シンプルさの簡単な説明。 第1章：理論的にシンプル

シンプルさの簡単な説明

MAINの質問に答えるために訪問しなければならないエリアを含むCAP 。

まえがき

私はよくアドバイスを聞いた：それを簡単にします。



そしてsimpleはどういう意味ですか？ オブジェクトXが単純であると言うとき、Xに対する期待は何ですか？ あることは別のことよりも簡単だと言うとき、どのように評価するのでしょうか？



どちらが簡単ですか：

「5語の短い文」または「deoxyribonucleic」という語ですか？

「6 * 5」または「481」？



または：

設定画面があります。 そのうちの5つはスケジュールに関連し、残りの5つは通知に関連しています。 メインメニューで「スケジュール」と「通知」の項目を個別に作成する必要がありますか？ または、1つの画面に10ポイントすべてを残しますか？ ユーザーにとって何が簡単になりますか？



これは主観的なものだと言えます。 これは特定の「シンプル感」によって決定され、ある人にとっては何かが単純であり、別の人にとっては複雑であるということです。



では、先生がもっと簡単に何かを説明するのに時間を費やす理由を教えてください。 なぜテキストを編集し、簡単にしようとするのですか？ プログラマーがコードの確認に時間を費やして、どのソリューションの方が理解しやすく、拡張しやすいのかを見つけようとする理由



単純さが評価と何らかの関係がある場合、最良の戦略は説得です。 テキストが単純であると読者に信じさせましょう。 または同僚は、私たちの決定は難しくないと信じていました。



これにより、仕事の結果との相互作用が質的に変わりますか？



いや



あなたのテキストは簡単だと考えられているので読みやすくなりません。 あなたの周りの誰もがその複雑さはスツールのそれと同じだと思っているとしても、コードを扱うのは簡単ではありません。



インタビューで、会社にはきれいなコードと優れたドキュメントがあると言われ、それを信じていた場合、これはコードの操作の単純さに影響しません。

さらに、コードがきちんと書かれていてドックがあると部門全体が信じているとしても、これは結果に影響しません。 彼らのコードに対する彼らの信念は間違っているかもしれません。



コードがスパゲッティだった場合-スパゲッティになります。 「ドキュメント」が「ここに2つの数字を追加しました」という形式のコメントである場合-コードにはドキュメントがありません。

そして、欲望や自信などはここでは役に立ちません。



これは^、それぞれ2つのカップケーキを2箱しか持っていない場合、5人の友人に1つのカップケーキを与えることができないほぼ同じ理由^{（ ru 、 en ）}で機能しません。 2 + 2 = 5という1年間、会社全体を瞑想する場合でも、カップケーキの悲しい状況は変わりません。



もう一度。 オブジェクトがあり、その特徴のいくつかは、あなたがそれを単純だと思う^{（ ru ）}ことができます。 そして明日、評価が変わり、「難しい」マークで停止した場合、オブジェクトは気にしません。



単純さや複雑さは、私たちの期待に依存しないと結論付けることができます。 むしろ、反対に、オブジェクトはどの特性を与えるかを決定します。



単純だと確信している^{（ ru ）}場合、実際にどのようなオブジェクトが表示されると予想されるかを理解したかったのです。 そしてその逆に、実際のオブジェクトのどのような特性が、私はそれを単純であると考えさせます。

なんで？ まあ、これは私の人生を楽にするでしょうか？）

第1章理論的にシンプル

この章では、次のトピックについて説明します。

• 質問の仕方、そしてなぜこれが重要なのですか？ （ 質問のシーケンス ）
• オブジェクト、アクション、およびそれらのエグゼキューターはどのように関連していますか？ （ アクションのシンプルさ 、 客観的な主観性 ）
• アクションの複雑さを判断する方法は？ （ 使いやすい 、 おそらくシンプル ）
• システムとそのモデルとは何ですか？なぜこれがオブジェクトを記述する便利な方法なのですか？ （ モデリングの体系化 ）

この章の最後で、OccamのRazor（ Blade Runner ）について少し説明します。 シンプルさに関する記事は、この原則に言及せずに奇妙に見えたでしょう。

1.1質問の順序

私たちの研究は質問から始まります。 質問を正しくすることは非常に重要です。 小さな余談：



-わかりました、深い考え、単純さの主な条件は何ですか？

-私はそれについて考える必要があります。

...

...

数百万年後...

- $$$<42。$



// 1つの美しい本に基づく



答えはありますが、何も得られません。 彼に関するすべての情報は質問に含まれていますが、質問はあまり具体的ではありませんでした。 それを証明することはできません $$$<42$ -本当に主な条件と反対を示すことはできません。



質問は、可能な回答の範囲を制限する必要があります。



「単純なものは何ですか？」は、それほど具体的な質問ではありません。 それを明確にしましょう。 記事の冒頭で、このパスの一部を既に実行しました。



オブジェクトXが単純であると言うとき、それから何を期待しますか？



私の観察によると、主に2つのケースがあります：

1. Xは、コンポーネントに分解されないオブジェクトです。 ここでは、「単純」という単語を「小学校」という単語に置き換えることができます。
   
   
   
   これはレンガです。 そして、ある意味、彼はシンプルです。
2. Xは、必要なアクションを簡単に実行できます。 たとえば、ソファは横になりたい場合はシンプルで、9階に上げる必要がある場合は複雑です。

オブジェクトが基本的な場合は理解できます。 しかし、アクションのコンテキストの複雑さに興味がある場合はどうでしょうか？



考え直してみましょう。 オブジェクトでアクションを実行します。



この文には3つの主要なエンティティがあります。

• アクション-何が起こっているかの説明。
• アクションの実行者-私たちは言葉の下に隠れています。
• オブジェクトは、アクションの実行対象です。

次に、次の質問に興味があります。

• 実行されるオブジェクトに応じてアクションのシンプルさを評価する方法は？
• アクションとそのエグゼキューターの関係は何ですか？

以下に回答します。

1.2使いやすさ

アクションを見てみましょう。



アクションの単純さは、その複雑さに反比例するものです。 アクションが複雑になるほど、単純ではなくなります-明らかです。 次の質問に答えます。

アクションの複雑さを判断する方法は？

アクションで何ができますか？ 他のシーケンスに分解できます！ アクション「記事を読む」は、「最初の段落を読む」、「2番目を読む」などに分けることができます。 それらは、順番に、「最初の文を読む」、「2番目の文を読む」として分解します...







同様に、複雑さの違いが私たちにとって重要ではなく、実行されるオブジェクトに依存しないアクション（レターを読むなど）に到達します。 このようなアクションを基本と呼びます。



次に、特定のオブジェクトのアクションの複雑さを、それが分割された基本アクションで測定できます。



アクションは、アクションの同じシーケンスに分割されている場合、同等です。



アクションの特徴は他に何ですか？

アルゴリズム

別のアクションを構成する一連のアクションの説明は、アルゴリズム^{（ ru 、 en ）}と呼びます。



アルゴリズムは、たとえば次のように一般的に説明できます。

読書：テキストがなくなるまで文章を読みます。

この形式では、読書は多くのテキストに適用できます。



ただし、ご理解のとおり、「文章を読む」アクションの数は、テキスト内の文章の数に依存します。

結果

アクションは何らかの理由で実行され、何かにつながります。 アクションに結果を持たせましょう！



その結果、アクションが発生したシステムの状態が変化します。 スイッチを押すと、スイッチが「オン」状態に移行し、キッチンで点灯するライトがこのアクションの結果です。 あなたはその言葉を読んで、その結果はあなたの脳の状態の変化です。



異なるアクションが同じ結果につながる可能性があります。

オブジェクトとのコミュニケーション

