intOnInit()
{
if(iCustom("EURUSD",PERIOD_D1,"Spy Control panel MCM",ChartID(),0,CHARTEVENT_TICK) == INVALID_HANDLE)
{ Print("Ошибка установки шпиона на EURUSD"); return(true);}
if(iCustom("GBPUSD",PERIOD_D1,"Spy Control panel MCM",ChartID(),1,CHARTEVENT_TICK) == INVALID_HANDLE)
{ Print("Ошибка установки шпиона на GBPUSD"); return(true);}
}
ここでは、ある「Spy Control panel MCM」を2つの異なる文字で「ヒンジ」していることが分かります。信号源となる記号が異なるわけですね。しかし、あなたは「EURUSDで取引している」、つまりシグナルのソースは1つの同じシンボルであると主張しています。決めましょう。
なんでその2番目のソースを取り上げるんだよ（笑)。
もし、私がメリットについて答え始めると、「別にちぎれたフレーズ」だとか、「私は何でもかんでも自分が正しいと思うよう な人間ではない」というような返答が返ってくるでしょう。それはもう明らかです。
ピンポンの件ですが、ちょっと不思議な立ち位置ですね。あるトピックに興味を持ち、答えや誘導尋問を受け、それに挑戦するか、払いのけるかのどちらかを始めるのです。そもそも、その話題はあなたや誰に必要なのでしょうか？私個人としては、このような結果は必要ありませんし、あなたが選んだ結果にはほとんど興味はありません。このテーマ自体は注目に値すると思われるが、著者の極論的熱情は、その維持の便宜に疑念を抱かせるものである。
なぜそうなるのでしょうか？そこに3つ目の数字としてOnTimerがありますね。このテーマについては、すでに引用されています。あなたは、テストを正しく実行するメソッドを実装 すればよいのです。あるんです。 OnTimer()関数に最小間隔を設定したものです。ということは、他に何か考えていることがあるのでしょう。
その前に、あなたはそう書きました。
でも、それは違うんです。
実際、あなたはすべてのシンボルで新しいバーが 刻まれる瞬間を「キャッチ」しようとしており、それを行うための最良の方法はOnTickイベントを使用することであることは明らかです。
OnTimer()でtickを「キャッチ」しようとしているのではないということです。OnTimer()では、新しいバーのチェックは各シンボルに対して個別に実行されます。このチェックは、タイマーで設定した間隔（秒単位）で行われます。
ティックのようなイベントはOnTick() 関数と Konstantin Gruzdev 氏の提案した方式、すなわちOnChartEvent() 関数で受信する。OnChartEvent()では、任意の時間枠の新しいバーの形成など、任意のイベントをトレースすることができます。
タイマーに問題はありません。さて、私は以下の方法で多通貨EAをテストします。
1.パラメータを最適化するシンボルにEAを装着し、各シンボルのパラメータを個別に最適化する。最適化処理はOnTick()関数を用いて行われます。あるシンボルのパラメータを最適化する際、他のシンボルは無効化されます。つまり、他のシンボルはテストに参加せず、パラメータが最適化されたシンボルに対してのみトレードが実行されます。
2.全シンボルのパラメータを最適化した後、全シンボルを一度にテストする必要があります。このコードをOnTimer()関数に移し、予備テスト（60秒）のためにタイマーを有効にし、得られた結果を分析します。納得がいけば、お金の管理システムなどのサブシステムをチューニングしていきます。そして、最後のテスト（タイマー10秒）を切り替えると、私の意見では、最も正確な結果を受け取ることができます。私の見解と結論は、すべての方法のテスト結果と、それらの結果の相互比較に基づいています。
マーケター
もしそれがあなたにとって重要なことであるなら、私はやはり開発者に、Fiveにおけるfxt-fileのアナログが何であるかを確認することをお勧めします。テストによって異なるティックベースが生成される可能性があることは、すでに書きました。
今のは面白い仮定ですね。ということもあるかもしれません。開発者からの返答をお待ちしています。
ディスクから読み込むよりも、オンザフライでティックを生成する方が高速であることが判明したのです。
mt5にはfxtファイルはありません。刻みはファイルに書き込まず、その場で分履歴からモデリングするようになりました。
ディスクから読み込むよりも、オンザフライでティックを生成する方が高速であることが判明したのです。
レナートさん、こんにちは。ご返信ありがとうございました。これは素晴らしいニュースです。
私は何も素晴らしいものを見ていない、それはあなたが本当のティックでテストすることはできませんmt5で判明した。
もし、私がメリットについて答え始めると、「別に抜粋したフレーズ」「私は何でもかんでも自分が正しいと思うよう な人間ではない」というような返答が返ってくるでしょう。それはもう明らかです。
いいえ、まだ何もわかっていないようですね。そして、今回で4 回目の説明となります。対話を元に戻そう。
すべてはこの瞬間から 始まったのです。
イェデルキン
コードの部分に注目してください。
ここでは、ある「Spy Control panel MCM」を2つの異なる文字で「ヒンジ」していることが分かります。信号源となる記号が異なるわけですね。しかし、あなたは「EURUSDで取引している」、つまりシグナルのソースは1つの同じシンボルであると主張しています。決めましょう。
それに対して、私はあなたに答えました。
tol64です。
おお、これは近づいてきましたね。私が勘違いしているところで、1つのバリエーションが登場したようです))。しばらく考えてから、詳しく書きたいと思います...。
想い。回答
tol64 です。
EURUSDのみでの取引となります。
私のテストでは、Konstantin Gruzdevによるスキーム - MetaTrader 5の多通貨モードの実装を考慮しています。)))すべてが定義されています。添付ファイルには、Spy Control panel MCMインジケーターとexSpy Control panel MCM Expert Advisorが含まれています。Expert Advisorをチャートにインストールすることで、その動作を確認することができます。ログには、Expert Advisor が異なるシンボルから受信した指定イベントが明確に表示されます。すべてがクリアで、何も混ざらない。
現在、OnChartEvent()でIDを受信したシンボルを指定してみましたが、結果は変わりません。OnInit()の2文字目を削除したのは、間違ったイベントを受け取る可能性を排除するためです。今回、このバリエーションでテストを実施した。
...
コード
...
絵画
...
結果が一致しない。 もう第二のシンボルはなく、シグナルはEURUSDからしか来ません。しかし、これは残念ながら問題の解決には至っていない。
ポイントは、「もうセカンドシンボルはない、シグナルはEURUSDからしか 来ない」。しかし、それは残念ながら問題を解決するものではありませんでした。"
ほらね？2つ目のソースを削除しても、問題は解決しませんでした。状況が単純化され、2つ目のソースを残すこともできたはずですが、次の問題を解こうとせず、元の例を引用し続けましたね。なぜ、1つのシンボル（シングルソース）しか持っていないのに、他のシンボルから（テストモードで）取引すると、非同一のバリアントが得られるのでしょうか？
これを表現した投稿はこちらです。
イェデルキン
まずは正しい表現から。最初の例では、「EURUSDで取引」を希望したはずです。実は、ユーザーイベントは2つのシンボルから発生しており、イベントハンドラでは、この2つのシンボルのいずれかからイベントを受信したときにTradeSignalCounter()+TradePerformer()が呼び出されていたのです。イベントキューは常に満杯だったと推測されます。
さて、シグナルソースの1つを削除したのに、なぜかイベントハンドラに「if(sparam == Symbol_01)」というチェックが入っていますね。しかし、次の質問は違います。コードから判断すると、Lizarのスキームは「All ticks」モードで使用され、関数TradeSignalCounter()+TradePerformer()がシグナルソース（EURUSD）から毎ティックで呼び出されています。興味深いのは、すでにイベントキューがオーバーフローする可能性を示唆していることです。しかし、この2つの関数のSymbol_01パラメータとしてどのような計測器が使われているのか、また、Lizarのスキームでイベントの周期性を変えることを試したことがあるのか知りたいのです。
2回目も説明 しました（なぜかホイホイと呼んでますね）。
tol64 です。
そう、それがやりたかったんです。結局のところ、私たちの行動はすべて欲求が引き金になっているのです。今回は、まさに私が望んでいたものが手に入りました。つまり、TradePerformer()関数がシンボル配列の各シンボルに対して取引が許可されているかどうかをチェックするため、EURUSDのみで取引を行ったのです。このオプションは外部変数にあり、当時はGBPUSDのシンボルを使った取引は禁止されていました。ユーザーイベントは2つのシンボルから発生しましたが、イベントハンドラでは、やはりTradePerformer()関数がEURUSDシンボルのみで取引を許可していました。TradePerformer()関数には、特定のシンボル（この場合はEURUSD）で新しいバーが発生したかどうかを判断する関数も含まれています。イベントキューが常に満杯であるという仮定は正しいのですが、この場合、すべてが別々に処理されており、日足バーでテストする場合、1ティックの遅れは重要ではありません。
テストに関与しないはずの信号源を一つ取り除いたことで、それまですべてが正しく行われていたことが確認できただけだった。テストすべきでないがテストすべき信号源を削除せずに結果を確認したときから、「if(sparam == Symbol_01)」のチェックが残っていた。このチェックは、実は余計なものであったことが判明した。結果は変わらなかった。Symbol_01 パラメータには EURUSD シンボルが使用されます。イベントの頻度を変えてみましたが、何も変わりませんでした。より正確には、全ティックモードが最も正確だと言えるでしょう。
ポイント：「このテストは、実は余計な ものだったということがわかりました。結果は変わらなかった。"
問題があなたの指摘することではないことに「気づかなかった」のはこれで2回目ですが、同じことを、さらに明確に答えています。
続けて、こう言ったんですね。
イェデルキン
"・・・以前はすべてうまくいっていた"-これは自己満足の範疇の話である。そもそもが間違っていたのです。どうやら、「イベントキューのオーバーフロー」という現象は重要視していないようですね。特に、イベントのポストイット的な伝達については。このテーマの参考資料やフォーラムをご覧になってみてください。キーワードは "キュー "です。
関数TradeSignalCounter()+TradePerformer()は1つのシグナルソースからのイベントのみを処理するため、キューの状態とそのオーバーフローの可能性は何ら変化していない。つまり、「GBRUSDシンボルによるイベント処理の禁止」は、該当するイベントをキューから全く削除していなかったのである。三度目の正直で、「イベントのキューがオーバーフローする可能性が既に示唆されていた」という問題点を指摘しています :)もし、「1ティック遅れる」程度だとお考えなら、そのような結論に至る根拠は何でしょうか。
「...この場合、すべて別々に処理されました」。問題は、オリジナルバージョンでは、両方の信号源からイベントを受信したときにイベントハンドラが関数を呼び出し、その関数がすでに「不要な」信号源からの信号をフィルタリングしていたことです。しかし、その関数は毎回（！）呼び出されていた。
イベントハンドラをどのような周期でテストするかは、あまり重要ではありません。Lizarの方式がティックバイティックでシグナルを生成するなら、イベントキューもティックバイティックでスコアリングしていることになり、1日1回ではありません。
"イベントの頻度を変えてみたが、変化がなかった。より正確には、オールティックモードが最も正確だと言えます。"ライザーの非チークモードについて、比較スクリーンショットを教えてください。
そして、3度目の正直で丁寧なお返事を させていただきました。また、あなたが嘲笑しているように見えるスマイリーも、実はあなたに対する私の親しみを表しているのです。曖昧なので、どこにも置かないようにします。
tol64 です。
おはようございます。))
この抜粋されたフレーズとは別に、「...私はどこかで間違っている可能性を排除せず、常にすべてをチェックします。しかし、どんなに厳しいチェックを受けても、一見正しく見えても、どこかに間違いがある可能性を排除することはできません」。付け加えると、私は自分がいつも正しいと思っているタイプではありません。)))
Timerのトピックを拝見しました。私が注目したのは、そのポイントです。
1.あるイベントが処理されている間、他のイベントが処理されないことがあります。
2.イベントスタックがオーバーフローした場合、古いイベントは処理されずにキューから削除される。
順を追って説明しよう。イベントの列挙があります。
...
コード
...
初期化時に、どのキャラクターから、どのイベントを受信するかを指定します。
...
コード
...
そこで、EURUSD からのみ CHARTEVENT_TICK イベントを受け付けることにします。それ以外の記号はありません。
テストが始まりました。何らかのイベントが発生すると、プログラムはOnChartEvent()関数に入り、売買シグナル用の変数配列を宣言し、イベントの有無を確認します。カスタムイベントであれば、TradeSignalCounter()でシグナルを判定し、TradePerformer()関数で新しいバーが発生したかどうかをチェックし、これに応じて他の条件を決定します。この機能は停止しており、EURUSDチャート上でイベントが発生した場合にのみ動作するようになります。つまり、この場合のティックです。
...
コード
...
これらの機能は非常に高速に実行されます。イベントキューがオーバーフローする暇もなく、重要なイベントを見逃すこともない。さらに、キューがオーバーフローしてイベントが見逃された場合、何が見逃されるのでしょうか？ダニ、ダニ2匹、ダニ3匹？それがどうした？昼間のバーでは取るに足らないことです。
この2つ目のソースで何を選んでいるのか)))もうセカンドソースはないのです。1つはEURUSDですが、Expert AdvisorはGBPUSDのチャートからEURUSDで取引します。そしてその結果は、同じように間違っている。コピーです。つまり、2つ目のソースが存在する場合と同じである。)))
-----------
自分でテストを行い、テスト結果を見せ、正しいテスト結果を得るために何をしたかを（もちろん、そうすることができれば）簡単に書いておくとよいでしょう。このテストでは、最もシンプルなエキスパートで十分です。任意の条件でエントリー、ストップロス、テイクプロフィット。過去10年間の日足バーとする。そして、あなた自身の目で確かめてください。時期が重なるものもあれば、そうでないものもあります。リザルトチャートを開いて、どこに矛盾があるのか見てみましょう。
そしてその後に書くのです。
イェデルキン
ピンポンについて......ちょっと変な位置ですね。あるトピックに興味を持ち、回答を得て、有力な質問をし、それに挑戦するか、否定し始めるのです。そもそも、その話題はあなたや誰に必要なのでしょうか？誰もあなたのために仕事をしてはくれないと思うんです。個人的には結果なんてどうでもいいし、あなたの選択の結果なんてほとんど興味ない。このテーマ自体は注目に値すると思われるが、著者の極論的熱意は、その維持の便宜に疑念を抱かせるものである。
それから、疑問もあります。
1.同じこと、つまり、もう関係ない、もう3回も答えられた、ということを繰り返していたら、どんな反応が返ってくると思ったのでしょうか。
2.なぜ私が議論していると思うのですか？ 私の回答を議論と受け取ったのなら、私は回答して説明したのですから、あなたは間違っています。しかし、あなたは自分自身が議論しているから議論と受け取ったのです。)))
3.自分の仕事を誰かに頼ることはしない。
4.私だけではなく、この問題に遭遇するすべての人がこのトピックを必要としているのです。必要ないのであれば、なぜ対話に入ったのでしょうか？私が極論に走ったのは結果であり、原因はあなたにある。
---
心理学的な観点からあなたの行動を分析することはしません。さもなければ、あなたも私も大気圏外に飛び出さなければならなくなるでしょう。ですから、対話は短く、要点を絞って行うようにしましょう。でも、必要ないのであれば、続けないほうがいい。なぜならルールを守って ください。)))
もちろん、個人的には、他人の世界観の特殊性を解析することに興味はない。あなたの極論的な熱意についての私の結論は、すでに上に述べたとおりです。付け加えることは何もありません。
...特に付け加えることはありません。
ああ、やめたほうがいい。そうでないと、ただの雑談になってしまいますから。話を元に戻そう。
---
また一連のテストを行った。前回発表したテスト結果は、モード「オープニング価格」のみで得られたものです。私見ですが、このモードではOnTimer()関数を使うことで、正しい結果を得ることができました。それ以外の方法では、正しい結果が得られませんでした。
今回は、2011年初頭から「All ticks」モードでテストを行いました。同時に、この方法にはどれくらいの時間がかかるのか、あの方法にはどれくらいの時間がかかるのか、といった面白さもありました。例えば、チャンピオンシップのExpert Advisorの自動テストでは、Expert Advisorは「All ticks」モードで15分以上テストする必要があります。今回のテストでは、12通貨ペアで取引するシンプルなExpert Advisorを構築しました。ストップロス、テイクプロフィット、トレーリングストップの 条件のみです。ポジションの拡大・縮小、資金管理システムはなく、取引ロットは固定(0.1)です。Expert Advisorは、1つのサイクルもなく書かれており、最大限に簡素化されています。すべてのシンボルでの作業時間枠はH8 です。
OnTick()を使って、順番に各シンボルのパラメータを個別に最適化しました。最適化が終わるのを待たずに、「このままではいけない」と思いました。100回実行したところで最適化を止め、最適なバリアントではなく、最もリスクの低いものを選びました。
テストを行ったプロセッサの周波数は2GHz です。ここに、何を重視するかが書かれています。
また、完全一致が目的ではないので、同一という言葉をほぼ同一に置き換えますが、グラフを視覚的に分析した場合、顕著な差はないはずです。
---
テスト結果
OnTimer()関数は、前回とほぼ同じ結果が得られたので、最初のテストに使用しました。そして今、その結果は比較のための参考となる。
OnTimer()
タイマーの間隔は60秒です。
テストは27分間行われました。
---
タイマーの間隔 300 秒。
結果はほぼ同じです。試験時間は26分です。
---
タイマー間隔 28800 秒～8 時間（使用時間枠）。
結果はほぼ同じです。試験時間は25分です。
また、1800秒と3600秒の間隔でのテストも行いましたが、こちらも結果は安定しています。
-----------
OnChartEvent()
1 分の期間はCHARTEVENT_NEWBAR_M1 です。
結果はほぼ同じです。試験時間は37分です。
---
周期1分 -CHARTEVENT_NEWBAR_H1.
結果はほぼ同じです。テスト時間27分。
---
周期1分 -CHARTEVENT_NEWBAR_H8.
結果はほぼ同じです。試験時間は27分です。
----------
OnTick()
結果はほぼ同じです。試験時間は72分です。
-----------------
All ticks "モードでは、どの手法もほぼ同じ結果を示した。OnTick()が最も長いバリエーションであることが判明しました。OnTimer()とOnChartEvent()のテスト時間はほぼ同じです。
報告する。
結論から言うと
私の場合、非常に大きなタイムフレーム（H8）で12通貨ペアで取引する最も単純な多通貨エキスパートアドバイザーでさえ、テスト（テストは15分）をパスできないので、チャンピオンシップに入れることはできません。食欲を削ぐ」、あるいはExpert Advisorのコードを最大限に最適化する方法を模索する必要がありそうです。
---
12組で高速テストを実現した人はいるのだろうか。テストの所要時間は？
12組のクイックテストを実現された方はいらっしゃるでしょうか？テストの所要時間は？
capr2011 on EURUSD:H1 every tick 2011.01.01-2011.08.01
4. スタート
3分21秒で終了
5.統計情報
1233kbのログファイル
100トレード、200ディール、利益 83043.82 USD