MetaTrader 5 позволяет во встроенном тестере стратегий моделировать автоматическую торговлю с помощью экспертов на языке MQL5. Такое моделирование называется тестированием экспертов, и может проводиться с использованием многопоточной оптимизации и одновременно по множеству инструментов. Для проведения тщательного тестирования требуется генерировать тики на основе имеющейся минутной истории. В статье дается подробное описание алгоритма, по которому генерируются тики для исторического тестирования в клиентском терминале MetaTrader 5.
アレックス、多通貨モデルをベースモデルとして受け入れて、必要ない人はDCに懇願してシンクロバーを削って歴史を短くしたらどうでしょう。
もし私が多通貨MQとして端末を使いたかったのなら、単一通貨ベースのままにしておくと、多通貨のイベントを逃してしまい、それ故にその後のすべての問題が発生することになるのです。
モデルやテスターがどう関係するんだ？
プラットフォームのポイントは、初期情報を正確に受信し、サーバーで受信したのと同じ量で端末に格納することです。
開発者が公平な情報を提供しないかもしれない！？ダニに関する情報は、あるに越したことはありません。
もし、多通貨のテストモデルが、1分毎にバーを意味するならば、これはサーバーのモデルではなく、テスターのモデル である。
もし、インジケータ構築のモデルが、毎分バーが存在することを意味するのであれば、それはサーバのモデルではなく、インジケータの 作業のモデルである。
歴史認識やテストのモデルに合うようにサーバーを変更 するよう開発者に懇願する必要はありません、建設的ではありません。
分足の欠落した履歴が必要な場合は、証券会社に依頼して、欠落した分足のバーを1本ずつ履歴に追加してもらう必要があります。
ブローカーにMetaquotesの松葉杖を回避するように依頼しますか？シングルの場合も同じように松葉杖をつく。
分バーの開始時刻を、:00秒ではなく、最初のティック到着時刻、例えば:05や:24に保存する必要がありますか?
もし、それだけで多くのテストの問題が解決するならば、 - 端末とテスターの質は大きく向上するのでしょうか？ 多通貨テストにおいて、このような数秒のオフセットが重要なのでしょうか？
テスターはティックボリュームを使用してバー内のすべての価格をモデル 化していることを忘れないでください。最初のダニがそのまま来て、他のダニが現実のように全く来ないとしたら、得るものは大きいですか？
このシフトが次のティックに何の影響も与えないのであれば、そもそも何のためのシフトなのか？最初の正解の刻みのために？
最初のティックの実時間を考慮し、それ以降のティックをモデリングするという、実際のティック履歴 に関するテストなしには、想像上の利益としか思えません。
モデルやテスターは関係ないのですか？
プラットフォームのポイントは、端末にあるオリジナルの情報を、それが出現してサーバーに来たときの量で明確に受け止め、保存することです。
開発者は、何もプレゼントすることができないのですティックの情報量は受信時と同じで、1バイトも増えないし、減りもしない。
もし、多通貨のテストモデルが、毎分バーがあることを意味するならば、これはサーバーのモデルではなく、テスターのモデル である。
インジケータを構築するモデルが、毎分バーの存在を暗示するので あれば、それはサーバモデルではなく、インジケータの モデルである
開発者に、自分たちの歴史認識やテストモデルに合わせてサーバーを変更 するよう懇願するのは、建設的ではありません。
もし、欠落した分の履歴が必要なら、それを要求すべきです - あなたのDC、彼らは単位ボリュームで、その履歴に欠落したすべての分のバーを追加してください。
必要な思考回路に事実をごまかす :)
サーバーからティックが送信されますが、ティック履歴は どこで見るのですか？
一方、端末はサーバーに保存されている履歴を受け取りますが、なぜシンクロブロック形式ではなく、この形式でサーバーに保存することが正しいと考えられているのでしょうか？
なぜ、サーバー自体に周波数ジェネレーターがないのか？
なぜ、バーを時間でスライスするのは正しいとされているのに、周波数ジェネレーターを導入するのは正しくなくなったのでしょうか？
それなら、時間を完全になくして、十字とゼロに切り替えましょう。そこには、基本的に時間の概念がありません。
分バーの開始時刻を00秒ではなく、最初のティックの時刻、例えば:05や:24に格納したいのですか?
いや、そういうことではないんです。バーの始値を、分足が開いた瞬間のリアル口座の価格に対応させるだけです。つまり、始値のバーの始値を表示するテスターが嘘をつかないようにしなければならないのです。
多通貨のExpert Advisorのテストでは、このような数秒のずれが重要なのでしょうか？
そうなんです、著しい非同期化が起こるからです。例えば、始値で複数の関連するシンボル間でほぼ一定の裁定取引を行う状況を作り出します。
テスターはティックボリュームを使用してバー内のすべての価格をモデル 化することを忘れないでください。最初のダニがその通りに来て、他のダニが全部実物と全然違っていたら、どれだけ得をするのでしょうか？
それがあったよりもはるかに - 同期は、終値の間だけでなく、始値の間にもなります。さらに、多通貨のバーが同期されることで、最適化の際に膨大な計算資源が解放されます。これまで、どのパスでも同じ操作、つまり同期に費やしていた計算資源が解放されるのです。
最初のティックの実時間を考慮し、次のティックをシミュレートするために、実際のティック履歴 のテストなしでは、想像上の利益であるように私には思えるのです。
多通貨の履歴を保存する作業は、動画を保存する作業と非常によく似ています。有効なシンクフレームを保存し、そこから変更を保存する必要があります。
現在、シンクロフレームは一切なく、シンクロラインのみです。各ライン（通貨ペア）はその変更を保存し、ラインであっても同期ポイントを持ちません。
この時点（バーオープン）の価格が正確であったとは、確実に言えないのです。
バーのオープニングがxx:yy:00で、オープニングティックがxx:yy:12なので
バーの開始時刻がxx:yy:00、開始ティックがxx:yy:12であったため
そのように格納するためには、それが正しいことであり、誰もが利益を得られることを開発者に納得させるために、多大な労力を費やす必要があります。
ただ、サーバーエンジン（と端末エンジン）をバーの保存と処理のために書き換えるよう説得する必要があります)
この状況では、より多くの抵抗（80％）が説得の第一段階になります。そして、その後はプログラマー次第です。
VelesとGaneshが彼らを助けることができますように
この時点（バー・オープニング）で、価格が正確にそこにあったとは、確実に言えないのです。
バーのオープン時間がxx:yy:00で、オープニングティックがxx:yy:12であったため
終値だけを ターゲットにすれば可能です。しかし、そのためには、Close[1]を現在の価格として、分（バーではなく）終値イベントを追跡する必要があります。
このような回避策は、開発者が使う完全に人為的な松葉杖ですが、裏技的な解決策です。
開発者が状況を変更しても、Ask価格のシミュレーションでは、テスターの実通貨分析でも多通貨分析でも非同期が発生します。
それは、深刻な非同期を与えるからです。例えば、始値で 複数の連動するシンボルの間で、ほぼ一定の裁定取引を行う状況を作り出します。
...実際には存在しないが、テスターが裁定取引が存在するとテスターの中で錯覚させる。
そうだろ？
...という、実際には存在しないが、テスターが仲裁が存在するように錯覚させるもの。
そうだろ？
全くその通りです。現実には裁定取引は存在せず、テスターでは一見正確に見える（モデル化されていない）過去のデータ、つまり始値で 裁定取引価格を表示しています。
まずいな...。
ここで私は、多通貨分析は避けるべきで、そうでなければ額をかきむしることになると、いつも脳裏に感じていたのです。理由があって避けたようです。