受注サイクルの整理 - ページ 4 1234567891011...15 新しいコメント zenz 2017.09.12 15:47 #31 fxsaber:強くないので、そうはならないでしょう。まず、TSは、取引条件が理想的なテスター用に書かれています。問題がなければ、テスターで見たものにできるだけ近くなるように本番を書こうとするのです。それ以外のアプローチでTSを書くのは、アイデアのアルゴリズム化ではなく、当たり外れの話です。では、ここで根本的な質問ですが、テスターに最も近い戦闘状況とは何でしょうか？私は自分の意見を言った（そして例を挙げた）、私はあなたの意見を聞いた。ストラテジーテスター（MT4）でティックテストしていたExpert Advisorの売買ロジックを、実際の口座で動作するように変換する作業に直面しています。 私の推理です。 テスターでは、Expert Advisorは理想的な取引条件だけでなく、実際には別のモードでも動作します - リアルタイムで、つまり、TSを計算する時間があり、注文を送って1ティックでその答えを得ることができますが、実際の取引ではそうではありません。私たちは、リアルタイムのロボットとノータイムのロボットの2種類を持っているようなものです。 実口座に注文（1件でも！）を送る／変更する場合＝ ping＋約定時間など。= せいぜい100-500msで、この間に刻み目は進み、カウントする必要があります。で、適当に流れに乗る（この間、ティックアベレージに対して価格がどこに行ったかはわからない。+ 最も速く、通常は最も重要なティックを見逃しているに違いない)。そのため、結果的にテスターで実行した作戦が何も残らないこともあります。 そこで、反省を踏まえて、次のように考えています。戦闘モードでは、Expert Advisorの取引ロジックは無効化され、実際にはフォロワーとして動作します。取引システムをインジケータに移し、オープニングとクローズのコマンドを生成し、そのコマンドをエキスパートが実行するのを待つのではなく、テスターとほぼ同じように、理想的な状態で持っているTSを実行するだけでいいのです。技術的に可能かどうかは疑問ですが、私の知る限り、インジケータはティックをスキップしてはいけません。しかし、少なくとも、この可能性がドキュメントに最初に記述されていたExpert Advisorよりは、ティックをスキップしないはずです。+ TCの計算誤差の分離を犠牲にしても、TCのロジックに関連するあらゆる種類の二次的操作の中断がないため、少なくなるはずである。 fxsaber 2017.09.12 15:52 #32 zenz:そこで、よく考えてみると、次のようなことに行き着きました。戦闘モードでは、Expert Advisorの取引ロジックは無効になり、実際にはコピー機として動作します。取引システムをインジケータに移し、オープニングとクローズのコマンドを生成し、Expert Advisorがこれらのコマンドを実行するのを待つのではなく、テスターに近い理想的な状態でTSを実行するだけである。技術的に可能かどうかは疑問ですが、私の知る限り、インジケータはティックをスキップしてはいけません。しかし、少なくとも、この可能性がドキュメントに最初に記述されていたExpert Advisorよりは、ティックをスキップしないはずです。+ TCの計算のエラーの分離を犠牲にしても、TCの操作のロジックに二次的なすべての種類に中断がないので、少なくする必要があります。そうですね、私も同じ方法を使います。内部の理想的なテスターに独自の未決済注文を持たせ、その仮想注文を実現しようとするコピー機を使うのです。この方式は、多くの重大な問題をいとも簡単に回避することができます。MT5では、ティック履歴を 要求できるので、より簡単です。しかも、複数のシンボルで要求できる。 Andrey Khatimlianskii 2017.09.12 16:02 #33 Stanislav Korotky:それは時間の問題ではなく、論理の問題です（時間については、別のスレッドで説明します ;-)）。あなたの論理（車の例えを含め、全てに同意する私の論理）は、環境分析を断片的に行うのではなく、「一気呵成に、一挙に」行うことです。副作用の処理は、新しい取引環境に組み込まれるため、次の実行まで延期されます。もし、時間補正がなければ、（私とfxsaberの）両方の論理は同じになります。正確には、テストで得た理想的なモデルに対して、即座に実行することで、現実を近似させることを目的としています。 Andrey Khatimlianskii 2017.09.12 16:05 #34 fxsaber:オープンオーダーを持つ内部の理想的なテスターと、その仮想オーダーを実現しようとするコピー機のようなものですね。もし、あなたのやり方（ループで、現実とうまく同期するまで最初のオーダーに留まる）で具体化すると、残りのオーダーが見えなくなる（あるいは単に後で処理される）という同じ問題にぶつかるかもしれません。しかし、これは同じ、完成したとされる話題についてです）。 fxsaber 2017.09.12 16:14 #35 Andrey Khatimlianskii:もし、あなたのやり方（ループで、現実とうまく同期するまで最初のオーダーに留まる）で具体化すると、残りのオーダーが見えなくなる（あるいは単に後で処理される）という同じ問題にぶつかるかもしれません。しかし、これは解決したとされる同じ疑問についてである）。これが私たちの取引方法だ! Stanislav Korotky 2017.09.13 11:09 #36 fxsaber:OOPの例を待っています。そして、やはりループという形で同じバックボーンとして捉えています。ロジックが変わらないのは、まず何を変えなければならないかを決めるためのものであり、次にすでに決めたことについてのためのものだからです。このタスクのために特別に例を書くことはしない。しかし、私のブログでは、そのアプローチの簡略化されたコンセプトを見ることができるかもしれません。そこでは、キューを深く分析するのではなく、空っぽかどうかだけをチェックするのです。希望者はそれを改良することができる。もし、ロジックが「価格の変化により、山積みになった注文を修正する」タスクを意味するならば、タスクは1つしかない。問題は、すべての 注文を修正することと、最新の価格に合わせて 修正することのどちらが重要なのかということです。あなたの好みによって、ロジックは異なります。単純なループを使えば、すべての 注文が修正されることが保証されるので、私はこのオプションに賛成です。すでに述べたように、OOPはタスクを責任ブロックに明確に分割し、この分解に基づいて、「価格の妥当性」よりも「すべての注文」が重要視されるのです。これは、価格が常に変化し、注文がたまにしかないことを見ても明らかである。より重要なのです。 fxsaber 2017.09.13 11:37 #37 Stanislav Korotky:PLOは、タスクを責任ブロックに分割することで明確にしており、この分解に基づいて、"価格の妥当性 "よりも "すべての注文 "が重要である。 この分解に 基づき、分割のみが続く。このPLOにおける "価格の妥当性 "は、待ち行列の場所を設定することで実現されます。 Stanislav Korotky 2017.09.13 11:48 #38 fxsaber: この分解に 基づき、分離だけが続く。このOOPの下での "価格の妥当性 "は、待ち行列に場所を設定することで達成される。これはもう、ちょっとした「哲学」ですね。処理はオーダーキューで行われ、代替案で提案されているようなティックフローではありません。とにかく、私はこの議論から撤退します。すべての議論はすでに終わっています。 fxsaber 2017.09.13 12:04 #39 Stanislav Korotky:とにかく、私はこの議論から撤退します。すべての議論はすでに終わっています。すでにそのように終わらせる風潮があります。 Vasiliy Sokolov 2017.09.13 12:23 #40 fxsaber:以下では、MT4だけでなく、MT5と他のプラットフォームにも関係する話題に触れていきます。しかし、ロジックは認識しやすいようにMQL4で書く予定なので、このブランチでは。注文の変更・削除のバックボーン（注文の肉）は、ほとんどの場合、以下のロジックに帰着します。今、そのアプローチはまれだが、はるかに正しい取引注文の 送信後は取引環境が変化するため、取引サーバーからの応答後、直ちにTSの全取引ロジックをゼロから実行することが望ましい。ループは最も危険なプログラミングのトリックの1つです。稀に発生する奇妙なエラーが発生し、解析がほとんどできない。ループさせるのではなく、逆にユーザースレッドをできるだけ早く終了させるようにする必要があります。もし、あなたが脈拍を保ちたいなら - MT5でOnTradeTransactionを分析してください。MT4は一般的にこのようなループには向いていません。なぜなら、シンプルであることは、言わば盗難よりも悪いことだからです。 1234567891011...15 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
強くないので、そうはならないでしょう。
まず、TSは、取引条件が理想的なテスター用に書かれています。問題がなければ、テスターで見たものにできるだけ近くなるように本番を書こうとするのです。それ以外のアプローチでTSを書くのは、アイデアのアルゴリズム化ではなく、当たり外れの話です。
では、ここで根本的な質問ですが、テスターに最も近い戦闘状況とは何でしょうか？私は自分の意見を言った（そして例を挙げた）、私はあなたの意見を聞いた。
ストラテジーテスター（MT4）でティックテストしていたExpert Advisorの売買ロジックを、実際の口座で動作するように変換する作業に直面しています。
私の推理です。
テスターでは、Expert Advisorは理想的な取引条件だけでなく、実際には別のモードでも動作します - リアルタイムで、つまり、TSを計算する時間があり、注文を送って1ティックでその答えを得ることができますが、実際の取引ではそうではありません。私たちは、リアルタイムのロボットとノータイムのロボットの2種類を持っているようなものです。 実口座に注文（1件でも！）を送る／変更する場合＝ ping＋約定時間など。= せいぜい100-500msで、この間に刻み目は進み、カウントする必要があります。で、適当に流れに乗る（この間、ティックアベレージに対して価格がどこに行ったかはわからない。+ 最も速く、通常は最も重要なティックを見逃しているに違いない)。そのため、結果的にテスターで実行した作戦が何も残らないこともあります。
そこで、反省を踏まえて、次のように考えています。
そこで、よく考えてみると、次のようなことに行き着きました。
そうですね、私も同じ方法を使います。内部の理想的なテスターに独自の未決済注文を持たせ、その仮想注文を実現しようとするコピー機を使うのです。この方式は、多くの重大な問題をいとも簡単に回避することができます。
MT5では、ティック履歴を 要求できるので、より簡単です。しかも、複数のシンボルで要求できる。
それは時間の問題ではなく、論理の問題です（時間については、別のスレッドで説明します ;-)）。あなたの論理（車の例えを含め、全てに同意する私の論理）は、環境分析を断片的に行うのではなく、「一気呵成に、一挙に」行うことです。副作用の処理は、新しい取引環境に組み込まれるため、次の実行まで延期されます。
もし、時間補正がなければ、（私とfxsaberの）両方の論理は同じになります。
正確には、テストで得た理想的なモデルに対して、即座に実行することで、現実を近似させることを目的としています。
オープンオーダーを持つ内部の理想的なテスターと、その仮想オーダーを実現しようとするコピー機のようなものですね。
もし、あなたのやり方（ループで、現実とうまく同期するまで最初のオーダーに留まる）で具体化すると、残りのオーダーが見えなくなる（あるいは単に後で処理される）という同じ問題にぶつかるかもしれません。しかし、これは同じ、完成したとされる話題についてです）。
もし、あなたのやり方（ループで、現実とうまく同期するまで最初のオーダーに留まる）で具体化すると、残りのオーダーが見えなくなる（あるいは単に後で処理される）という同じ問題にぶつかるかもしれません。しかし、これは解決したとされる同じ疑問についてである）。
これが私たちの取引方法だ!
OOPの例を待っています。そして、やはりループという形で同じバックボーンとして捉えています。ロジックが変わらないのは、まず何を変えなければならないかを決めるためのものであり、次にすでに決めたことについてのためのものだからです。
このタスクのために特別に例を書くことはしない。しかし、私のブログでは、そのアプローチの簡略化されたコンセプトを見ることができるかもしれません。そこでは、キューを深く分析するのではなく、空っぽかどうかだけをチェックするのです。希望者はそれを改良することができる。
もし、ロジックが「価格の変化により、山積みになった注文を修正する」タスクを意味するならば、タスクは1つしかない。問題は、すべての 注文を修正することと、最新の価格に合わせて 修正することのどちらが重要なのかということです。あなたの好みによって、ロジックは異なります。単純なループを使えば、すべての 注文が修正されることが保証されるので、私はこのオプションに賛成です。すでに述べたように、OOPはタスクを責任ブロックに明確に分割し、この分解に基づいて、「価格の妥当性」よりも「すべての注文」が重要視されるのです。これは、価格が常に変化し、注文がたまにしかないことを見ても明らかである。より重要なのです。
PLOは、タスクを責任ブロックに分割することで明確にしており、この分解に基づいて、"価格の妥当性 "よりも "すべての注文 "が重要である。
この分解に 基づき、分離だけが続く。このOOPの下での "価格の妥当性 "は、待ち行列に場所を設定することで達成される。
これはもう、ちょっとした「哲学」ですね。処理はオーダーキューで行われ、代替案で提案されているようなティックフローではありません。とにかく、私はこの議論から撤退します。すべての議論はすでに終わっています。
とにかく、私はこの議論から撤退します。すべての議論はすでに終わっています。
すでにそのように終わらせる風潮があります。
以下では、MT4だけでなく、MT5と他のプラットフォームにも関係する話題に触れていきます。しかし、ロジックは認識しやすいようにMQL4で書く予定なので、このブランチでは。
注文の変更・削除のバックボーン（注文の肉）は、ほとんどの場合、以下のロジックに帰着します。
今、そのアプローチはまれだが、はるかに正しい
取引注文の 送信後は取引環境が変化するため、取引サーバーからの応答後、直ちにTSの全取引ロジックをゼロから実行することが望ましい。
ループは最も危険なプログラミングのトリックの1つです。稀に発生する奇妙なエラーが発生し、解析がほとんどできない。
ループさせるのではなく、逆にユーザースレッドをできるだけ早く終了させるようにする必要があります。もし、あなたが脈拍を保ちたいなら - MT5でOnTradeTransactionを分析してください。MT4は一般的にこのようなループには向いていません。なぜなら、シンプルであることは、言わば盗難よりも悪いことだからです。