受注サイクルの整理 - ページ 2 123456789...15 新しいコメント fxsaber 2017.09.11 20:25 #11 Andrey Khatimlianskii:なぜなら、価格は移動し、OnTickを新たに呼び出すたびに、同じ、リストの最初の、注文を新たに修正するための条件が満たされるからです。特に、5秒間の修正であれば、なおさらです ;)ここでも、関連性の問題に触れています。1回の注文で常に最新の状態になります。その他は、できれば最新のものを。一方、あなたのバリアントは、すべての注文が最新のものではありません。このような「バックボーン」は、複数の注文を扱うEAのロジックを壊してしまうことになります。1つのオーダーを持つシステムには何のメリットもなく、他をスポイルしてしまうのであれば、何の意味があるのでしょうか。言いたいことは理解したいが、できない。待ち時間が経過したら取引環境を更新する」という原則に問題があるとは思えません。注文を処理する前に、数量や価格からの距離でソートするのは正しいことです。しかし、フォーラムからコードをコピーした人が全員それを実装してくれるとは思わない方がいい。 その意味では、私のコードの方が安全です。まあ......初心者向けに書かれたものではありません。あなたと私は、ここでとてもよく話し合っています。 Andrey Khatimlianskii 2017.09.11 20:44 #12 fxsaber:ここでも関連性の問題が指摘される。1回の注文で常に最新の状態になります。その他は可能な限り最新にします。あなたの選択肢は、すべての注文が最新でないことです。実際のところ、どの程度？買い2枚オープン、ビッド1.2345、両者のSLは1.2344で。ネクストティック：ビッドが1.2350にあり、ファーストオーダーのSLを1.2349に移動し、セカンドは1.2344に留まるティックを待たずに：Bidは1.2375、第一注文のSLは1.2374に移動、第二注文はまだそこにある。もう一歩、Bidは1.2376、1順目のSLは1.2375に移動、2順目はそのままで。価格は1.2300まで戻り、両方の注文のSL（1.2374と1.2344）がトリガーされました［単純化するために、価格が飛躍的に1.2300に到達せず（そうすれば両方のストップがこのレベルに滑り込んだはず）、価格が徐々に上昇してきたとしますが、当社のEAは変更を加えるのに忙しく、この時点で何もできなかったのです）］。結果：1回目の注文で+30pips、2回目の注文で+0pips私のシナリオでは、1.2375か最悪1.2374で両方のSLが修正されたはずです。結論：両方の注文で+30pips。fxsaber意味が分かって嬉しいが、うまくいかない。待ち時間が経過したら取引環境を更新する」という原則は問題ないと思うのですが。あなたのアルゴリズムは、リストの最初の順番にこだわっている、それだけです。状況によっては、システムに悪影響を及ぼすこともあります（実際に遭遇したことがあります）。 fxsaber 2017.09.11 21:02 #13 Andrey Khatimlianskii:実際のところ、どの程度？2枚買いオープン、ビッド1.2345、両者のSLは1.2344で。ネクストティック：ビッドが1.2350にあり、ファーストオーダーのSLを1.2349に移動し、セカンドは1.2344に留まるティックを待たずに：Bidは1.2375、第一注文のSLは1.2374に移動、第二注文はまだそこにある。もう一歩、Bidは1.2376、1順目のSLは1.2375に移動、2順目はそのままで。価格は1.2300まで戻り、両方の注文のSL（1.2374と1.2344）がトリガーされました［単純化するために、価格が飛躍的に1.2300に到達せず（そうすれば両方のストップがこのレベルまで滑り込んだ）、価格が徐々に上昇してきたとしますが、当社のEAは修正に追われてこの時点で何も出来ませんでした］。結果：1回目の注文で+30pips、2回目の注文で+0pips私のバリエーションでは、1.2375か最悪1.2374で両方のSLが修正されたはずです。結論：両方の注文で+30pips。この例の各ステップでは、TSは取引 注文がなくても、その注文がどこにあるべきかを知っているはずです。つまり、TSはそのオーダーが今どこにあるかということに、何ら執着することはできないのです。あくまでも、自分の立ち位置を計算し、計算したものと取引環境を同期させ、取引注文を出すという処理です。しかし、あなたの例では、TSの結果は、OnTickがHighの価格に到着したかどうかに依存します。そして、正しいTSは、まさにその上であるべきなのです。彼女はそのような価格であったことを見ており（たとえその価格でのOnTickが見逃されたとしても）、したがって彼女のSLはそれに応じて置かれるべきなのです。そして、同期は100％その役割を果たします。そして、なぜ2枚目が止まっていると言い続けるのかが理解できない。同期ロジックがなくても、あなたのバリアントと同じように変更されます。NewTickイベントでOnTickが呼ばれるのではなく、通常の内部関数として呼ばれるような感じです。 Andrey Khatimlianskii 2017.09.12 04:38 #14 fxsaber:この例の各ステップでは、TSは取引 注文なしでその注文がどこにあるべきかを知る必要があります。つまり、TSは今オーダーがどこにあるのか、一切紐付けられないのです。あくまでも、自分の立ち位置を計算し、計算したものと取引環境を同期させ、取引注文を出すという処理です。そうなんです、彼女は知っているんです。しかし、それを同期させる時間がない。1つの修正が通過している間に価格がさらに動き、新しい計算条件が最初の注文を再び修正するよう彼女に告げるのだ。そして、これはよくあることです。fxsaberあなたの例では、OnTickが高値に来たかどうかで、TCの結果が変わります。そして、正しいTSはその丁度前にあるはずです。それは、そのような価格があった（たとえそれを持つOnTickが見逃されたとしても）、つまり、そのSLはそれに応じて置かれるべきであると見なします。そして、同期は100％その役割を果たします。それはない（例ではSLレベルの計算がなかった）。また、同期では時間がないため、仕事ができません（上図参照）。fxsaberそして、なぜ2枚目が立ち止まったままだと言い続けるのか、理解できません。同期ロジックがなくても、あなたのバリアントと同じように変更されます。NewTickイベントでOnTickが呼ばれるのではなく、通常の内部関数として呼ばれるような感じです。いつも通り、理解できました。しかし、修正中にすでに価格が変化しており、OnTickの強制呼び出しはすでに新しい価格で動作し、2番目の注文は最初のレベルのままである。エラーはありません。あなたの場合、具体的すぎるかもしれませんが（しかし、これもまた、実際にあったことなのです）。 fxsaber 2017.09.12 05:53 #15 Andrey Khatimlianskii:そうです、わかっているのです。しかし、同期させる時間はない。1回の修正が過ぎると、価格がさらに動き、新しい計算条件によって最初の注文を再び修正するように指示される。そして、これはよくあることです。あなたが考案した例では、このロジックを考慮しても追加損失が出ることはありません。では、例を挙げましょう。例えば、上昇した後、必要なプルバックでオープンするために、BuyLimitsをトレールするとします。Almost Lucky-TC.毎回Limitの山を引きずっていたら、お客様のオプションでプルバックがつかめません。まあ時代遅れの取引環境に基づいて取引注文を 出すのはおかしいんだけどね。しかし、あなたは頑なに（私のように）違う視点を守ります。 Andrey Khatimlianskii 2017.09.12 06:42 #16 fxsaber:まあ時代遅れの取引環境をもとに取引注文を 出すのはおかしいですけどね。しかし、あなたは頑なに（私のように）違う視点を守ります。2つの悪のうち、より少ないものを選ばなければならない。もちろん、指値が価格の後ろに伸びている例は、「1EA＝各方向1注文」のバリエーションで実装するのがよいでしょう。しかし、一般 的には、すべての注文を管理する方がよいでしょう。 fxsaber 2017.09.12 07:00 #17 Andrey Khatimlianskii:しかし、一般 的には、すべての注文を管理する方が正しいのです。つまり、現在の取引環境だけでTSが機能するという要件に賛成できないのですね。 Andrey Khatimlianskii 2017.09.12 08:03 #18 fxsaber:つまり、TSが現在の取引環境のみで機能するという要件に反対しているのですね。そのために、すべてのTCオーダーのコントロールを犠牲にしなければならないのなら、それは絶対です。想像してみてください。4台のトラックを所有しているとします。それぞれがA地点からB地点まで貴重な荷物を運んでいるのです。ルートを監視する必要があります。 1分ごとに1人と連絡を取るのと、2分ごとに全員と連絡を取るのと、どちらがいいでしょうか？2番目のケースでは、遅れが少し長くなり、ルートが間に合わないと4つとも少し遠回りしなければならないかもしれません。しかし、1台のトラックを運んで他の3台を失うよりは、全体としてビジネスにとってプラスになるはずです。 Stanislav Korotky 2017.09.12 08:14 #19 Andrey Khatimlianskii:そのために、すべてのTCオーダーの制御を犠牲にしなければならないのなら、絶対にそうします。例えば、4台のトラックを所有しているとします。それぞれがA地点からB地点まで貴重な荷物を運んでいるのだ。ルートをコントロールする必要があります。 一人と1分おきに連絡を取るか、全員と2分おきに連絡を取るか？2つ目のケースでは、遅延がやや長くなり、ルートが間に合わなかった場合、4つとも少し遠回りしなければならなくなる可能性があります。しかし、トラック1台を使って他の3台を失うよりは、全体としてはビジネスにとって良いことでしょう。+1.つまり、OrderModifyを直接呼び出す代わりに、(すべてのパラメータを含む)modifyコマンドを生成して、それを処理するキューに入れる、マネージャー的な存在に、order brute forceのループアナログが隠されている、というようなOOPアプローチでは、おそらく新しい発想は生まれなかったでしょう。このアイデアは、環境を分析するエンティティと、分析に基づいてアクションを実行するエンティティの間で責任（このコードでは、単一のループに詰め込まれている）を分割することです。 Andrey Khatimlianskii 2017.09.12 08:18 #20 Stanislav Korotky:おそらく、このアイデアは、OOPアプローチでは発生しないでしょう。オーダー検索を伴うループのアナログが、マネージャーのようなエンティティに隠されていて、オーダーモディファイを直接呼び出す代わりに、修正するコマンド（すべてのパラメータ付き）を生成してキューに入れ、それが処理されます。このコードでは、環境を分析するオブジェクトと、分析に基づいたアクションを実行するオブジェクトの間で、責任（このコードでは1つのループに詰め込まれている）を分担することである。このような事態を避けるためには、非同期命令を使用するしかない。さもなければ、実行されるコマンドのリストに対するループが残ってしまい、実際には、オーダーに対するループになってしまいます。待ち行列の状況でのみ、ある注文に関連する古い未実行注文を新しいものに置き換える規定を設ける必要があるのです。そうしないと、キューがオーバーフローして、オーダーがキューの外に送られてしまうからです。-時代遅れですね。 123456789...15 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
なぜなら、価格は移動し、OnTickを新たに呼び出すたびに、同じ、リストの最初の、注文を新たに修正するための条件が満たされるからです。特に、5秒間の修正であれば、なおさらです ;)
ここでも、関連性の問題に触れています。1回の注文で常に最新の状態になります。その他は、できれば最新のものを。一方、あなたのバリアントは、すべての注文が最新のものではありません。
このような「バックボーン」は、複数の注文を扱うEAのロジックを壊してしまうことになります。
1つのオーダーを持つシステムには何のメリットもなく、他をスポイルしてしまうのであれば、何の意味があるのでしょうか。
言いたいことは理解したいが、できない。待ち時間が経過したら取引環境を更新する」という原則に問題があるとは思えません。
注文を処理する前に、数量や価格からの距離でソートするのは正しいことです。しかし、フォーラムからコードをコピーした人が全員それを実装してくれるとは思わない方がいい。
その意味では、私のコードの方が安全です。
まあ......初心者向けに書かれたものではありません。あなたと私は、ここでとてもよく話し合っています。
ここでも関連性の問題が指摘される。1回の注文で常に最新の状態になります。その他は可能な限り最新にします。あなたの選択肢は、すべての注文が最新でないことです。
実際のところ、どの程度？
意味が分かって嬉しいが、うまくいかない。待ち時間が経過したら取引環境を更新する」という原則は問題ないと思うのですが。
あなたのアルゴリズムは、リストの最初の順番にこだわっている、それだけです。
状況によっては、システムに悪影響を及ぼすこともあります（実際に遭遇したことがあります）。
実際のところ、どの程度？
私のバリエーションでは、1.2375か最悪1.2374で両方のSLが修正されたはずです。結論：両方の注文で+30pips。
この例の各ステップでは、TSは取引 注文がなくても、その注文がどこにあるべきかを知っているはずです。つまり、TSはそのオーダーが今どこにあるかということに、何ら執着することはできないのです。あくまでも、自分の立ち位置を計算し、計算したものと取引環境を同期させ、取引注文を出すという処理です。
しかし、あなたの例では、TSの結果は、OnTickがHighの価格に到着したかどうかに依存します。そして、正しいTSは、まさにその上であるべきなのです。彼女はそのような価格であったことを見ており（たとえその価格でのOnTickが見逃されたとしても）、したがって彼女のSLはそれに応じて置かれるべきなのです。そして、同期は100％その役割を果たします。
そして、なぜ2枚目が止まっていると言い続けるのかが理解できない。同期ロジックがなくても、あなたのバリアントと同じように変更されます。NewTickイベントでOnTickが呼ばれるのではなく、通常の内部関数として呼ばれるような感じです。
この例の各ステップでは、TSは取引 注文なしでその注文がどこにあるべきかを知る必要があります。つまり、TSは今オーダーがどこにあるのか、一切紐付けられないのです。あくまでも、自分の立ち位置を計算し、計算したものと取引環境を同期させ、取引注文を出すという処理です。
そうなんです、彼女は知っているんです。しかし、それを同期させる時間がない。1つの修正が通過している間に価格がさらに動き、新しい計算条件が最初の注文を再び修正するよう彼女に告げるのだ。そして、これはよくあることです。
あなたの例では、OnTickが高値に来たかどうかで、TCの結果が変わります。そして、正しいTSはその丁度前にあるはずです。それは、そのような価格があった（たとえそれを持つOnTickが見逃されたとしても）、つまり、そのSLはそれに応じて置かれるべきであると見なします。そして、同期は100％その役割を果たします。
それはない（例ではSLレベルの計算がなかった）。
また、同期では時間がないため、仕事ができません（上図参照）。
そして、なぜ2枚目が立ち止まったままだと言い続けるのか、理解できません。同期ロジックがなくても、あなたのバリアントと同じように変更されます。NewTickイベントでOnTickが呼ばれるのではなく、通常の内部関数として呼ばれるような感じです。
いつも通り、理解できました。
しかし、修正中にすでに価格が変化しており、OnTickの強制呼び出しはすでに新しい価格で動作し、2番目の注文は最初のレベルのままである。
エラーはありません。あなたの場合、具体的すぎるかもしれませんが（しかし、これもまた、実際にあったことなのです）。
そうです、わかっているのです。しかし、同期させる時間はない。1回の修正が過ぎると、価格がさらに動き、新しい計算条件によって最初の注文を再び修正するように指示される。そして、これはよくあることです。
あなたが考案した例では、このロジックを考慮しても追加損失が出ることはありません。では、例を挙げましょう。
例えば、上昇した後、必要なプルバックでオープンするために、BuyLimitsをトレールするとします。Almost Lucky-TC.毎回Limitの山を引きずっていたら、お客様のオプションでプルバックがつかめません。
まあ時代遅れの取引環境に基づいて取引注文を 出すのはおかしいんだけどね。しかし、あなたは頑なに（私のように）違う視点を守ります。
まあ時代遅れの取引環境をもとに取引注文を 出すのはおかしいですけどね。しかし、あなたは頑なに（私のように）違う視点を守ります。
2つの悪のうち、より少ないものを選ばなければならない。
もちろん、指値が価格の後ろに伸びている例は、「1EA＝各方向1注文」のバリエーションで実装するのがよいでしょう。
しかし、一般 的には、すべての注文を管理する方がよいでしょう。
しかし、一般 的には、すべての注文を管理する方が正しいのです。
つまり、現在の取引環境だけでTSが機能するという要件に賛成できないのですね。
つまり、TSが現在の取引環境のみで機能するという要件に反対しているのですね。
そのために、すべてのTCオーダーのコントロールを犠牲にしなければならないのなら、それは絶対です。
想像してみてください。4台のトラックを所有しているとします。それぞれがA地点からB地点まで貴重な荷物を運んでいるのです。ルートを監視する必要があります。
1分ごとに1人と連絡を取るのと、2分ごとに全員と連絡を取るのと、どちらがいいでしょうか？
2番目のケースでは、遅れが少し長くなり、ルートが間に合わないと4つとも少し遠回りしなければならないかもしれません。しかし、1台のトラックを運んで他の3台を失うよりは、全体としてビジネスにとってプラスになるはずです。
そのために、すべてのTCオーダーの制御を犠牲にしなければならないのなら、絶対にそうします。
例えば、4台のトラックを所有しているとします。それぞれがA地点からB地点まで貴重な荷物を運んでいるのだ。ルートをコントロールする必要があります。
一人と1分おきに連絡を取るか、全員と2分おきに連絡を取るか？
2つ目のケースでは、遅延がやや長くなり、ルートが間に合わなかった場合、4つとも少し遠回りしなければならなくなる可能性があります。しかし、トラック1台を使って他の3台を失うよりは、全体としてはビジネスにとって良いことでしょう。
+1.
つまり、OrderModifyを直接呼び出す代わりに、(すべてのパラメータを含む)modifyコマンドを生成して、それを処理するキューに入れる、マネージャー的な存在に、order brute forceのループアナログが隠されている、というようなOOPアプローチでは、おそらく新しい発想は生まれなかったでしょう。このアイデアは、環境を分析するエンティティと、分析に基づいてアクションを実行するエンティティの間で責任（このコードでは、単一のループに詰め込まれている）を分割することです。
おそらく、このアイデアは、OOPアプローチでは発生しないでしょう。オーダー検索を伴うループのアナログが、マネージャーのようなエンティティに隠されていて、オーダーモディファイを直接呼び出す代わりに、修正するコマンド（すべてのパラメータ付き）を生成してキューに入れ、それが処理されます。このコードでは、環境を分析するオブジェクトと、分析に基づいたアクションを実行するオブジェクトの間で、責任（このコードでは1つのループに詰め込まれている）を分担することである。
このような事態を避けるためには、非同期命令を使用するしかない。
さもなければ、実行されるコマンドのリストに対するループが残ってしまい、実際には、オーダーに対するループになってしまいます。
待ち行列の状況でのみ、ある注文に関連する古い未実行注文を新しいものに置き換える規定を設ける必要があるのです。そうしないと、キューがオーバーフローして、オーダーがキューの外に送られてしまうからです。-時代遅れですね。