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

新しいコメント
 
transcendreamer #:

72のケース、24の新しい特殊用途のケース、非線形書法、行列文法、形態素解析、boustrophedon、特殊音声学 - クールな貿易宗派が必要とするものだけです（だからチェキストやフリーメイソンは聖杯を盗めません）。

そうですね、「2本の移動平均線をクロスさせる」という表現はぜひイフクイルに訳すべきですね)

 

この話題は哲学的な部分が多く、アルゴトレーディングだけでなく、（場所によっては）プログラミング全般の枠に収まらないため、「複雑化アルゴリズム」についての最後の一説で概念の一連の部分を完結させ、その理解の概略と疑問-こんなアルゴリズムが原理的に存在できるのか-に答えることにした。

予定通り、2つのネストしたループ（高さと幅）からなる1つのグラフィック関数を呼び出し、5つの基本パラメータ（x、y、幅、高さ、色）を使って、ピクセル画面上に単純な長方形のマーカーを描く例で「複雑化メカニズム」を考察してみることにする。

描画関数を "コンストラクタ "と呼び、そのパラメータをObjectに設定します。多くの人が考えるように、オブジェクトとは、画面のピクセルセットの中にある、色でマークされ、幾何学的な形に組み立てられたピクセルの「サブセット」ですが、プログラマーにとってオブジェクトとは、目で見て認識できる外形だけではないことに注意する必要があります。 と同時に、仕組みそのものを作る.ラベルはご存知の通り、描画関数によって2サイクルで「構築」されるため、パラメータを持つ関数も「ラベル」で あることを意味する。 この 点は、オブジェクトのシェルの視覚的な知覚に慣れていて、その背後にあるコードを遠回しで二次的なものとして考えている人には理解しにくいのですが、それはオブジェクトそのものであり、初期機能の実装やパラメータの値を変更した場合には、必然的にシェルの外形が変化することになるのです。

私は、関数のパラメータセットとその内部実装を分離して、それをメインオブジェクトとして扱う方が簡単だと思っています。もちろん、コンストラクタ関数の内部実装とそのパラメータセットは表裏一体なので、これは正しいとは言えませんが。しかし、内部実装の 変更頻度ははるかに低く、この変更は、例えばパラメトリックセットの値の変更などよりも根本的なものであり、作業や実験が容易である。コンストラクタ関数の実装方法が変わると、新しいパラメトリックセットが発生し、コンストラクタ関数の古いパラメトリックセットに基づいて作られたすべての「プロトブロック」の変更を伴います。すなわちラベルの状態を、x, y, width, height, color の5 つのパラメータで 構成し、イベント発生時に「有効化」する場合、関数構成器の実装方法を変更し、パラメータの数を 3 つに減らすと、主要なパラメータセットの構造（ここから、他の状態、イベント、プロセスがすでに作成されている可能性があります）が変わり、ラベルの状態の代替構築は「崩壊」して、新しいバージョンの関数構成器では役に立たなくなるのです。ここで、複雑化アルゴリズム実装の最初の大きな障害に直面する。それは、 関数コンストラクタの実装方法が、オブジェクトの複雑化の可能 性を制限していることである。この境界を、何らかのアルゴリズムに従って人手を介さずに超えることが、自動化されたコンプリケーション です。

ラベルの関数コンストラクタの本来の実装方法を変えずに、また複雑化という意味にも立ち入らずに、実験的に「素直な」ラベルの複雑化を考えてみよう。パラメータセットの値を変え、それをもとに新しい状態を「導出」するだけで、何が出てくるかを見ることができる。

  • 新しい状態のパラメータを、関数コンストラクタのパラメータの初期セットから選び、そのパラメータに新しい値を考案し、割り当てられたメモリブロックに書き込むのです。
  • ラベルの状態が一つ 増えただけで、自動的に イベントモデルを 構築することになります。ラベルが少なくとも一つの他の 状態を持つなら、いつかはそれに切り替わるはずですから、ラベルが別の状態に入る原因となる環境または他のオブジェクトに関連したイベントを記述する必要があります。すなわち、新しく追加された1つの状態は、 論理的に、代替状態に切り替えるための少なくとも1つのイベント記述と、（任意に）初期状態または他の状態に戻るための2つ目のイベント記述を必要とする。
  • オブジェクトに新しい状態が追加されるたびに、少なくとも1つ、できれば2つの新しいイベントが追加されます。その記述は、イベント モデルの条件の中に置かれなければなりません。先験的に、 SMの存在によってのみ、オブジェクトの 状態が切り替わる。結論：+1 オブジェクトの状態 = +2 オブジェクトまたは環境イベント + 2 SM 条件。
  • Object Stateを追加すると、Object State Change Eventも追加されるため、新しいEventに優先順位をつける必要があり、そのためには階層構造が最適である。新しいEventやStateが出現すると同時に、条件ツリーが成長する。Objectの振る舞いは、その生活に「関わる」ものとの外部との相互作用に対する様々な反応によって豊かになり、複雑さが進めば進むほど、外部との接触は広くなると言わざるを得ません。ラベルの複雑さを環境と切り離して考えることはできず、相互作用の環境が必要であることがわかった。さもなければ、新しい状態はメモリ上で「死荷重」となり、その変化の可能性は内部タイマーだけとなる。
  • 新しいObjectの状態を、環境中のObjectと不可分にリンクするイベントなしで作成しても意味がないことがわかった。Objectを複雑にする過程で、状態、イベント、イベントモデルの条件などすべてを一度に追加し（同時に階層的に整理）、イベント->状態、または...の関係を作成 する必要があるのである。イベント->プロセスなど
  • Object Processの追加は、Stateの追加と基本的には変わらず、割り当てるメモリ量が違うだけです。新しいプロセスは、状態と同様に、それ自身の基本的なイベント（スタートイベント、スイッチイベント、ストップイベントなど）を定義する必要があります。


