構造のルール プログラムの構成方法を学び、可能性、エラー、解決策などを探る。 - ページ 18

[Mykola Demko]

C-4:

ウラジミール、君の回路では難しいんだ。ドライバを書き換えるだけでいいということですか？でも、プラットフォーム依存のパーツはもっとたくさん数えていますよ。

マーケットヒストリーやトレードヒストリーはどのように取得するのでしょうか？また、現在位置の情報は、ひょっとして端末からは取得しないのでしょうか？また、ボラティリティモジュールを実装しなければならない場合、プラットフォームに依存するAPIが1つ増えることになります。

アダプターは書きますか？何人くらいになるのでしょうか？つまり、モジュールの数は2倍、プラットフォーム依存のコードの量は同じになります。

そういう問題意識はない。

ただ、赤色は非常に安定しており、プラットフォームから来るすべてのものは、あなたが別のプラットフォームのために必要な場合は、確立されたAPIもあり、問題なく書き換え、長年にわたって変更されていません。

しかし、緑色の矢印のついたモジュールはすべて独自のものであり、ほとんど常にアクティブな手直しです（理想には限度がありません）。

方向予報士が書かれ、その後、深化拡大という新しい発想が生まれ、まあ、今のように買いですが、売りの準備をし、徐々に量を減らしていくしかありません。

そこで、2つのモジュールを使うようにしました。

MMコレクターもダイナミックなスキームで、今はポジションで動作していますが、突然アイデアが浮かんで、ロングポジションに変更することにしました（スムーズなマーケットエントリー）。

Market Driverはプラットフォーム依存のAPIに出力するため、形式は明確で安定しているはずだが、APIは多くの可能性を提供するため、多くのねじれが生じるだろう。

[Vladimir Gomonov]

Urain:

そういう問題意識はない。

ニコライ 君の投稿は非常にセンシティブだが、私は提案されたスキーム（の普遍性）を弁護するつもりだ。

ただ、赤色のものは非常に安定しており、プラットフォームから来るものは何年も変わっていませんし、他のプラットフォームで必要な場合は、確立されたAPIもあり、書き換えは問題ありません。

この方式で重要な考え方のひとつは、プラットフォームに依存する部品の数ではなく、それらを厳密に局在化させることです。つまり：TS自体（予測因子+ MM-モジュール） - それは、プラットフォームに依存しない設計ですが、データソースは、指標と市場ドライバ、それぞれ依存（推奨補正器の入力に供給取引履歴、 - も本質的に指標である）です。

その結果、明確に区別され、重複のない、限定された介入領域が生まれました。

1.マイグレーション。

2.TSの改善、特にスケーリングの改善。

しかし、緑色の矢印がついたモジュールはすべて自社製品であり、ほとんどの場合、積極的に再設計されています（理想には限度がありません）。

しかし、プラットフォームに依存する部分と依存しない部分のスキームを慎重に修正すれば、例えば現在の状況では、プラットフォームに依存するEAでは本当に面倒な、両方のプラットフォーム（MT4/5）のEA 開発に簡単に対応することができるようになるのです。

方向予報士が書かれ、その後、深化拡大という新しいアイディアが生まれ、まあ、今のように買いですが、売りの準備も必要で、徐々に量を減らしていきます。

そこで、2つのモジュールを使うようにしました。

このスキームでマークされたコンポーネントの中に、モジュールがいくつあってもかまいません。 それはそれでいいのですが、明確なパイプラインの配置だけが有用だと思います。 やむを得ない場合以外は、コードの中で混在してはいけないもの、すなわち、「モジュール」です。シャッフルはできるだけ避けるべきです。 これにより、マルチツールに向かってスケーリングする際に、常に明確で便利な モジュールのドッキングポイントを持つことができます。 この角度からスキームを見ると、自分自身で発見することができますよ。

MMコレクターもダイナミックなスキームで、今はポジションで動くが、突然賢くなってエクイティ（スムーズな相場入り）に変更することにしたのです。

上記参照 // しかし、MM補正器の入力は、単一通貨（より正確には単一商品）のフォーキャスターのクラウドを多通貨（多商品）のキッチンに統合するのに一番便利なポイントです。

Market Driverはプラットフォーム依存のAPIに出力するため、形式は明確で安定しているはずですが、APIが多くの機能を提供するため、多くの混乱が発生します。

しかし、もしこれらの直接的なAPIコールがドライバにローカライズされず、プレディクタやMMモジュールのコードと混在するとしたら...............と考えてみてください。

;)

[Mykola Demko]

