取引環境に対応する際の典型的な間違いとその対処法 - ページ 2

新しいコメント
 

fxsaber:

ラップの必要性を示す機能を赤色で表示しています。その問題点については、こちらで 解説しています。これは、古くはポジションの再オープンの問題で、OrderSendの後にポジションがオープンするのを待つSleepで解決していたことを思い出す人もいるかもしれません。しかし、実はこの問題はOrderSendとは関係がない。取引環境を正しく読み取ることが必要です。

右は簡単な例です。

オーダーリストは、ポジションリストと同様、瞬時に更新されるものではありません。Sleep-crutchがないとダメだと思う。

おそらくより正しいのは、 OnTradeTransaction です。

 
Aleksey Lebedev:

注文のリストは、ポジションのリストと同様、瞬時に更新されるわけではありません。imhoは、Sleep-crutchなしではやっていけない。

おそらく、 OnTradeTransaction を使用するのがよいでしょう。

環境アップデート待ちの問題がある場合、スリープはどのように対応すればよいのでしょうか？それが役に立つか立たないか。

つまり、ポジションを開く注文や保留中の注文を送った後は、その結果を待って、それ以上開く注文や設定する注文を送らないという、逆のアプローチになるはずです。そのため、プログラム実行の遅延を与えるだけで、プログラム自身が送信した取引要求の結果をチェックしないスリープを信頼する代わりに、我々自身が管理するフラグが必要です - フラグを設定し、結果を待つ論理に従って動作するようにします。結果待ちの後、フラグを削除する。

 
Artyom Trishkin:

質問：取引注文を出した後、次のティックまでサーバーが成行注文を出さなかった場合、どうなりますか？

MT4と全く同じになり、何もなければカウントされません。


このような取引注文には、いくつかの理由が考えられます。

  1. サードパーティのOrderSendまたはOrderSendAsync - 取引環境を読み込むプログラムからのものではありません。プログラムを実行している端末からでない場合もあります。この場合、何もできない。このような状況でも、全てはMT4と同じです。
  2. OrderSend または OrderSendAsync - は、取引環境を読み込むプログラムから起動されます。OrderSendの場合、OrderSendは明確な結果を持って実行を終了するので、すべてが明確である。OrderSendAsyncの場合、最初のパラダイムに従って 次のイベントにデータを渡すか、MT4の通常の非同期データ転送シミュレーション（マルチスレッド実装）で行われているようにOrdersAsyncWait()（コードを持っていない）を行うか、2通りのことができます。
MT4のOrderSendAsyncについて、少し触れておく必要がありそうです。プログラム実行のどの段階でも、対応する取引スレッドがどれだけ忙しく、何をしているかを確認することができます。この意味で、MT4のカスタム非同期は、MT5のものよりもはるかに多くの可能性を与えてくれます。しかし、MT4では、各チャートで「クライアント」を実行することで実装されており、すなわち高価なものです。MT5では、OBJ_CHARTオブジェクトでスクリプトを実行することにより、同じ機能を記述することが可能であり、多くのチャートがなくても、わずかな遅延が発生します。つまり、OrderSendAsyncCustomはOrderSendAsyncより若干遅くなりますが、それでもOrderSendよりはるかに速く、カスタム実装のすべての利点を享受することができるのです。
 
Aleksey Lebedev:

注文のリストは、ポジションのリストと同様、瞬時に更新されるわけではありません。imhoは、Sleep-crutchなしではやっていけない。

おそらく、 OnTradeTransaction を使用するのがより正しいでしょう。

MqlTradeTransactionは、OrderSendAsyncで作業する際に適切なパラダイムを選択する場合にのみ必要となる場合があります。その他の場合、OnTradeTransaction==OnTrade となり、OnTick や OnTimer と同じ役割を果たす。


トレーディング、自動売買システム、ストラテジーテストに関するフォーラム

取引環境での作業における典型的なミスとその修正方法

fxsaber さん 2018.02.19 22:36

EAを書くという取引環境での作業には、2つのパラダイムがあります。

  1. イベント入力（OnTick、OnTimerなど）は、互いに依存しあっています。イベントとイベントの間には、（キャッシュのようなスピードのためではなく、ユーザビリティのために）必ず持っていなければならない情報があるのです。例えば、OrderSendAsyncの結果を保存し、OnTradeTransactionで 使用する必要があります。キャッシュは必須情報ではなく、高速化のためにのみ使用されます。だから、すぐには検討しないのです。
  2. イベント入力（OnTick、OnTimerなど）は、互いに依存しません。各入力はゼロからです。大雑把に言うと、イベントごとに自分で実行するスクリプトの ようなものです。

ハイライトは、各 On ファンクションで同じトレードコードが 実行されていることを示します。対応するノントレーディングコードで、それ以外はすべて完結します。

 
fxsaber:

MT4と全く同じになり、何もなければカウントされません。

つまり、次のカチカチ音で、プログラムは新しいオープニングのリクエストを送ります。その結果、同じような問題、つまり複数回の開封が発生してしまうのです。

Expert Advisorは以下のようなロジックを持つ必要があります。

  1. ポジションを建てる、または保留注文を設定 するシグナルを取得します。
  2. 注文/ポジションの数を確認し、新しいポジションを開くための信号がない場合 - 終了（ステップ1について）。
  3. サーバーの応答待ちフラグを確認する。
    1. フラグが立っている - 終了（ステップ1へ）
    2. フラグ省略-継続
  4. フラグが省略された場合 - 取引注文を送信し（試行回数に制限があります）、リターンコードを確認します。
    1. 注文が実行された - 待機フラグを設定する
    2. 注文が失敗 - 取引注文修正機能を呼び出し、ポイント4へ進む。
  5. 待機フラグが立つ - 取引環境の変化を確認する
    1. 取引環境に変化がない-終了（ステップ1へ）。
    2. 環境変化 - 保留注文の発注またはポジションの開設 - 待機フラグを外し、終了（ステップ1へ）。
 
Artyom Trishkin:

つまり、次のティックでは、ソフトウェアが新しいオープニング要求を送信します。その結果、同じような問題、つまり複数回の開封が発生してしまうのです。

全文を読むと良いと思います。

EAは以下のようなロジックを持つことが望ましい。

  1. ポジションを建てる、または保留注文を設定 するシグナルを受信しました。
  2. 注文/ポジションの数を確認し、新しいポジションを開くための信号がない場合 - 終了（ポイント1へ）。
  3. サーバーの応答待ちフラグを 確認する。
    1. フラグが立っている - 終了（ステップ1へ）
    2. フラグ省略-継続
  4. フラグが省略された場合 - 取引注文を送信し（試行回数に制限があります）、リターンコードを確認します。
    1. 注文が実行された - 待機フラグを設定する
    2. 注文が実行されない - コール機能で取引注文を修正し、ポイント 4 に進む。
  5. 待機フラグが立つ - 取引環境の変化を確認する
    1. 取引環境が変化していない - 終了（ステップ1へ）。
    2. 環境変化 - 保留注文の発注またはポジションの開設 - 待機フラグを外し、終了（ステップ1へ）。

waitフラグは、2番目のケースと OrderSendAsyncでのみ使用可能です。OrderSend については、wait フラグは全く必要ない。待機フラグのないOrderSendAsyncはOrdersAsyncWait()となります。

どんな理論も実践で確認することができます。

実践的な結果で導く。
 
fxsaber:

投稿の全文を読むとよいでしょう。

待機フラグは、2番目のケースと OrderSendAsyncの場合のみ可能です。OrderSend については、wait フラグは全く必要ない。待機フラグのないOrderSendAsyncはOrdersAsyncWait()となります。

どんな理論も実際に試してみることができる

私は、実践的な結果によって導かれているのです。

まあ、非同期モード用に書いたんですけどね。synchronousでは待つ必要はありません。結果はクエリのレスポンスの中にすでに存在します。

 
Artyom Trishkin:

そうですね......非同期モード用に書きました。

最初から詳細な回答 があった。

 
fxsaber:

冒頭から延々と答えが 続く。

私の読み方が悪かったのでしょう :)

マルチディスカバリーエラーを回避するための手順は見当たりませんでした。一般的な「パラダイム」のみ ;)

フラグは、ポジションをオープンしたり、保留中の注文を設定する関数（ラッパー）の中でチェックされます。あるいは、信号追跡機能にもあるかもしれません。

ベストな方法を考えなければならない。

 
Artyom Trishkin:

フラグがチェックされるのは、ポジションをオープンしたり、保留中の注文を配置したりする機能（ラッパー）です。あるいは、信号追跡機能にもあるかもしれません。

私は、OrdersAsyncWait()による解決策をはるかに好みます。そうすると、まっさらな状態で次に読む取引環境は、できるだけ関連性の高いものになります。

OrderSendAsyncの使用は 常に適切であるべきです。唯一起こりうる状況は、同じシグナルで互いに独立した複数の（＞1）取引注文を送信することです。したがって、OrderSendAsyncというのは、他のすべてのケースで決して意味をなさない。


SZZY OrderSendAsyncが非常に関連する別のトピックがあります - マルチアドバイザー：1つのExpert Advisorで複数の独立したTSです。そこではOrderSendはほとんど適さないし、OrderAsyncWait( const string Symb) も原則的にSleepが許されないのでよくない。

12345678910
新しいコメント