オブジェクトに戻ります。 すでに述べたように、さまざまなアクションを実行できます。 このエンティティまたはそのエンティティが「意図されている」アクションを理解する方法が必要です。



例から始めましょう。



「そして、このスーツケースをどのようにドラッグしますか？」

-彼は横にペンを持っています！



ハンドルはスーツケースの外側にある一片の革で、リベットで釘付けされています。 しかし、この場合は気にしません。 スーツケースに持っていける物があるのではないかと心配しています。



このようなすべてのオブジェクトをハンドルと呼びます。 カップ、ドア、スーツケース、またはバケツに置くことができます。







例から2つのペンの説明があるという結論に達しました。

1. 革のストリップがスーツケースに釘付けされたリベットのように。
2. 取り組む対象の概念として。

最初は実装^{（ en ）の}記述です。



2番目は、インターフェイスの説明です。



インターフェイスは、それを実装するオブジェクトと対話する方法に関する情報を格納するオブジェクトです。



なぜ必要なのですか？ 簡単です。ほとんどの場合、オブジェクトの実装方法には関心がありません。

ライトをオンにしたいときは、スイッチを探しています。どのように機能するかは関係ありません。重要なことは、その状態をオン/オフに切り替えることができることです。

ボタンが表示されたら、クリックできることがすでにわかっています。

どこかにペンがあると言われたとき、あなたはそれを取ることができることをすでに知っています。

そして、それは非常に便利です。

まとめ

アクションは、アルゴリズムを定義する他のアクションのシーケンスです。 アクションの結果は、何らかのシステム変更です。



アクションの複雑さは、特定のオブジェクトに対するアルゴリズムの基本アクションの数に等しくなります。



オブジェクトとアクションの関係により、オブジェクトのインターフェースが決まります。 オブジェクトで実行できるアクションに関する情報を保存します。



次の質問：

アクションとそのエグゼキューターの関係は何ですか？

1.3客観的な主観性

あなたは合理的に気付くかもしれません：



「しかし、同じアクションを実行すると、結果が異なる可能性があります！ 物理学の教授がひも理論の記事をすぐに読み、すべてを理解できれば、同じアプローチで何も達成できません。 そして、同様の結果を得るには、言葉で定義を探し、他の記事を読み、もっと多くの行動をとる必要があります。」



これは良い点です。 答えがあります。



他のタスクと同様に、私たちのものには初期条件があります。 それらを変更すると、タスク自体も変更されます。 そして、これはその実装が異なるアクションを必要とするという事実につながります。



あなたは記事を読んでいます。 数ページを読んで、脇に置いたとします。 ここで、記事を読むために、アクションを少なくする必要があります。 しかし、記事自体の複雑さはこれから変更されましたか？ いや それで実行するアクションが変更されました。 「記事を読んで」、「記事を最後まで読んで最後まで読んだ」というものでした。



アクションで何をすべきか？ 望ましい結果を修正します。 覚えているように、さまざまな方法で到達できます。



さらに、パフォーマーをほぼ同じグループに分けることができます。 無限の数の出演者がいなければ、そのようなグループの数は限られています。



次に、各グループについて、それを望ましい結果に導くアクションを説明します。



パフォーマーのグループごとにアクションのセットを取得しました。 しかし、今は複雑さをどうするか？

1.4おそらくちょうど

一連のアクションがあります。 それらのそれぞれは、パフォーマーの特定のグループに属します。 特定のオブジェクトごとにこれらのアクションのそれぞれの複雑さを計算する方法を知っています。



しかし、アーティストがグループの1つに入る確率を設定しようとするとどうなりますか？

タスクは、古典的な理論的タスクに変わります。



アクションの複雑さの大きさがあります。 ランダムな人が各アクションを実行する確率があります。



複雑さの「平均値」を見つけることができます。 これは、いわゆる数学的期待^{（ ru ）}です。 これを行うには、オブジェクトとのアクションの各複雑度を、その発生確率で乗算する必要があります。



これらの確率をどこから取得するか、誰がオブジェクトで具体的にアクションを実行するかがまだわからない場合にパフォーマーをグループに分割する方法は？いい質問です！



その考察は私たちの記事の範囲を超えていますが、私の意見では興味深い例を挙げます。



あなたは著者です。そしてあなたの仕事は、テーマ別のセクションがあるサイトで記事を書くことです。記事を投稿すると、一般フィードおよびその「セクション」のフィードに表示されます。セクションには購読者がいて、サイトの視聴者の一部を占めています。共有フィードは全員に表示されます。セクションにサブスクライブしている人はそのトピックを理解しているが、署名されたトピックは理解していないと仮定します-いいえ。

物理学に関する記事にしましょう。オーディエンスを分析したところ、サイトのオーディエンスの3％が「物理」セクションに登録していることがわかりました。このセクションの購読者がそこから記事を入力する可能性は80％であることがわかりました。また、一般的なフィードから記事にアクセスする確率は5％であることがわかりました。



潜在的な読者はだれですか。「物理学」セクションに登録していない人のために記事を「最適化」する必要がありますか？言い換えれば、物理学に精通した人が私たちの記事を読む可能性はどのくらいですか？



したがって、注意、この確率は...約33％です。



読者の3分の2以上が物理学を理解していないため、これを考慮する必要があります。



どうして起こったの？要するに、物理学に精通している人が記事を訪れる可能性が高いことは、その少数によって補われます。共通のフィードから記事にアクセスするわずかな機会が、評価で重要な役割を果たし始めます。これについてもっと知りたいですか？ここにベイズの定理^{（ru、en）}に関する良い記事へのリンクがあります。

確認したい場合：





アクションとそれを実行する人について話しました。最後の質問に移る時間です。

「オブジェクト」という言葉をよく使用しましたが、それについての情報は提供しません。多くのエンティティに適用できるように十分に抽象的であり、作業できるように十分な情報が必要です。



使用するオブジェクトの記述方法は？

1.5モデリングの体系化

私はテキスト、表、図などを一般的に説明しようとすることにしました。しかし、それを行う方法は？



一歩後退して、彼らの「創造」がどのように起こるかを見てみましょう。多分これは私たちを助けるでしょう。



テキストを書きます。あるアイデアがあり、それを言葉で定式化し、書き留めます。さらに、アイデアは他の言葉の形だけではありません。写真、音楽、数学的なオブジェクトを記述することができます。



コードを書いています。コードに変換する要件があります。これらは口頭で表現することも、イメージ（インターフェースのスケッチなど）を表すこともできます。

図を作成します。このスキームで説明するオブジェクト間の関係があります。



これらのプロセスには共通点があります。何らかのシステムがあります。必ずしも同じ「用語」を使用しているわけではありませんが、別のシステムに変換します。



「モデリング」という言葉は、このプロセスを説明するのに適しているように思えます。



したがって、モデルとは、指定された表記（用語）を使用して別のシステムを記述するシステムです。



この定義は合理的な質問につながります：

システムとは何ですか？

システムは、いくつかのコンポーネントの組み合わせです。可能な状態と現在の状態のセットによって定義されます。システムコンポーネント私はしばしばオブジェクトを呼び出します。

これらは、要素（事前定義されたもの）およびこれらの要素で構成される他のシステムになります。接続のようなものがまだあります-それらは、他のオブジェクトに応じて1つのオブジェクトの可能な状態を制限または決定したいときに現れます。



例：

2枚のコインのシステムがあります。それらの1つは「ワシ」状態にあり、もう1つは「尾」状態にあります。

イーグルと尾は私たちのシステムの要素です。



コインは、「ヘッド」と「テール」の要素で構成されるサブシステムであり、これらの状態のいずれかになります。最初のコインの場合：







コインを裏返すことができず、システムに変更を加えることができないとします。この場合、システムは次のように記述できます：







コインを投げることができる場合、システムは次のように記述されます：