MetaDriver:
ニコライさん、あなたの投稿はとても賢明なものですが、私は提案されたスキーム（の普遍性）を守ることを引き受けます。

このスキームで重要なのは、プラットフォームに依存するパーツの数ではなく、それらを厳密にローカライズすることです。つまり：TS自体（予測因子+ MM-モジュール） - それは、プラットフォームに依存しない設計ですが、データソースは、指標と市場ドライバ、それぞれ依存（推奨補正器の入力に供給取引履歴、 - も本質的に指標である）です。

その結果、明確に区別され、重複のない、限定された介入領域が生まれました。

1.マイグレーション。

2.TSの改善。 特に、スケーリング。

しかし、プラットフォームに依存する部分と依存しない部分の区分けを丁寧にこなしていけば、例えば現在の状況では、プラットフォームに依存した取引システムでは面倒な両プラットフォーム（MT4/5）のEA開発にも簡単に対応できるようになるのです。

このスキームでマークされたコンポーネントの中に、モジュールがいくつあってもかまいません。 それはそれでいいのですが、明確なパイプラインの配置だけが有用だと思います。 やむを得ない場合以外は、コードの中で混在してはいけないもの、すなわち、「モジュール」です。シャッフルはできるだけ避けるべきです。 これにより、マルチツールに向かってスケーリングする際に、常に明確で便利な モジュールのドッキングポイントを持つことができます。 この角度からスキームを見ると、自分自身で発見することができますよ。

しかし、MM 補正器の入力は、単一通貨（より正確には単一商品）予測器のクラウドを多通貨（多商品）キッチンに統合するのに一番便利なポイントです。

しかし、もしこれらの直接的なAPIコールがドライバにローカライズされず、プレディクタやMMモジュールのコードと混在するとしたら.......................。

;)

よし、これをベースにしよう（ただしストップモジュールは追加しよう、合理的だと思うし、誰も異論はないだろう）。

とか、この図式に足りないものはないかとか、やり直しとか。

[Vladimir Gomonov]

Urain:

よし、これを基本にしよう（ただし、合理的と思われるし、誰も異論がないので、ストップを扱うためのモジュールを追加しよう）。

で、この回路に他に何が足りないかを考えたり、作り直したりしてください。

リワーク・インプルーブメントを考えてみる（料理させる）。

この方式にはGUI（ビジュアル・モニタリング/コントロール・サブシステム）が明らかに欠けています。 Expert AdvisorとGUIとのインタラクションの統一された （そして便利な！）方式を開発したいのです。 今のところ、私はこの問題に関して自発的で、本当に困ったものです。同じ目標（双方向の完全なデータ抽象化）を達成したい。だからこそ、トレーニングのためにEA/GUIインターフェイスのタスクを提案したのですが、メルカリ的に興味があるので、一般の方からアイデアをいただきたかったんです。

[Vasiliy Sokolov]

MetaDriver:
このように、スキーム・コンポーネントの中にいくつものモジュールが入っていても構いません。 これは普通のことです。 ただ、パイプラインの配置が明確であることが重要です。 どうしても必要な場合以外は、コード内でシャッフルしてはいけません。このため、マルチツールに向かってスケーリングする際、常に明確で便利な ドッキングポイントを持つことができます。 この角度から図を見て、あなた自身がそれを見つけることができるでしょう。

無制限のモジュールスプロールは、将来的に深刻な問題を引き起こします。Expert Advisorのロジックは、実質的に異なるモジュールに分散していますね。モジュール自体が相互に作用し、モジュール間のリンクがもつれにならない保証はない。緑色で表示されているマスは、すべて1つのトレーディングシステムの要素である。異なるモジュールに分解することは、プログラミングの大原則の一つである、一つのタスクの中にデータやメソッドをカプセル化することに違反します。

みなさんが自分のスキームを公開し始めたので、私も続けてみます。今回は、さらに抽象的なスキームです。

黒い矢印は厳密な関係を表しています。灰色のものは、モジュール内部のプライベートな相互関係で、重要ではありません。また、取引ロボットクラスは、プラットフォームAPIに直接対応できますが、プラットフォームへの依存性は低くなります。

[Mykola Demko]

C-4:

無制限のモジュールスプロールは、将来的に深刻な問題を引き起こします。Expert Advisorのロジックは、実質的に異なるモジュールに分散していますね。モジュール自体が相互に作用し、モジュール間のリンクがもつれにならない保証はない。緑色で表示されているマスは、すべて1つのトレーディングシステムの要素である。異なるモジュールに分解することは、プログラミングの大原則の一つである、一つのタスクの中にデータやメソッドをカプセル化することに違反します。

みなさんが自分のスキームを公開し始めたので、私も続けてみます。今回は、さらに抽象的なスキームです。

黒い矢印は厳密な関係を表しています。灰色のものは、モジュール内部のプライベートな相互関係で、重要ではありません。また、取引ロボットクラスはプラットフォームAPIに直接アクセスする権利を持っていますが、これではプラットフォーム独立性が損なわれてしまいます。

もし、APIにアクセスするのがaccessモジュールであればどうでしょうか？ そうすると、1つのモジュールを変更することでプラットフォームを変更することが可能になります。

[Mykola Demko]

MetaDriver:

再設計・改良の面では、考えてみる（醸造させてみる）。

この方式にはGUI（視覚的なモニタリング/制御サブシステム）が明らかに欠けています。 Expert AdvisorとGUI間のインタラクションの統一された （そして便利な！）方式を開発したいのです。 今のところ、私はこの問題に関して自発的で、本当に迷惑しています。同じ目標（双方向の完全なデータ抽象化）を達成したいです。だからこそ、トレーニングのためにEA/GUIインターフェイスのタスクを提案したのですが、メルカリ的に興味があるので、一般の方からアイデアをいただきたかったんです。

タスクから行く。GUIで最も要求される作業は何でしょうか？

そこから先は得たいものを記述し、共通の見出しを選び、枠組みを作り、さらにいろいろなものを追加し、枠組みの変更のしやすさを確認する。

そして、どうあるべきかを理解し、もう一度書き直します。私はそのように考えています。

[Andrey Khatimlianskii]

MetaDriverの 言うことは正しいし、彼のシステムも正しい。Dick_fxは、「トレーディングドライバー」は10～20のプラットフォームで動作し、最適な価格を使用する必要があることも付け加えます。

しかし、このような正しいシステムの使用は、理想的な条件下でのみ便利です。戦略に誤りがない、ユーザーの介入がない、不可抗力がない...。そして、現実にはそのようなことはほとんどありません。

dick_fxの例を挙げましょう。25のストラテジーが機能しており、アグリゲーター（トレードドライバー）がそれらをネットポジションに集め、マーケットに投入し、全てOKです。突然、17番目のストラテジーがおかしくなって、不健全な予測をするようになりました。Expert Advisorは素直に開く。

MT4のような些細なロッカーは何をするものなのか。

• はチャートから17番目のEAを削除します（ディール内のマジコンで簡単に見つかります）。
• 対応するポジション（MT4 の場合）またはポジションの一部（MT5 の場合）をクローズします。
• は、このEAで作成されたログを読み込んで状況を分析する。

では、「正しい会計」に話を移しましょう。トレーダーはエラー（50%の証拠金取引-明らかなロジックエラー）を修正するために何をすべきでしょうか？

• どのストラテジーがそれを生成したのか（どのように、ログから？）
• 適当なコードを見つけて編集してください（return(0)？）。
• または、ポジション集計ループで、必要なストラテジー（数字は間違えてはいけません！）の反対側に、continueと入れます。
• Expert Advisor をコンパイルする（MT4 の場合、最初にターミナルを閉じる か、コンパイル後に正しい設定を指定する）。
• 状況の分析-別の曲（戦略への分割と独自のログが提供されていない場合）。

問題は、どちらが簡単かです。明らかにMT4搭載のバリアント。

そして、何が安いのか？明らかに、Nettingのオプションです。

結論から言うと、どうなんでしょうか？MT4からGUIでマーケットドライバを作ること ;)

[Andrey Khatimlianskii]

そしてもうひとつ。

これはすべて「正しい」トレーダー、さらにはプログラマーの理屈である。自分の趣味で、預金量の多い口座でやるのであれば、しかたがない。

専門家の文章に触れてみると、誰も「正しい」文章を必要としていないことがわかります。トレーダーとカスタマーの混在は変更できないので、「彼らのために」と書かなければならない。

仕事を辞める」という選択肢は受け入れられる!=)

[Vladimir Gomonov]

komposter:

そしてもうひとつ。

これはすべて「正しい」トレーダー、さらにはプログラマーの理屈である。自分の趣味で、預金量の多い口座でやるのであれば、しかたがない。

専門家の文章に触れてみると、誰も「正しい」文章を必要としていないことがわかります。トレーダーとカスタマーの混在は変更できないので、「彼らのために」と書かなければならない。

仕事を辞める」という選択肢は受け入れられる!=)

ほぼ同意見です。 このスキームは、この仕事のために開発されたものではありません。自分用として。つまり、アウトプットはマーケットでも仕事でもなく、FX/為替で産業規模で取引することを想定しています...))。