mql4言語の特徴、微妙なニュアンスとテクニック - ページ 35

[Andrei Trukhanovich]

fxsaber #:

そこで今、どうすればすべての注文を一度に処理できるかを考えています。

どうしたらいいのかわからないのですが、そういうズレが致命的な結果につながらないような書き方を心がけています。

確率は下がりますが、アカウント管理の多様化・煩雑化を差し引いての話です。

[fxsaber]

Andrei Trukhanovich #:

あるいは、ボットを異なるアカウントに分散させる。

そして、例えば、プットアウェイ・オーダーの期限切れを禁止する。一般的には、松葉づえ。

そんな不幸なクセのある基本的な必要性。どうやら、スナップショットでどうにかするためのようです。

[Igor Makanu]

fxsaber #:

詳しいお返事ありがとうございました今、すべての注文を一度に処理する方法を考えています。

最初と最後の注文（チケット）を覚えておくのはどうでしょうか？

で、サイクル終了後、最初のオーダーと最後のオーダーがカウント前と同じチケットであることを確認します。

   int n  = OrdersTotal();
   
   if(n == 0) return(0.0);
   else if(n == 1 && OrderSelect(0, SELECT_BY_POS)) return(OrderLots());
   
   int t_last = OrderSelect(n - 1, SELECT_BY_POS) ? OrderTicket() : -1;
   int t_first = OrderSelect(0, SELECT_BY_POS) ? OrderTicket() : -1;

SZY: 論理的には、OrderSelect() がこの衝突に責任を持つはずです。注文のテーブルが変更された場合には false を返すはずですが、フォーラムで OrderSelect() が false を返したという記事を読んだ記憶がありませんし、私は OrderSelect() のエラーハンドラに出会ったこともありません。

[fxsaber]

Igor Makanu #:

は、最初と最後の注文（チケット）を覚えていることができますか？

チケットの並びを完全に記憶していないと、このような解決策は失敗します。

[Igor Makanu]

fxsaber #:

チケットの順番を完全に覚えていないと、この解決策は失敗します。

また、チケットの完全保存は、ループを回している間に、すでに処理されたオーダーの状態が変化する可能性があるため、失敗の原因になります

もちろん、よくわかりませんが、サイクルに入っているときに注文がクローズされると、OrderTotal()が変化します。

オーダーがクローズされ、新しいオーダーがオープンされた場合、チケットとオーダーセレクト(0)またはオーダーセレクト(オーダートータル()-1)が変更されます。

また、以前の「極端な注文」やOrderTotal()自体を残すには、どのような状況が起こり得るとお考えでしょうか？

[fxsaber]

Igor Makanu #:

また、同じ「極端な注文」とOrderTotal()自体を維持するために、どのような状況が起こり得るか、ご意見をお聞かせください。

ほとんどの場合、注文テーブルが揺れるとOrdersTotalが変化する。

そして、リミッターが補充され、さらにポジションが生まれる可能性があります。

[Andrei Trukhanovich]

Igor Makanu #:

は、最初と最後の順番（チケット）を記憶することができるのでしょうか？

一を念ずれば通ず

[Taras Slobodyanik]

fxsaber 関数が呼ば れる前と後に存在したいくつかの順序を見逃すことは理論的に可能でしょうか？それとも2回カウントされるのでしょうか。

つまり、オーダーが削除されたり、列挙中に現れたりした場合、インデックス作成はどうなるのでしょうか？

チケットの配列を集めて作業しています。
OrdersTotal、Balance、Marginが変更された場合、リストを再作成する必要があります。

そのため、EAは常に自らが選択したチケットのみで動作します。

[Igor Makanu]

Andrei Trukhanovich #:

一念発起

これらは、アーキテクチャの実装の特殊性であり、文書化されておらず、誰も将来的に保証することはできません。

注 OrderTotal()とOrdersHistoryTotal()は、最後のオーダーのチケット

ループ内の計算の結果、これらの値が変化した場合、処理

しかし、普遍的で信頼できる解決策はありえません。ここでの課題は、サーバーで何が起こるか、データがネットワーク経由でどのように配信されるか、そして端末の隣接チャートで何が起こっているかを推測することです ))) 。）

期待するのはOrderSelect() の速度だけです。私の記憶が正しければ、1秒間に100万回以上の呼び出しが あるはずです

[Valeriy Yastremskiy]

fxsaber #:

発券の一連の流れが完全に記憶されていなければ、このようなソリューションは失敗します。

覚えておくにはお金がかからないかもしれませんが、フルステータスを把握するにはお金がかかるかもしれません。前の方と同意見で、合理性と優先順位の論理で負荷を減らしてください。

私たちが住む非同期の世界では、リクエストの順番に対するレスポンスの順番は保証されないし、順番も全く保証されない。