いくつかのシステム間に依存関係があります。 2番目のコインの状態を最初のコインの状態と等しくすることはできません。



コイン2の可能な状態のセットは、制限を考慮して、コイン1が配置されている状態を除く、以前のすべての可能な状態です。







この場合、コイン2の状態がコイン1の状態を決定すると言うことができます。



ここで、「エッジ」を追加してコインの可能な状態のセットを変更するとどうなるか見てみましょう。



コイン1と2の状態のすべてのペアを作成できます。







この場合、コイン2の可能な状態を制限することについて話します。

更新：

Javaでのコインのサンプルの実装を作成しました。これがリポジトリです。さらに、基本アクションのためにコイントスを行う場合の複雑さの計算方法も示します。

モデルに戻る

モデルを最初のマッピングである別のシステムと呼びます。 一般に、他の要素から構築できます。 システムのモデルは地図であり、システム自体は領域^{（ en ）}です。 誰も他のモデルのモデルを作成する必要はありません。 マップ^{（ en ）の}マップを描くことができます。



モデルを構築してみましょう。



古典から始めましょう：ブラックボックス。

あなたが持っている：「入力」、「出力」とボックス。 結果を「入力」として取得するために変更するコンポーネント、結果を「出力」として表示するコンポーネント、および残りをブラックボックスとして指定します。 そのようなモデルは、システムの内部依存関係を記述しませんが、それらを隠します。 結果がどのように得られるかはわかりません。







このアプローチは、システムの動作を調査する場合によく使用されますが、同時に「開く」ことはできません。 たとえば、心理学。 私たちは人々にテストを与え、彼らはそれを解決します。 現時点では、人々の頭の中で何が起こっているのかわかりません。 ただし、十分なデータを収集したら、デバイスボックスについて説明できます。これにより、同様の結果が得られます。 Machine Ex Homoパートでは、これをさらに詳しく見ていきます。



次に、コンポーネントのセット全体とその可能な状態を表示するモデルを作成します。



あなたは古代ギリシャに住んでいます。 あなたの隣人のゼノ^{（ ru ）は}すでにあなたをつかまえました。 このエイドフの息子は、毎晩別の脳を破壊するミステリー^{（ ru ）}であなたの家に侵入し、その後、あなたは眠れない夜を考えて過ごします。 あなたは眠る必要があり、そのためには少なくとも数日間彼を黙らせる必要があります。



彼が最後に亀を追いかけているアキレスの物語に頼った時。 この夜、バケツの1つに目が落ちました。 興味深い考えが浮かびました 。バケツと石を使って、そのアポリアをより詳細に調べることです 。



亀の各ステップで、開始点に対するアキレスと亀の位置を見つけられるようにします。 歩き回るカメ、アキレス、カメの10倍の速さです。 そして、それらの初期位置：1000ステップと0ステップ。



私たちのモデルはまだ数字の表現方法を知りません。 そしてその上で、アキレスがどこにいるのか、カメがどこにいるのか、道がどこにあるのかを区別することは絶対に不可能です。



自然数の表現は簡単です。バケツを取り、この数に等しい石の数を入れます。



これで、速度と経路を説明できます。 アキレスの速度を示すバケットには、10個の石があります。 カメの速度のためのバケツ-1石。 それでは、 「バケットオブザウェイ」に進みましょう。 私たちは亀に千の石を置き、アキレスを空のままにします。 亀が一歩を踏み出すと、石をスピードからパスにシフトします。 終わった？



まだです。 バケツに署名するペイントはありません。 石だけ。 これを処理する方法は？



または、タートルバケットを「速度」を「パスのバケット」の右側に配置することもできます。 アキレスのバケツでも同じことをします。 そして、カメのバケツを押し戻します。 これで、「2つのバケット」の組み合わせで、右側のバケットが高速で、左側が高速であることがわかりました。



2つのバケットの2つのグループを見ます。 アキレスのどのグループに行く必要があるかを調べるには、バケツを見て、その中の石を数え、アキレスの速度が10ステップであることを覚えて、バケツがアキレスに属していると結論付けてください。 そして、いくつかの変更を行い、アキレスの速度をカメの速度と等しくしたい場合はどうでしょうか？ その後、アキレスのチェック方法は一般的に機能しなくなります！



したがって、速度と経路のバケツの前に、「名前のバケツ」を配置します。 今では一番右になっています。 ルールを次のようにします。名前のバケットが空の場合、それに続くバケットはカメです。 石があれば、このバケットのグループはアキレスを意味します。





私はSで石を描いていませんでしたが、最初のステップではアキレスのバケツが空であり、亀には1000個の石が含まれていることは明らかだと思います。



あなたは喜んでいます。 今、ゼノンは、彼が石の分割のプロセスを永遠に続けることができると決めた理由について一生懸命に考えなければなりません。 少なくともあなたは本当にそう願っています。

残念ながら、これは睡眠の改善には役立ちませんでした。 ゼノは本当に次の夜に来ませんでしたが、今あなた自身は深く考えています。 石を分けることが不可能になる^{（ ru ）}瞬間が来るでしょうか？



見てください。各ステップで、検討している各オブジェクトのある種の状態を取得しました。 アキレスの位置は1つのバケツに対応し、カメは他のバケツに対応します。 速度については、状況は似ています。 このモデルは、シミュレートされたシステムのすべてのオブジェクトのすべての可能な状態を完全に記述します。



テキストもシステムのモデルです。 この場合の用語は単語です。 それらは意味によって、または意味のセットによって定義され、コンテキストによって制限されます。

私たちの感覚は、外部からの情報に基づいて脳が作成するモデルでもあります。



要するに、あなたは常にモデルに出くわします。



なぜ私たち全員がこれをしたのか覚えていますか？ 念のため：モデルの定義を行い、その複雑さを計算しました。 時間が来ました。これをどのように適用できるかを見てみましょう。



あなたはUXデザイナーです。 あなたのタスク：アプリケーション設定ページを作成します。 あなたは、彼らが将来変化しないことを知っています。 全部で10個あります：5つのグラフィックと5つの通知設定。



すべてを1つの画面に残すことができます。 また、最初の画面で「スケジュール」および「通知」項目を作成し、5つの設定で対応する画面に切り替えることができるというアイデアも得ました。







ユーザーのメモリが非常に乏しく、上から下へ読む習慣があると仮定しましょう。 しかし同時に、オプションをグループ化した場合、彼はセクションで間違いを犯さないほど賢いです。 彼は画面の名前を読まずに、メニュー項目に直接行きます。



設定は10個しかなく、リストで画面に表示することができ、ユーザーは目的のアイテムを単に突くだけです。 この場合、ユーザーはシートをスクロールする必要はないと考えています。 一方、ユーザーが最後から設定が必要な場合は、リスト全体を読む必要がないため、必要なポイントの半分をスキップできます。



どのモデルがより簡単な相互作用を提供しますか？



ユーザーがリストアイテムを使用して実行できるアクション：読み取りとそのアイテムへの突入。 インターフェイス言語に翻訳する場合：メニュー項目には読みやすさと読みやすさのプロパティがあります。 すべてのポイントは短いので、それらを読む難易度の違いは無視されます。 「突く」および「読む」アクションは、私たちの文脈では基本的であると想定しています。 複雑さは1です。



ユーザーがいずれかのアイテムを必要とする可能性が等しくなると予想されます。 それらを取り上げても意味がありません。



もちろん、あなたはすでに答えについてある種の予感を持っています。 書き留めておくとともに、答えが正しいという自信を書き留めておくことをお勧めします。 たとえば、1から10までのスケールでは、10は絶対に確実ですが、1はまったく確実ではありません。 結果と比較するために、このデータが必要になります。 ネタバレ「決定」の下で調査が行われます。 残念ながら、Habrはテキスト内のどこでも投票を行うことを許可していないため、リンクはGoogleフォームにつながります。 そこで、あなたはそれを調べて、全体的な結果に関する統計を見ることができます。



ペン、紙、電卓を開いて難易度を自分で計算することをお勧めします。 そして、その後だけ、スポイラーを開きます。





最終編集段階でこの例を記事に挿入しました。 私が話していたことを要約することは私にとって重要でした。 前の章の情報をわかりやすい方法でリンクします。 簡単に想像して、私たちが話したことを使ってみてください。



私は間違っていました。 この例を書いたとき、私は答えが何であるかを知っていると思いました。 そして今、私はかなり驚いています。 いいえ、そうではありません。 私がすべての計算を正直に実行したとき、結果は私に非常に大きな打撃を与えました。 私の頭の中で、次のようなことが起こりました。



-*一斉*私たちは誤解されていますか？！





...

...

...



私はそのような膨大な余談と例を謝罪します。 おそらくあなたはこれ以上読む準備ができていないので、もう一度考え直したいと思うでしょう。 そしてこれは良い選択です。



最初に目次があります。記事をブックマークして、すぐにこの場所に戻ることができます。



続行することに決めましたか？ 次に、私が提起したいものの最後のトピックがあります。

1.6ブレードランナー

OccamのRazorを知っている可能性が高いですが、念のため、思い出させていただきます。

「絶対に必要でない限り、新しいエンティティを引き付けるべきではありません。」



一般に、この原則は次のように解釈されます。すべての仮説の中で、最も可能性が高いのは、最短のサブルーチン（または、より単純に短いサブルーチン）によって記述されるもの^{（ ru 、 en1 、 en2 ）}です。



実際の生活の様子：

ライトをオンにしてライトが点灯した場合、仮説は次のようになります。

1. スイッチが電気回路を閉じ、電流が電球を通過しました。
2. スイッチが小さなノームを蹴り、ワイヤーが接続された結果、回路が閉じて電流が電球を通りました。
3. スイッチは小さなノームを蹴り、小さなドラゴンが座っていたトロリーを押し、炎にrightえ、はんだを溶かし、ワイヤを接続し、その結果、回路が閉じて電流が電球を通りました。

これらの仮説のうち、gnomeのないエンティティが少ないものが望ましいです。 ただし、電球をオンにした場合、スイッチから静かな宣誓が聞こえます-スイッチが宣誓する理由は説明されておらず、後者には冗長エンティティが含まれているため、2番目の仮説が望ましいです。



私は正直になります。 OccamのRazorを初めて聞いたとき、仮説については考えませんでした。 そして、その曖昧な言葉遣いは、これが一般的な原則であるという考えに至りました-あなたのシステムにあるエンティティの数を減らすと、すべてがクールになります。



私は非常に間違っていました 。



しかし、システムの単純さについて説明したとき、この原則の誤った解釈を修正する方法に気付きました。 そして、それから何か役に立つものを作りましょう。



変更前と変更後のシステムがあります。



BeforeとAfterの複雑さの違いが、変更を行うプロセスの複雑さよりも大きい場合、この変更は正当化されます。変更は結果（少なくとも必要な部分）に影響しなかったことが理解されます。それを呼び出す...簡素化のための必要条件。



繰り返しますが



、変更後のシステム の予想される単純化は、変更自体の複雑さよりも大きくなければなりません。



の変更の複雑さを示す場合$$C および、システムの複雑さ$C_$$$Cおよびその後の方法$C$$$C 「我々が得ます：$C’$



$$$C’ - C > C_$ 。

また、変化に対する効率の類似物を表現することもできます。

$$$k = (C’-C)/C_$ 。

もし $$kが1より大きい場合は、必要な単純化条件に対​​応する適切なコーシャーの変更です。$k$

もし $$kは 1より小さいが0より大きい-これは、システムを単純化するが、利益を得るよりも多くの労力を費やすことを意味します。$k$

