1

これは主に理論的な質問です (ただし、サンプル コードは常に歓迎されます)。

本当の問題は、複数のカスタム インジケーターから複数のシナリオをテストする EA の「フレーム」を正しくコーディングする方法です。

私が (忙しい) EA を構築する方法は、1 つの戦略にあまり焦点を当てていませんが、複数の戦略を「テスト」し、最も適切なものを「選択」しようとしています。

そのため、すべて「ステータス データ」の配列を返すいくつかのカスタム インジケーターを作成しました。

たとえば、次の指標があります。

  • クロス移動平均インジケータ, 平均がクロスされたときにシグナルを発し、現在の位置が MA から移動したパーセンテージで示されます.
  • ボリンジャー バンド インジケーター。バンド間の「余裕」を返し、バンドが「圧迫」を開始したときにシグナルを出します。
  • 複数の時間枠の「方向/トレンド」インジケーター(上昇または下降に向かって移動する特定の時間枠です)。これは現在の方向を返し、時間枠の方向が変化した場合にシグナルを発します。
  • 「小規模な」動きをチェックし、最良の売買ポイントを選択するためのADX インジケーター。

巨大なシナリオを 1 つ書くこともできますが、もっとうまくできると思います。たとえば、すべての時間枠が下降している場合 (下降トレンド)、多くの下降の動きを処理するための特別なシナリオを用意できます。しかし、現在の傾向がない場合は、別のシナリオが最適です。

なので、複数のシナリオを作るのがベストだと思います (まだ 1 EA です)。最初にすべてのカスタム指標データが収集され、次に各シナリオがそのデータを使用して計算を行います。次に、「スコア」を返し、最高のスコアが選択されます。

しかし、コードを最適な「概要」の方法でレイアウトするにはどうすればよいでしょうか?

シナリオごとにクラスを作成し、データを使用して手動で「チェック」する必要がありますか? そして、それらを複数のファイルに分割するだけ#includeですか？

それともイベント駆動型ですか？リスナーを特定の指標イベントに対して実行、計算、および設定し続け、独自の方法でそこに移動するクラスを作成しました (それは素晴らしいことです)。

どんな考えでも大歓迎です！

アップデート2016-01-11,12:00

今は UML を作成する時間がありません..しかし、私は今のところ次のことを行います ->

  • Order(Orderシングルトンで、注文リクエストを実行するだけです)
  • Indicator(各指標が拡張する基本クラス)

  • Strategy(各戦略が拡張する基底クラス)

  • IndicatorFetcher(すべてのインジケーターを保持し、各ティックで実行されます)

  • StrategyRunner(すべての戦略を保持し、各ティックで実行されます。IndicatorFetcher)

各StrategyインスタンスはIndicatorFetcher(すべてのインジケーターのデータを含む概要を保持し、Orderシングルトンを使用して取引を実行する) へのアクセスを取得します。

4

3 に答える 3

1

複雑なシナリオでは、各シナリオをクラスに分割すると便利です。クラスは、相互に作用するタスクとデータに分けられます。インジケータは、Monitor-Task に供給される Data-class 内にラップできます。複数のモニター クラスに反応する大き​​なアクション タスク クラスを作成できます。

于 2015-12-21T02:02:54.140 に答える
1

. . . 忍び寄る件名についてのコメント StackOverflow は、ユーザーが関連する質問

を投稿することを奨励しています。、特にドメインは、狭帯域の専門化と問題ドメインの最終的な利益志向の動機に関して非常に具体的です。とは言うものの、StackOverflow は、トレーディング戦略の開発努力のハイレベルなアーキテクチャと開発戦略を議論するのに最適な場所ではないようであり、自己構成した強硬派の政策執行者からの強い否定的なフィードバックに時折直面するかもしれません。MCVEMCVE

algorithmic-tradingquantitative-financeMQL4



上記のすべてが言及されましたが、質問の最後の更新により、主題は、前述の理論的に促進されたStackOverflowの理想からさらに一歩遠ざかりました。( ... 警告されました )



アドホックな最終更新:
クラス継承とシングルトン + その他のパタ​​ーン アーキテクチャについて


ソフトウェア エンジニアリングの伝道理論やベスト プラクティス指向ではないいくつかの事実を再考するかもしれませんが、クオンツ モデリングにとって非常に基本的なものであり、トレーディング ドメインがすべてです。

- OOD/OOP理想は、言語の制限された拡張性に苦しむ可能性があり、またそうなるでしょうMQL4(はるかに!C++ )

- 他のドメインで一般的なデザインパターンは、MQL4イベントトリガーの制限されたコード実行機能の下で機能する必要はありません (mainloop()カスタムが追加された類似の構造を制御する手段がありません)また、外部イベントインジェクターの「MQL4ハングアップ」だけで動作する「実行可能な」MVC に似たフレームワークを設計しようとすると、実際に多くの問題があります。OnTick()

strategyStrategyTester量的モデリングおよび最適化サービスのフレームワーク全体を荒廃させます。実際にクオンツ モデリングのポートフォリオ集約戦略に興味がある場合は、これを行うための他のツールがありますが、コーディングのMQL4ボトムアップではないことは間違いありません。

- 同じプロセスの下で多くの戦略を組み立てても、文字通り何のメリットもありませんが、実行されないリスクがXTOあります - 操作は制御不能であり、指数関数的に増大します。

最初のメモ:アーキテクチャは敵です(コードの「レイアウト」ではありませんMQL4) 。

MetaTrader Terminal 4以前の質問で説明したように、コード実行エコシステムが最適なロードマップであるかどうかを正しく理解することです。

MT4 でのプロセス管理の制限事項

これは、大規模なプロジェクトの中核となるアルファとオメガです。

GUI-Finite-State-Automaton レイヤーを使用して MT4 イベント スキームの上に GPU / GPU グリッド / ハイブリッド デュアル イベント コントローラーを実行し、実際の状態を分散バックエンド処理に供給して、本当に高速な MQL4-EA を実現します。これらの壮大なプロジェクトはすべて実行可能であり、共有リソースの使用の安定性 (競合状態の回避) と主にノンブロッキング設計 (優先される同時実行の側面としての衝突の回避) に適切な注意が払われているため、正常に機能します。

MT4 でのプロセス管理の制限の概要については、この投稿を確認してください。

#includeか#includeどうか？(それは質問です...)

デンマークの王子であるハムレットに頼まなくても、#includeディレクティブはコードベースの準備ができていますが、それだけではすべてのストレスを効率的に処理できるわけではありません。

数百人*年を少し超えるコードベースの開発と保守を提供した経験に基づいて、 は何でも屋で#includeはありません。

よく考えられた選択 ... IDE にいくつかの自作のレクサーと構文バリデーターを加えたもの... が鍵となります。なぜなら、これはチームの真の生産性向上ツール (または、悪い選択をした場合はパフォーマンス ブレーキ) だからです。

この投稿でこれに関するいくつかのメモを読むことを躊躇しないでください

最後のコメント:

最初の投稿は「何か巨大なものをプログラムする方法」
に動機付けられていましたが[少しシャープなコントラストとメリットに焦点を当てるという名目で行われた、故意に過度に単純化したことをご容赦ください] IMHO
MQL4



トレーディングにはまったく異なる目標があります - それは営利目的の規律で
あり、コードを設計する前に定量的手法
が通常使用されますが、その逆ではありませんこれは 定量的にモデル化されたトレーディング戦略を意味します私はむしろそれを TruStrategy であると宣言することを好みます.5次元のポリシーのフィールドです.コードの実装が開始される前に アプリオリな感覚[利益を生み出すパフォーマンス]を提供する.アプリオリではなくアドホック





{ S, D, A, A, T }




-最終的に巨大なレガシーコード、スマート（er）-OODコード、または小さくて十分なコードになる. すべての 5 次元(イベントの頻度、シグナル検出の複雑さ、アルファ、ベータ、およびブラック スワン ファクターに対する感度、オンザフライで並行して管理される取引の数だけでなく)

で既知の TruStrategy の動作がなければ1 つタイトなリアルタイムイベントフロー制御ループ内でナノ秒を探しているか[HFTスペクトルの終わり近くに配置されている場合]、非進化モデルの維持に費やされる時間/日を削減するために戦っている[ペタバイトの静的データが最初に非凸型の適応型 AI/ML モデル用に処理される







GridSearch相互検証ミニマイザーは、機械の連合に最も適したメンバーを選択することであり、週に 1 つまたは 2 つの成功トレードの機会を確実に予測できます]

信じられないかもしれませんが、結果のコードは大きく異なります。 ..

于 2015-12-18T13:38:52.340 に答える