結論

確かに、1冊以上の本を書く必要があるだろうし、1つの投稿では十分ではないだろう。しかし、あるプログラムに複雑化の目的を定義し、様々な状態、イベント、環境に対する反応を持つオブジェクトのモデルを作成するようにすれば、機能デザイナーの実装を変更せず、固定されたパラメトリックセットに依存しなくても、おそらく、n回目の試行と誤差の後に、簡単なタスクを行うラベルを作成できることは既に明白である。その複雑さは想像に難くないが、私は楽観的である。

 
こんにちは、私はExpert Advisorを持って、私はeurusdとusdchfで一日に約100ドルをテストしています。
 
Ruslan #:
こんにちはすべて私は専門家の顧問を持っている私は誰かがそれを得意としている場合より多くの詳細を必要とする今、私は約100ドルユーロとusdchfの日テスト

は...

中のオブジェクトが正しく表現されていない :-)

PS/オブジェクトに関係なく、失敗することが保証されている

 
グローバルスコープで式が使えない strategy("DailyCandleCross", shorttitle="DCC", overlay=true, calc_on_order_fills= true, calc_on_every_tick=true, default_qty_type=strategy.percent_of_equity, default_qty_value=75, pyramiding=0) を修正できませんか？
 
私は、いわゆる「複雑化のアルゴリズム」に関する私自身や他の人々の幻想を明らかにし（もし私がその出現に無意識に寄与していたならば）、鋭い読者を、宇宙自身があらゆる形態や「聖杯」のバリエーションを否定する厳しい現実に戻し、私の推論は、哲学への愛と「永久移動」や「タイムマシン」の発明で眠れない夜に熱狂し、自らの天才への信仰に苦しむ心が生み出したものであると示したいのである。
複雑化アルゴリズムを実装することはできないが、より正確に言えば、その「愚かな」バージョンを実装することができる。あるプログラムが、あるオブジェクトのパラメトリックな状態、イベント、プロセス、条件をランダムにスタンプし、同じランダムさの中で、それらを互いに複合化して...。は、それらを消去し、再び開始します。この奇妙な行動は永遠に続くかもしれないし、その目的は何なのか全く不明だ。結果はどうなったのでしょうか？ランダムな結果？そして、コンストラクタ関数の問題を覚えていますか？その実装をどう変えるか？全然、はっきりしないんですけど...。問題は、実装方法のわずかな変更によって、すべてのプロトブロック構造の「正当性」が完全に失われ、変更後の機能では使用できなくなることである。全ては、研究所や科学アカデミーが解決することを前提に、何年もかかる作業であり、最終的に何かが解決するわけではありません。
このフォーラムの雰囲気は、聖杯のインスピレーションで飽和し、適切な心のフレームを投げかけ、そこから後者は驚くべき、科学のようなたとえ話を生成します、残念ながら、決して実用的な何かにつながることはありませんが...。...元気が出ますが。:)
あまり厳しく判断しないでください、私はただ「哲学的な興奮」を感じていただけなのです)))
 
くそ、またエスカレートしてるのか？静かになりましたね。
 
Реter Konow 「聖杯」のバリエーションを否定しているという厳しい現実に戻し、私の推論は、哲学への愛に燃え、「永久移動」や「タイムマシン」の発明で眠れない夜を過ごし、自らの天才を信じて苦しんでいる心が生み出したものだと示したいのです。
複雑化アルゴリズムを実装することはできないが、より正確に言えば、その「愚かな」バージョンを実装することができる。あるプログラムが、あるオブジェクトのパラメトリックな状態、イベント、プロセス、条件をランダムにスタンプし、同じランダムさの中で、それらを互いに複合化して...。は、それらを消去し、再び開始します。この奇妙な行動は永遠に続くかもしれないし、その目的は何なのか全く不明だ。結果はどうなったのでしょうか？ランダムな結果？そして、コンストラクタ関数の問題を覚えていますか？その実装をどう変えるか？全然、はっきりしないんですけど...。問題は、実装方法のわずかな変更によって、すべてのプロトブロック構造の「正当性」が完全に失われ、変更後の機能では使用できなくなることである。全ては、研究所や科学アカデミーが解決することを前提に、何年もかかる作業であり、最終的に何かが解決するわけではありません。
このフォーラムの雰囲気は、聖杯のインスピレーションで飽和し、適切な心のフレームを投げかけ、そこから後者は驚くべき、科学のようなたとえ話を生成します、残念ながら、決して実用的な何かにつながることはありませんが...。...元気が出ますが。:)
あまり厳しく判断しないでください。"哲学的なオチ "になってしまったので)))

もしあなたが突然、認知的な気分の心境になったら、遺伝子プログラミングについて読んでみて ください（ネタバレ：バッカス・ナウロスなしにはできません）。

1...1011121314151617
新しいコメント
理由: