プログラミングでオブジェクトを表現すること。 - ページ 13

 
Aliaksandr Hryshyn #:
一例を挙げてみましょうか。

その例については、もう少し後で、読者に対してより完全に、より明確にコンセプトを提示することにしよう。

 

第3部

Event Modelを 正式なものにするためには、Eventの 性質を拡張することが必要である。これまでのところ、すべてのオブジェクトはいわゆる「プロトブロック」、すなわちオブジェクト・システムの「生命」を再現するためにハンドラ関数によって使用されるパラメトリックな基礎を持ったいくつかの特定の実体から構成されていると仮定してきた。各「プロトブロック」は、マトリョーシカのように、より小さなプロトブロックの「ボディ」を含み、それ自身もより大きなプロトブロックのボディに含まれる、パラメトリックな「ボディ」を持っていると言われたのである。パラメータは最小の「粒子」であり、パラメータの集合はオブジェクトのパラメータ的「本体」であり、この本体から「束ねられない」パラメータの集合は次の複雑さのレベルのプロトブロックである。ここで一旦、プロトブロックのパラメトリックな構造を見て、「イベント」に 話を移し、その成り立ちを理解することにしよう。この時点で述べることができる。

  • 状態は、オブジェクトのパラメータセットから派生した構造、つまり、選択されたパラメータの「キャスト」である。
  • Stateは、そのObjectの値の重要なインスタンスを保存する。
  • 構造的には、パラメトリックなステート本体は、「レゴ・ツール」としてプロセスの一部となる。
  • プロセスとは、オブジェクトの "ライフ "によって連鎖的にリンクされたステートのシーケンスである。
  • プロセスには、「シネフィルム」のフレームとしての「ステート」が含まれ、それに分解されます。

次に、本イベントの発端とそのパラメトリックな構造の開示に進みます。イベントがどのように形成されるのか、パラメトリックな「肖像画」とプロトブロックの階層におけるその位置を確認しなければならないのです。この後、プロトブロックを機能的なシステムに「つなぐ」ことに移り、イベントモデルの「誕生」をたどります。イベントのパラメトリック構造は、永続的な属性の組み合わせによる複数のバリエーションを持つことにすぐに気がつくべきである。知っておこう。

  • イベント背景 - イベントとして 考慮される意味のある変化に 先行する、または付随する初期 状態として 表される、オブジェクトまたはその環境(環境内の他のオブジェクト)から取得されたパラメータとその値のセットです。
  • 目標値- オブジェクトまたはその環境の選択されたパラメータのセットで、そのオブジェクトまたはその環境の目標 状態として 表され、イベントとして 扱われるもの。
  • ターゲット差分-Object またはその環境の 選択された一連のパラメータの 過去と現在の値の間に求められる差分で Object またはその環境における重要な イベントとして表現さ れる。
  • ターゲット比率-イベントと みなされるオブジェクトまたはその環境の、選択された一連の パラメータの値の比率
  • ターゲットの「シグネチャー 」 -イベントとして 扱われる、オブジェクトまたはその 環境の選択された一連のパラメータの過去と現在の値の間の 変化の求める特性。

ここでは、パラメトリックボディに含まれ、さまざまな組み合わせで構造を構成する「イベント」の 5つの主要な属性を列挙した。イベントは、他のプロトブロックと 同様に、オブジェクトの動的な生活の中でパラメトリックなボディから構築され、さらに望ましいターゲット(背景、値、差、比率、署名)をイベントモジュールの テンプレートとして 計算し記録するために、現在の瞬間からキーパラメータとその値を「取り込む」ことによって形成されています(システムでさらに使用するため)。イベント生成時に、差分やシグネチャーの計算結果を格納するための派生パラメータがボディに追加される。また、ターゲット計算やパラメトリックレイアウト、レコーディングに必要な機能を備えた専用のハンドラ-コレクタでイベントを作成することもできます。もちろん、EventState よりも複雑で、後者とは異なり、Object(s) のパラメータの直系の子孫ではなく、差分の計算結果や初期パラメータの変化の性質に関するパラメータで補完される「派生」部分を持つが、構造的にはStateProcess と同じプロトブロック、つまり値のインスタンスを持つパラメータ セットである。

プロトブロックをシステムへリンク させる。

これで、プロトブロックは少なくとも3つの方法で特別なハンドラ-コレクタ-によって形成されるという概念を得たことになる。

  1. StateやProcessを 構築する際に、Objectのパラメトリックボディを削り取る」方法。
  2. イベントを 構築する際に、オブジェクトや環境の現在からパラメータとその値を取得 し、「背景」「目標値」「目標比率」を確定させる方法です。
  3. Eventを 構築する際にも、ターゲット差分や ターゲット変化シグネチャの 特殊な派生パラメータを追加して 計算する方法 です。

そして、「コンセプトで用意れたプロトブロックから、どのように "生きた "システムを構築するか、そのために "イベントモデル"はどのような役割を果たすのか」という問いに移りましょう。

あらゆるシステム(オブジェクト)の重要な「生命のメタプロセス」は、次の2つです。

  • 決められたプログラムを自主的に実行すること。
  • 環境との相互作用。

この2つのメタ・プロセスは 1つに織り込まれており、外部からの影響により独立した実行プロセスが妨害されると、それに応じてシステムは失われた均衡を取り戻し、独立した実行プロセスを継続させるためにパラメータを変更するのです。全体として、このダイナミズムは、「環境」における「システム」の 生命である。外的作用と内的反応」の関係がどのように実現されるかを理解するためには、この概念にもう一つの要素である「コンディショナリティ」を追加する必要があります。

  • コンディションは コーズと エフェクトを システムの他のプロトブロックと接続するプロトブロックである。前編で説明したパラメータ連携ハンドラは、連携したパラメータの値を内部に設定されたルールや式に従って変更するのに対し、Conditionは依存関係のルールや式を定式化せず、式やアルゴリズムなしにプロトブロックを内部に因果の連鎖で繋ぎます。例えば、あるEventは Causeの「本体」に置かれ、あるConditionはEffectの「本体」に置かれる。このように、あるイベントをチェックし、検出することで、ある状態をObjectの中に取り込むことができる。数式や計算を使わずに単純に、あるプロトブロックから別のプロトブロックへ直接移行することです。
  • コンディションは、他のプロトブロックと 同様に、ハンドラを持つ。この場合、「then」「else」とともに、「if()」という演算子が最も効果的である。Cause」の本体(「if()」に入れられる)には、常に パターンと インスタンスの 比較があることに注意してください。Eventを チェックする場合、そのテンプレートをConditionに 入れ、Condition ハンドラ自身がテンプレートのパラメータからインスタンスを集め、その値をオリジナルと比較し、比較結果に応じて2つのConsequenceその後」または)のうち1つを選択することになる。
以上、今回はこの辺で。これでイベントモデルを考えるためのコンセプトは一通り揃ったので、(興味があれば)次に紹介することにします。


 
Реter Konow #:

第3部

lib(ライブラリ)は直感的に操作できるようになるのでしょうか?

 
Реter Konow #:

しかし、私たちはその扱いが非常に苦手で、しばしば非常に低いパフォーマンスで我慢しなければならず、コンピュータは簡単に私たちを圧倒してしまうのです)。

私たち(意識)は、脳の機能のほんの一部に過ぎず、必要なものでもない...。しかし、高次の神経活動の他の側面では、脳はよく機能し、どんなコンピューターにも勝つことができる...。詩、絵画、物語、科学などなど、話にならない...知能的には脳よりシャベルに近い...。

 
transcendreamer #:

(図書館は)直感的にわかるようになるのか?

あなたがどれだけプログラミングの経験があるのかわからないので、私が書いていることがどれだけ理解できるのか想像がつきません。完全なヒューマニストにとって、このコンセプトはほとんど理解できないでしょうが、コーディングのスキルを持つ人にとっては、多くのことが非常に明白です。質問を立ててみて、それに答えてみる)。

追記:コードベースにたくさんのコードがあるということは、経験があるということですね。そうすれば、コンセプトの多くが明らかになるはずです。

 
Nikolay Ivanov #:

私たち(意識)は、脳の機能のほんの一部に過ぎず、その必要すらありません...。しかし、高次の神経活動の他の側面では、脳はよく機能し、どんなコンピューターにも勝つことができる...。詩、絵画、物語、科学など、コンピュータは何の関係もない...知能という点では、脳よりもシャベルに近い...」と。

私もそう思います。

 
Реter Konow #:

あなたがどれほどのプログラミングの経験をお持ちなのかわからないので、私が書いていることをどれだけ理解しているのか想像がつきません。全くの素人にはコンセプトがよくわからないでしょうが、コーディングのスキルを持つ人にとっては、多くのことが非常にわかりやすいのです。質問を立ててみて、それに答えてみる)。

追記:コードベースにたくさんのコードがあるということは、経験があるということですね。そうすれば、多くのコンセプトがクリアになるはずです。

mql5には標準ライブラリがありますし、複雑なエンティティを扱う際にある種の安心感を与えてくれるライブラリもあります(ただし、逆に不必要に複雑化してしまう場合もあります)。

 
transcendreamer #:

まあ、mql5には標準ライブラリがありますし、他にも複雑なエンティティを簡単に扱えるライブラリはあります(ただし、逆の場合もあります)--そこで質問ですが、こんな便利なライブラリはないでしょうか?

何とも言えませんね。このような非標準的なアプローチを実現するには、標準的なOOPを使わず、低レベルのプログラミングですべてを行う必要があると思います。でも、もしかしたら私が間違っているのかもしれません。

 
Реter Konow #:

何とも言えませんね。このような非標準的なアプローチを実装すると、標準的なOOPを使わずに、低レベルのプログラミングですべてを行う必要があると思います。でも、もしかしたら私が間違っているのかもしれません。

すべて完了

 
Реter Konow #:

何とも言えませんね。このような非標準的なアプローチを実装すると、標準的なOOPを使わずに、低レベルのプログラミングですべてを行う必要があると思います。でも、もしかしたら私が間違っているのかもしれません。

重要なのは、ユーザーにとって、それが複雑化ではなく、単純化であることです。

理由: