受注サイクルの整理

fxsaber 2017.10.06 07:06 #101

Artyom Trishkin:

しかし、そうしない方がいいのです。すべてのものは、あるべき場所にあるべきです。

EAタイマーでは、必要な条件に従ってリストを取得し、list.Total()>xxxの時点で希望通りの処理を行います。

タイマーがなかった昔のMQL4では、この問題に解決策がなかったことが判明したのですね。数行で解決できることなのに、なぜわざわざタイマーを使うのか？

Artyom Trishkin 2017.10.06 07:07 #102

Alexey Viktorov:

まさにその通りです。

そして、私のポスト

また、実際の取引では、注文のループを追い続けることにどんな意味があるのでしょうか。何より、時間がもったいない...。

取引環境に関する最新の情報を常に把握し、必要な都度検索するのではなく、利用可能なリストを参照すること。そして、リストは常に最新であるべきなので、最新でありながら効率的に維持できるように気を配る価値があります。

結局、リストがなければ、必要なときに情報を探さなければならない。しかも、1ティックに1回だけではありません。そしてそこには、環境を繰り返し読み込むことのブレーキがすべて現れてくるのです。

ただし、環境の変化をコントロールすることを放棄し、必要なときだけリストを埋めるようにすれば、ここでも最適化が可能です。しかし、その場合、ユーザーの手動でのクローズ/変更/オープン操作に反応するEAの機能が失われます。

Artyom Trishkin 2017.10.06 07:08 #103

fxsaber:

タイマーがなかった昔のMQL4では、この問題に解決策がなかったことが判明したのですね。数行で解決できることなのに、なぜわざわざタイマーを使うのか？

どうしても無理なときは、どうすれば解決できるかを考える必要がありました。でも、今はそれが可能なんです ;)

Alexey Viktorov 2017.10.06 07:16 #104

Artyom Trishkin:

取引環境に関する最新の情報を常に把握し、必要な時にいちいち検索することなく、既存のリストを参照することができること。リストは常に最新であるべきなので、常に最新でありながら効率的な 運用に気を配る価値があります。

結局、リストがなければ、必要なときに情報を探さなければならない。しかも、1ティックに1回だけではありません。そして、ここでは、すべてのスローダウンは、環境のロードを繰り返したときに現れる。

しかし、ここでも最適化することができます - あなたが環境の変化を制御し、必要なときにのみリストを埋めることを拒否した場合。しかし、その場合、手動でクローズ/変更/オープンする際のユーザーのアクションにEAが反応する機能を失うことになります。

それが「でも効果的」というキーワードです。また、次のティックが来たときにしかリストを変更できないのであれば、ミリ秒ごとにリストを更新することの深い意味は何なのでしょうか？また、1ティックに1回ではダメなのでしょうか？注文はティックの外側で閉じることができますか？私の見るところ、ティックがない状態で、EAがopen/closeのコマンドを送る、つまり環境、つまりリストを変更すると、この動作でティックが発生するのだと思います。あるいは、そうでない場合、何か他の原因によるティックがなければ、リストは変更されません。そうでしょう？

Artyom Trishkin 2017.10.06 07:23 #105

Alexey Viktorov:

ここに「しかし効果的に」というキーワードがあります。また、次のティックを受信したときにのみリストが変更できるのであれば、ミリ秒ごとにリストを更新する深い意味はあるのでしょうか？また、1ティックに1回ではダメなのでしょうか？注文はティックの外側で閉じることができますか？私の見るところ、ティックがない状態で、EAがopen/closeのコマンドを送る、つまり環境、つまりリストを変更すると、この動作でティックが発生するのだと思います。あるいは、そうでない場合、何か他の原因によるティックがなければ、リストは変更されません。そうでしょう？

テスターではOnTimer()を実行して、OnTick()からだけリストを作成していますが、実戦では差がつかないのですね...。

しかし、そこで必要なのはリストの作成だけでなく、タイマーです。すべてにおいて、必要なものが一度に揃う。今のところは。さらにプロファイリングすることで、ボトルネックが見えてきます。

Taras Slobodyanik 2017.10.06 10:13 #106

Alexey Viktorov:

それが「しかし効果的に」というキーワードです。また、1ミリ秒ごとにリストを更新することの深い意味は何でしょうか。もし、リストが別の刻みの到来によってのみ変更されるのであれば、その意味は何でしょうか。また、1ティックに1回ではダメなのでしょうか？注文はティックの外側で閉じることができますか？私の見るところ、ティックがない状態で、EAがopen/closeのコマンドを送る、つまり環境、つまりリストを変更すると、この動作でティックが発生するようです。あるいは、そうでない場合、何か他の原因によるティックがなければ、リストは変更されません。そうでしょう？

プログラムが多くのシンボルを扱う場合、タイマーのブルートフォースにはポイントがあります - 刻み目は異なる時間にやってきます。

しかし、「自分の」注文リストではなく、端末が作成した注文リストを検索するのは意味がなく、そのリストが誰かによって変更されるという問題が発生するのです。

Alexey Viktorov 2017.10.06 10:25 #107

Taras Slobodyanik:

プログラムが多くのシンボルを扱う場合、タイマーのブルートフォースにはポイントがあります - 刻み目は異なる時間にやってきます。

しかし、「自分の」注文リストではなく、端末が作成したリストを検索するのは意味がなく、誰かがリストを変更したときに問題が発生する原因になっています。

not your own」リストの場合、注文の総量があるので、それを静的変数に格納してループを走らせ、環境の変化に応じて列挙していくことができる。しかし、1ミリ秒単位ではありません...。

Artyom Trishkin 2017.10.06 10:26 #108

Alexey Viktorov:

万が一、リストが「自分のものではない」場合、注文の総数があり、それを静的変数に格納し、ループを実行して環境の変化に応じて再実行することができる。しかし、1ミリ秒単位ではありません...。

この方法では、保留中の注文のトリガーを捕捉することはできません。

Alexey Viktorov 2017.10.06 10:32 #109

Artyom Trishkin:

この方法では、保留中の注文のトリガーを捕捉する方法はありません。

つまり、ノミを捕まえる、つまり保留中の注文の話ではなく、1ミリ秒ごとにすべての注文を試すという話なのです。

Artyom Trishkin 2017.10.06 12:01 #110

Alexey Viktorov:

つまり、ノミ、つまり保留中のオーダーを捕まえるのではなく、すべてのオーダーをミリ秒単位で見ていくのです。

- フライパンは何のために必要なのか？

- 例えば、目玉焼きを焼くとき。

- スクランブルエッグではなく、フライパンで...。

受注サイクルの整理 - ページ 11