受注サイクルの整理 - ページ 3 12345678910...15 新しいコメント fxsaber 2017.09.12 08:18 #21 Andrey Khatimlianskii:そのために、すべてのTCオーダーの制御を犠牲にしなければならないのなら、絶対にそうします。例えば、4台のトラックを所有しているとします。それぞれが、A地点からB地点まで貴重な荷物を運んでいる。ルートを監視する必要があります。 1分おきに1人と話すのと、2分おきに全員と話すのと、どっちがいい？2つ目のケースでは、遅延がやや長くなり、ルートが間に合わなかった場合、4つとも少し遠回りしなければならなくなる可能性があります。しかし、トラック1台を使って他の3台を失うよりは、全体としてはビジネスにとって良いことでしょう。関連付けはありがたいが、トレードロジックにはならないようだ。この問題は根本的なもので、全く異なるTC構築の原則に触れているように思います。 Stanislav Korotky 2017.09.12 08:33 #22 Andrey Khatimlianskii:このような状況を避けるには、非同期命令を使用するしかないでしょう。そうでなければ、実行するコマンドのリストに対するループが残ってしまい、本質的にオーダーのループになってしまうからです。待ち行列の状況でのみ、ある注文に関連する古い未実行注文を新しいものに置き換える規定を設ける必要があるのです。さもないと、キューがオーバーフローして、キューから送り出されたオーダーが陳腐化する可能性があります。 不一致です。コマンドの実行を遅延させたキューは、すでに非同期を実現しています。コマンドループでは、新しい環境を見ているわけではありません。実際、特定のオーダーを修正するためのコマンドは、キューに1つしか存在できない。 Andrey Khatimlianskii 2017.09.12 08:40 #23 fxsaber:関連付けはありがたいのですが、トレードロジックにはならないようです。この問題は、TC構築の全く異なる原理に触れる、根本的なものだと思われます。私は、あなたの協会の話を聞きたいと思っています。そう、この問いは根源的なものなのです。スタニスラフ・コロツキー 私はそうは思いません。コマンドの実行を遅延させたキューは、すでに非同期を実現しています。コマンドループに新しい環境を求めているわけではありません。実際、特定のオーダーを修正するためのコマンドは、キューに1つしか存在できない。新しい環境を要求することは、一般的に、最小限の時間を要します。サーバーからの応答を待つ時間が大半を占めます。コマンドの実行を他の（あるいは複数の）EAに委任しても、シーケンシャルなコマンドの実行に変わりはない。その結果、ビルトインオーダーのサイクルと変わらないと思うのです。 fxsaber 2017.09.12 09:05 #24 Andrey Khatimlianskii:アソシエーションに耳を傾ける準備はできています。そう、この問いは根源的なものなのです。強くないので、そうはならないでしょう。まず、TSは、取引条件が理想的なテスター用に書かれています。問題がなければ、テスターで見たものにできるだけ近くなるように本番を書こうとするのです。それ以外のアプローチでTSを書くのは、アイデアのアルゴリズム化ではなく、当たり外れの話です。では、ここで根本的な質問ですが、テスターに最も近い戦闘状況とは何でしょうか？私は自分の意見を言った（そして例を挙げた）、あなたは聞いた。 Andrey Khatimlianskii 2017.09.12 09:33 #25 fxsaber:まず、TSは、取引条件が理想的なテスター用に書かれています。問題がなければ、実世界でテスターで見たものとできるだけ同じになるように、実戦版を書こうとするのです。それ以外のアプローチでTSを書くのは、アイデアのアルゴリズム化ではなく、当たり外れの話です。では、ここで根本的な質問ですが、テスターに最も近い戦闘状況とは何でしょうか？私は自分の意見を言った（そして例を挙げた）、私はあなたの意見を聞いた。なぜ、リストの最初のオーダーで作業すると、テスターに近い結果になるのか、まだ聞いていません（複数のオーダーがあるシステムについては、まだ議論中です）。 fxsaber 2017.09.12 09:40 #26 Andrey Khatimlianskii:リストの最初の順番で作業すると、結果がテスターに近くなると思う理由をまだ聞いていない（まだ多次元のシステムを議論している）。そしてこれは、残念ながら証明されたというより、ほとんど仮定に近いものです。あなたの選択肢のように。そう、私のアプローチを多少ひねる必要はありません。最初の注文のことではなく、何か中断した後にTS全体を再開することなのです。 Andrey Khatimlianskii 2017.09.12 09:53 #27 fxsaber:そしてこれは、残念ながら証明されたというより、ほとんど仮定に近いものです。どちらも選択肢にない。そう、私のアプローチを多少ひねる必要はありません。最初の注文のことではなく、何か中断した後にTS全体を再開することなのです。そうですね、ファーストオーダーだけで仕事をするのは、ある状況下でしか通用しないでしょう。議論は尽くされたと思っています。 fxsaber 2017.09.12 09:59 #28 Andrey Khatimlianskii:議論は尽くされたと思います。はい、ありがとうございます。ディスカッションの進め方は、並行して行われたものとは大きく異なりましたが......。 Stanislav Korotky 2017.09.12 14:42 #29 Andrey Khatimlianskii:新しい環境を要求するのは、一般的に最小限の時間で済みます。サーバーからの応答を待つ時間が大半を占めます。コマンドの実行を他の（あるいは複数の）EAに委ねることはできますが、シーケンシャルなコマンド実行であることに変わりはありません。結果は、オーダーのビルトインループと変わらないと思うのですが。それは時間の問題ではなく、論理の問題です（時間については、別のスレッドで説明します ;-)）。あなたの論理（自動車の例えを含め、全てに賛成なので私の論理）は、環境分析を断片的に行うのではなく、「一気呵成に、一挙に」行うことです。副作用の処理は、新しい取引環境に組み込まれるため、次の実行まで延期されます。別のEAは論外です。すべてがこれひとつで可能です。もちろん、その結果は1サイクルと同等になる。そうすれば、コードは論理的に理解しやすくなり、実際に私たちの論理を証明することができるのです。 fxsaber 2017.09.12 14:50 #30 Stanislav Korotky:別のEAは論外です。すべてがこれひとつで可能です。もちろん、その結果はループと同等になる。そうすれば、コードが論理的に明確になり、実際に私たちの論理を証明することになるからです。OOP-exampleを待っています。そして、今でもループという形で見ています。ロジックが変わらないのは、まず何を変えなければならないかを決めるため、そしてすでに決定したことについて決めるためである。 12345678910...15 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
そのために、すべてのTCオーダーの制御を犠牲にしなければならないのなら、絶対にそうします。
例えば、4台のトラックを所有しているとします。それぞれが、A地点からB地点まで貴重な荷物を運んでいる。ルートを監視する必要があります。
1分おきに1人と話すのと、2分おきに全員と話すのと、どっちがいい？
2つ目のケースでは、遅延がやや長くなり、ルートが間に合わなかった場合、4つとも少し遠回りしなければならなくなる可能性があります。しかし、トラック1台を使って他の3台を失うよりは、全体としてはビジネスにとって良いことでしょう。
関連付けはありがたいが、トレードロジックにはならないようだ。この問題は根本的なもので、全く異なるTC構築の原則に触れているように思います。
このような状況を避けるには、非同期命令を使用するしかないでしょう。
そうでなければ、実行するコマンドのリストに対するループが残ってしまい、本質的にオーダーのループになってしまうからです。
待ち行列の状況でのみ、ある注文に関連する古い未実行注文を新しいものに置き換える規定を設ける必要があるのです。さもないと、キューがオーバーフローして、キューから送り出されたオーダーが陳腐化する可能性があります。
関連付けはありがたいのですが、トレードロジックにはならないようです。この問題は、TC構築の全く異なる原理に触れる、根本的なものだと思われます。
私は、あなたの協会の話を聞きたいと思っています。そう、この問いは根源的なものなのです。
私はそうは思いません。コマンドの実行を遅延させたキューは、すでに非同期を実現しています。コマンドループに新しい環境を求めているわけではありません。実際、特定のオーダーを修正するためのコマンドは、キューに1つしか存在できない。
新しい環境を要求することは、一般的に、最小限の時間を要します。サーバーからの応答を待つ時間が大半を占めます。
コマンドの実行を他の（あるいは複数の）EAに委任しても、シーケンシャルなコマンドの実行に変わりはない。その結果、ビルトインオーダーのサイクルと変わらないと思うのです。
アソシエーションに耳を傾ける準備はできています。そう、この問いは根源的なものなのです。
強くないので、そうはならないでしょう。
まず、TSは、取引条件が理想的なテスター用に書かれています。問題がなければ、テスターで見たものにできるだけ近くなるように本番を書こうとするのです。それ以外のアプローチでTSを書くのは、アイデアのアルゴリズム化ではなく、当たり外れの話です。
では、ここで根本的な質問ですが、テスターに最も近い戦闘状況とは何でしょうか？私は自分の意見を言った（そして例を挙げた）、あなたは聞いた。
まず、TSは、取引条件が理想的なテスター用に書かれています。問題がなければ、実世界でテスターで見たものとできるだけ同じになるように、実戦版を書こうとするのです。それ以外のアプローチでTSを書くのは、アイデアのアルゴリズム化ではなく、当たり外れの話です。
では、ここで根本的な質問ですが、テスターに最も近い戦闘状況とは何でしょうか？私は自分の意見を言った（そして例を挙げた）、私はあなたの意見を聞いた。
なぜ、リストの最初のオーダーで作業すると、テスターに近い結果になるのか、まだ聞いていません（複数のオーダーがあるシステムについては、まだ議論中です）。
リストの最初の順番で作業すると、結果がテスターに近くなると思う理由をまだ聞いていない（まだ多次元のシステムを議論している）。
そしてこれは、残念ながら証明されたというより、ほとんど仮定に近いものです。あなたの選択肢のように。
そう、私のアプローチを多少ひねる必要はありません。最初の注文のことではなく、何か中断した後にTS全体を再開することなのです。
そしてこれは、残念ながら証明されたというより、ほとんど仮定に近いものです。どちらも選択肢にない。
そう、私のアプローチを多少ひねる必要はありません。最初の注文のことではなく、何か中断した後にTS全体を再開することなのです。
そうですね、ファーストオーダーだけで仕事をするのは、ある状況下でしか通用しないでしょう。
議論は尽くされたと思っています。
議論は尽くされたと思います。
はい、ありがとうございます。ディスカッションの進め方は、並行して行われたものとは大きく異なりましたが......。
新しい環境を要求するのは、一般的に最小限の時間で済みます。サーバーからの応答を待つ時間が大半を占めます。
コマンドの実行を他の（あるいは複数の）EAに委ねることはできますが、シーケンシャルなコマンド実行であることに変わりはありません。結果は、オーダーのビルトインループと変わらないと思うのですが。
それは時間の問題ではなく、論理の問題です（時間については、別のスレッドで説明します ;-)）。あなたの論理（自動車の例えを含め、全てに賛成なので私の論理）は、環境分析を断片的に行うのではなく、「一気呵成に、一挙に」行うことです。副作用の処理は、新しい取引環境に組み込まれるため、次の実行まで延期されます。
別のEAは論外です。すべてがこれひとつで可能です。もちろん、その結果は1サイクルと同等になる。そうすれば、コードは論理的に理解しやすくなり、実際に私たちの論理を証明することができるのです。
別のEAは論外です。すべてがこれひとつで可能です。もちろん、その結果はループと同等になる。そうすれば、コードが論理的に明確になり、実際に私たちの論理を証明することになるからです。
OOP-exampleを待っています。そして、今でもループという形で見ています。ロジックが変わらないのは、まず何を変えなければならないかを決めるため、そしてすでに決定したことについて決めるためである。