もし $$kが 0未満の場合、このような変更は実行する価値がないことがわかります。複雑です。$k$



なぜ必要なのですか？たとえば、時間の限られた状況で行動し、必要な変更に優先順位を付けたいとします。大きな変化$$kを最初に考慮する必要があります。$k$



例：



2つのテキストがありますが、1つにはテキストがありません。



一方では、テキストの量を増やして、それを複雑にしました。しかし一方で、これのおかげで、一部の読者は「Occam razor example」をグーグル検索しません。見積もりでこのような読者が多数いる場合は、例を紹介すると記事が簡単になります。



私たちも彼を説明するためにいくつかの行動をとったことを忘れてはなりません。あまりにも多くのアクションを費やし、単純化では十分ではなかった場合-エッセンスの導入は「報われません」。



うーん、これはすべてオッカムのカミソリとどのように関係していますか？



すでにいくつかのシステムがあると仮定しましょう。そして、それらの複雑さは、エンティティの数に直接依存します（実世界では、これはすでにわかっているように、必ずしも真実ではありません）。これらのシステムでのアクションの結果は私たちに合っています。



すでにシステムがあるので、$$C および → 0（システムに変更を加えるために何もする必要はありません）。最小数のエンティティを持つシステムを取り、計算します$C_ \rightarrow 0$$$他のシステムと比較した k。わかった$k$$$kはマイナスの無限大に等しくなります。そのような状況で、単純さの観点から、最も少ないオブジェクトを含むシステムとは異なるシステムを選択することは、無限に愚かな解決策です。これは、すべてのシステムの中で、オブジェクトの数が最も少ないものを選択する必要があることを示しています。$k$うんOccam's Razorに不審なほど似ています。



この条件を使用して他に何を説明できますか？

たとえば、さまざまなコード改善プラクティスを適用する価値がある場合と、無意味な場合を評価できます。



実際、大学でタスクを書いて、そのコードが一度読まれた場合（またはまったく読まないが、それがどのように機能するかを見るだけ）、それがよく読まれることを心配するべきではありません。



しかし、あなたがオープンソースプロジェクトのために書いており、何百人もの人々があなたのコードで作業する場合、またはあなたが開発する予定のあなたのプロジェクトを書く場合、あなたはその品質に注意する必要があります。



大要を書いている場合、将来必要になるかどうかを評価する必要があります。教師がその空き状況のみをチェックし、すべての情報がGoogleで見つけやすい場合、それを複雑にするのはなぜですか？



記事を書いている場合は、記事との相互作用をどのように見るかを決定します。たとえば、この記事は一度だけ読むことを意図したものではありません。クイック検索用に最適化しようとしました。そのため、各パートの下に「ブリーフフライ」スポイラーと目次があります。



ああ、人が私たちのモデルをどのように読むかをどうにかして説明し、このモデルの複雑さを読む方法を見つける方法があれば。私たちの行動がこのプロセスの複雑さにどのように影響するかを確実に言うことができ、私たちの理論を多数の実際的な問題に適用できます。



残念ながら、このためには、あらゆるモデルの人々を読み取るための一般的なアルゴリズムを作成する必要があります。これが非常に難しい作業であると思われる場合は、その通りです。



幸いなことに、私はすでにこの作業の一部を行っています。



Machine Ex Homoと呼ばれる次の章では、脳が情報をどのように扱うかを見ていきます。理解と、すでに知っている情報が新しいものの認識にどのように影響するかについて話します。人間の記憶を研究する分野での心理学者と神経生物学者の研究を見て、彼ら自身の記憶のモデルを作りましょう。その助けを借りて、単語の頻度の効果、エッジの効果、錯視など、いくつかの興味深い心理的効果を説明します。そして、さらに多くの写真があります。



要するに-それは面白いでしょう、私は約束します。





ライセンス：

CC BY-NC-SA 4.0