Язык программирования MQL5 позволяет решать задачи на совершенно новом уровне. Даже те задачи, которые уже вроде имеют решения, благодаря объектно-ориентированному программированию могут подняться на качественно новый уровень. В данной статье специально взят простой пример проверки появления нового бара на графике, который был преобразован в достаточно мощный и универсальный инструмент. Какой? Читайте в статье.
MetaTrader 5 позволяет во встроенном тестере стратегий моделировать автоматическую торговлю с помощью экспертов на языке MQL5. Такое моделирование называется тестированием экспертов, и может проводиться с использованием многопоточной оптимизации и одновременно по множеству инструментов. Для проведения тщательного тестирования требуется генерировать тики на основе имеющейся минутной истории. В статье дается подробное описание алгоритма, по которому генерируются тики для исторического тестирования в клиентском терминале MetaTrader 5.
どんなリアリティがあるんだ？リアルタイムテスト？もしそうなら、もちろん賛成です。シンボルに2つのEAをぶら下げれば、すべてが正しくなります。しかし、私は多通貨モードをテストしています。また、OnTimer()のみを使用した場合(10秒)も同様の結果を示しています。
私は、多通貨モードでの実際の実行（各シンボルに設定されたEAで（各EAで）N個のシンボルで取引）について話しています - それは実際の見積もりを与え、テスターの場合には、主にテストモードを 比較しており、各多通貨ティック処理方法の正しさを比較しているのではないのです。テスターの人工的な環境に基づくものであれば、異なるモードを比較することに何の意味があるのでしょうか？実行結果の同一性は、取引上最も正しい結果を与えると主張する根拠にはならず、テスターの内部動作機構上、最適なものであることを示しています。
まずは正しい表現から。元の例では、「ユーロドルでの取引」を希望していたはずです。実際、カスタムイベントは 2つのシンボルから発生しており、イベントハンドラでは、これら2つのシンボルのいずれかからイベントが受信されたときにTradeSignalCounter()+TradePerformer()が呼び出されていました。イベントキューは常に満杯だったと推測されます。
さて、シグナルソースの1つを削除したのに、なぜかイベントハンドラに「if(sparam == Symbol_01)」というチェックが入っていますね。しかし、次の質問は違います。コードから判断すると、Lizarのスキームは「All ticks」モードで使用され、関数TradeSignalCounter()+TradePerformer()がシグナルソース（EURUSD）から毎ティックで呼び出されています。興味深いのは、すでにイベントキューがオーバーフローする可能性を示唆していることです。しかし、この2つの関数のSymbol_01パラメータとしてどのような計測器が使われているのか、また、Lizarのスキームでイベントの周期性を変えることを試されたのかが知りたいです。
そう、それがやりたかったんです。結局のところ、私たちの行動はすべて欲求が引き金になっているのです。今回は、まさに私が望んでいたものが手に入りました。つまり、TradePerformer()関数がシンボル配列の各シンボルに対して取引が許可されているかどうかをチェックするため、EURUSDのみで 取引を行ったのです。このオプションは外部変数にあり、当時はGBPUSDの シンボルを使った取引は禁止されていました。ユーザーイベントは2つのシンボルから発生しましたが、イベントハンドラでは、やはりTradePerformer()関数がEURUSD シンボルのみで取引を許可していました。TradePerformer()関数には、特定のシンボル（この場合はEURUSD）で新しいバーが発生したかどうかを判断する関数も含まれています。イベントキューが常に満杯であるという仮定は正しいのですが、この場合、すべてが別々に処理されており、日足バーでテストする場合、1ティックの遅れは重要ではありません。
テストに関与しないはずの信号源を一つ取り除いたことで、それまですべてが正しく行われていたことが確認できただけだった。テストが行われるべきでない信号源を削除せずに結果を確認したところ、「if(sparam == Symbol_01)」のチェックが残りました。このチェックは、実は余計なものであったことが判明した。結果は変わらなかった。Symbol_01 パラメータにはEURUSD シンボルが使用されます。イベントの頻度を変えてみましたが、何も変わりませんでした。より正確には、全ティックモードが最も正確だと言えるでしょう。
私は、多通貨モードでの実際の実行（各シンボルに設定されたEAで（各EAで）N個のシンボルで取引）について話しています - それは実際の見積もりを与え、テスターの場合には、主にテストモードを 比較しており、各多通貨ティック処理方法の正しさを比較しているのではないのです。テスターの人工的な環境に基づくものであれば、異なるモードを比較することに何の意味があるのでしょうか？実行結果が同じでも、トレーディングの観点から最も正しい結果が得られるとは言えず、テスターの内部機構の観点から最適であると言えます。
今ならわかる。しかし、もともとはテスターでのテストに焦点を当てた議論でした。取引を開始する前に、システムをテストする必要があります。テストの精度が高ければ高いほど、実際の取引で自信を持つことができます。ここで紹介したテスト結果は、テストには正しいやり方と間違ったやり方があることを示しています。今、誰もが選択肢を持ち、何が正しいか間違っているかを自分で決めることができるのです。あるトレーダー（私の記憶違いでなければ、ヴァン・タープ氏）は、「我々は認識で取引する」と正論を述べています。それに付け加えることができる。私たちは、自分のアイデアを交換するだけではありません。私たちは、認識によって生きていることさえあるのです。))
実際の取引やテストにおいて、Expert Advisorを各シンボルに個別に取り付ければ、最も精度が高くなるはずです。もちろん、私もそう思っています。しかし、そのためのバーシンクロナイゼーションは必要ない。正確さには持続性が伴います。テスターで長い履歴期間を推定することができます。そして、個人的には正しい検査結果を見ることができるほうがいい。
もう一点強調しておきたいのは、私はどこかで勘違いをしている可能性を排除せず、必ずすべてをチェックするということです。しかし、厳しいテストを経て、一見正しく見えるものでも、どこかに間違いがある可能性は否定できません。このとき、もし提示されたそれらの試験方法の結果の評価に異論がある人がいたら、比較のために自分の試験結果を提示する必要があります。結局のところ、このスレッドの目的は、正しい ことをする方法、より正確に言えば、多通貨 Expert Advisor を正しくテストする方法を見つけることであって、言葉だけで誰が正しいとか間違っているとかいうことではないのです。事実、事実だけ、事実以外の何物でもない!)))
人工的なテスター環境を前提にしたモード同士を比較することに、何の意味があるのでしょうか？
要は、結果を見て正しい判断をすることです。それに、確かに歪んだデータを分析しても意味がないですね。結局、自分が蒔いた種は自分で刈り取るのです）。
本来ならテストに関わらないはずの信号源を1つ取り除くことで、それまでが正しく行われていたことが確認できただけだった。
"...以前はちゃんとできていた "は、自己満足の範疇から。そもそもが間違いなのだ。イベント列の過密」といった現象は重要視していないようですね。特に、イベントのポストイット的な伝達については。このテーマの参考資料やフォーラムをご覧になってみてください。キーワードは "キュー "です。
...TradePerformer()関数がシンボル配列の各シンボルに対して取引可能かどうかをチェックするため、EURUSDのみで 取引しました。このオプションは外部変数にあり、当時はGBPUSDの シンボルでの取引は禁止されていました。ユーザーイベントは 2つのシンボルから発生しましたが、イベントハンドラでは、やはりTradePerformer()関数がEURUSD シンボルのみで取引を許可していました。TradePerformer()関数には、特定のシンボル（この場合はEURUSD）で新しいバーが発生したかどうかを判断する関数も含まれています。イベントキューが常に満杯であるという仮定は正しいのですが、この場合、すべてが別々に処理されており、日足バーでテストする場合、1ティックの遅れは重要ではありません。
TradeSignalCounter()+TradePerformer() は1つのシグナルソースからのイベントのみを処理したため、キューの状態とそのオーバーフローの可能性は全く変わりませんでした。つまり、「GBRUSDシンボルによるイベント処理の禁止」は、該当するイベントをキューから全く削除していなかったのである。3度目の正直で、「イベントのキューがオーバーフローする可能性が既に示唆されていた」という問題に注意を喚起しています :)もし、「1ティック遅れる」程度だとお考えなら、そのような結論に至る根拠は何でしょうか。
「...この場合、すべて別々に処理されました」。問題は、オリジナルバージョンでは、両方の信号源からイベントを受信したときにイベントハンドラが関数を呼び出し、その関数がすでに「不要な」信号源からの信号をフィルタリングしていたことです。しかし、その関数は毎回（！）呼び出されていた。
日足でテストした場合、1ティックの遅れは重要ではありません。
イベントハンドラのテストはどのような周期で行ってもかまいません。Lizarの方式が刻々と信号を発生させるのであれば、イベントキューも刻々とスコアリングしていることになり、1日に1回ではありません。
"イベントの周期を変えてみたが、変化がなかった。より正確には、全ティックモードが最も正確だと言えます」 ライザーの非ティックモードの比較スクリーンショットを提供していただけないでしょうか。
実際の取引やテストで、各シンボルに個別にEAをかけると、それが一番正確な選択肢になると思います。もちろん、私もそう思っています。しかし、バーを同期させる必要はない。正確さには持続性が伴います。テスターで長い履歴期間を推定することができます。そして、個人的には正しい検査結果を見ることができるほうがいい。
ポイントは、その結果に基づいて正しい判断をすることです。でも、破損したデータを解析する意味は絶対にないと思うんです。結局、自分が蒔いた種は自分で刈り取るのです）。
私が指摘したいのは、「正しさ」の範疇は、今やテスターの走行の正体に取って代わられましたが、だからといって、そうしたデータの歪みが少ないとは言えないということです。特に、今回は10秒間隔を選択されていますが、5秒間隔や1秒間隔よりも歪みが大きいことは間違いありません。つまり、テスターの動作条件にある何らかの特徴を利用して、10秒タイマーで好みの方式を実現しているのです。実際、あなたはタイマーイベントですべての楽器の新しいバーの ティックの到着の瞬間を「キャッチ」しようとしており、これを行うための最良の方法がOnTickイベントであることは明らかです。
時間を無駄にしないでください。ダニに完全一致することはないでしょう。小節の終了時刻は楽器によって異なる。
ある計測器では現在時刻はバーが閉じた時刻、別の計測器ではまだバーが形成されていない時刻、そして3つ目の計測器では数ティック前に形成された時刻です。
ティック履歴を見て ください、ティックの量は計測器によって何倍も違います。
Yedelkin 2011.08.25 08:16 #
---
おはようございます。))
この別に切り取った文言とは別に、「。どこかで間違っていると断定せず、必ずすべてをチェックします。しかし、どんなに厳しいチェックを受けても、一見正しく見えても、どこかに間違いがある可能 性を否定できないのです」。付け加えると、私は自分がいつも正しいと思っているタイプではありません。)))
---
イェデルキン
元々間違っていたのです。どうやら、「イベントの行列ができる」という現象は重要視していないようですね。特に、イベントのポストイット的な伝達については。このテーマの参考資料やフォーラムをご覧になってみてください。キーワードは "キュー "です。
---
Timerの トピックを拝見しました。私が注目したのは、そのポイントです。
1.あるイベントが処理されている間、他のイベントが処理されないことがあります。
2.イベントスタックがオーバーフローした場合、古いイベントは処理されずにキューから削除されます。
順を追って説明しよう。イベントの列挙があります。
初期化の際、どのシンボルからイベントを受け付けるか、どのイベントを受け付けるかを指定する。
つまり、EURUSD シンボルからのCHARTEVENT_TICK イベントのみを受け入れることになります。それ以外の記号はありません。
テストが始まりました。何らかのイベントが発生すると、プログラムはOnChartEvent()関数に入り、売買シグナル用の変数配列を宣言し、イベントの有無を確認します。カスタムイベントであれば、TradeSignalCounter()でシグナルを判定し、TradePerformer()関数で新しいバーが発生したかどうかをチェックし、これに応じて他の条件を決定します。この機能は停止しており、EURUSD チャート上でイベントが発生した場合にのみ動作するようになります。つまり、この場合のティックです。
イェデルキン
TradeSignalCounter()+TradePerformer() が1つのシグナルソースからのイベントのみを処理することから、イベントキューの状態とそのオーバーフローの可能性は何ら変わることはありません。つまり、「GBRUSD シンボルによるイベント処理の禁止」は、該当するイベントをキューから全く削除していなかったのである。3度目の正直で、「イベントのキューがオーバーフローする可能性は、すでにInterestingによって示唆されていた」という問題に注意を促しています :)もし、「1ティック遅れる」程度だとお考えなら、そのような結論に至る根拠は何でしょうか？
---
記載されている機能の実行は非常に高速です。イベントキューがオーバーフローすることもなく、重要なイベントが見逃されることもありません。さらに、キューがオーバーフローしてイベントが見逃された場合、何が見逃されるのでしょうか？ダニ、ダニ2匹、ダニ3匹？それがどうした？昼間のバーでは取るに足らないことです。
---
イェデルキン
問題は、オリジナルバージョンでは、両方の信号源からイベントが来たときにイベントハンドラが関数を呼び出し、その関数がすでに「不要な」信号源からの信号をフィルタリングしていたことです。しかし、その関数は毎回（！）呼び出されていた。
---
なぜこの第二のソースにしがみつくのか))もうセカンドソースはないのです。EURUSDが ありますが、Expert AdvisorはGBPUSDの チャートからEURUSDに トレードします。そしてその結果は、同じように間違っている。コピーです。つまり、2つ目のソースが存在する場合と同じである。)))
-----------
自分でテストを行い、テスト結果を見せ、正しいテスト結果を得るために何をしたかを（もちろん、そうすることができれば）簡単に書いておくとよいでしょう。このテストでは、最もシンプルなエキスパートで十分です。任意の条件でエントリー、ストップロス、テイクプロフィット。過去10年間の日足バーとする。そして、あなた自身の目で確かめてください。時期が重なるものもあれば、そうでないものもあります。結果チャートを開いて、どこにミスマッチがあるのかを確認します。
バー同期をオンラインで行う必要がないとは！？
だって、その前に書いているじゃないですか。
マーケター
多通貨モード（各シンボルに設定されたEAで（各EAで）N個のシンボルで取引）での実際の実行について話しています - これは実際の見積もりを与えます...
このことから、実運用とは、複数のEAが動作しているときに、それぞれが自分のシンボルに直接ホバリングしているオンラインテストのことだと理解しています。そういう意味なら、質問です。各 Expert Advisor が独自のシンボルに配置されている場合、この場合、なぜバーの同期が必要なのでしょうか。おそらく、この場合のバーの同期は、取引システムが複数のシンボルについて一度に判断するように構成されている場合に必要であり、そのため、これらの複数のシンボルのバーが形成されなければならない。一つのシンボルにいながら、複数のシンボルで独立して取引することを意味します（任意のシンボルで）。
マーケッターです。
テスターでのこれらの実験はすべてオンライン取引の推定に必要であり、このトピックの問題はテスター（オンラインをエミュレートする）ではなく、オンライン、そして何よりもオンラインのバー同期が（適切なExpert Advisorのために）必要であることです。
私にとってテスター実験は、ヒストリーの上でトレードした結果を評価するために必要なものなのです。そして、私がオンライントレードを選ぶのも、この評価によるものです。したがって、このトピックの問題は、オンラインの問題ではなく、テスターの問題であり、テスターでも（対応するExpert Advisorの）バーの同期が必要なのはそのためです。いくつかの鏡像))))
マーケッターです。
私が指摘したいのは、「正しさ」のカテゴリーが、今はテスターの走行の正体に置き換わっていますが、だからといって、そうしたデータの偏りが少ないとは言えないということです。特に、今回は10秒間隔を選択されていますが、5秒間隔や1秒間隔よりも歪みが大きいことは間違いありません。つまり、テスターの動作条件にある何らかの特徴を利用して、10秒タイマーで好みの方式を実現しているのです。
そうですね、間隔が狭いほど、より正確な結果が得られます。でも、実は最後のテストには必要なんですよ、少なくとも僕には。また、予備的なものについては、やはりウラジミール（MetaDriver）さんと同じように、1分間隔でよいということになりますね。
マーケッターです。
実際、タイマーイベントを使って、すべてのシンボルで新しいバーの ティックの到着を「キャッチ」しようとするわけですが、それをするのに最適な方法が OnTick イベントであることは明らかです。
と、ここで、スレッドの最初の投稿をよく読んでいないことがわかりますね。タイマーイベントではなく、OnChartEvent()で。それとも誤植？
このことから、実運用とは、複数のEAが動作し、それぞれが自分のシンボルに直接ぶら下がっているオンラインテストのことだと理解しています。そういうことであれば、質問です。各 Expert Advisor が独自のシンボルに配置されている場合、この場合、なぜバーの同期が必要なのでしょうか。おそらく、この場合のバーの同期は、複数のシンボルを同時に見て判断するような取引システムの場合、その複数のシンボル上のバーが形成される必要があるのだろう。
だいたいこんな感じです。
と、ここで、スレッドの最初の投稿をよく読んでいないことがわかりますね。タイマーイベントではなく、OnChartEvent()で。それとも誤植？
なぜ、そうしなければならないのか？そこに3番目の数字としてOnTimerがありますね。このテーマについては、すでに引用されています。あなたは、テストを正しく実行するメソッドを実装 すればよいのです。持っているんですね。 OnTimer()関数に最小間隔を設定したものです。ということは、他に何か考えていることがあるのでしょう。
1つはEURUSD ですが、Expert AdvisorはGBPUSDの チャートからEURUSDで 取引します。そしてその結果は、同じように間違っている。
もし、それがあなたにとって重要なことであるなら、私は、5におけるfxt-fileのアナログが何であるかを開発者に尋ねることをお勧めします。テストによって異なるティックベースが生成される可能性が高いことは既に書きました。