/*
Входные параметры индикатора
extern int FastEMA=12;
extern int SlowEMA=26;
extern int SignalSMA=9;
*/double signal=iCustom(Symbol(),Period(),"MACD",
FastEMA,//параметр 1
SlowEMA,//параметр 2
SignalSMA,//параметр 30,//номер буфера индикатора
SignalBar);//бар, с которого получаем данные (внешняя переменная)
このiCustomの 行だけ変更されるのですね。では、この指標を詳しく見ていく必要があります。
トピックを間違えています。問題は明らかにEAにあるのに、あなたは最適化に集中している（パラメータ転送など）。最適化のことはしばらく忘れて、EAにコメントやプリンターを入れ、ビジュアルでパラメータを変えて実行し、中間データをコントロールし、すべてのエラーを見つけ、最適化に戻る。
同じ結果で、最適化されたパラメータは取引シグナルの形成に影響しないことがわかり、これはテスターではなくEAの問題であることがわかります。
(iCustom(NULL, 0, "ART", MA_Period, KFK, 0, 1), Digits); - このようにパラメータを設定すると、上で例を挙げたように、すべてのゼロが表示されます。
iCustom(NULL, 0, "ART", 0, 1), Digits); を設定すると、計算値が表示されます。
が、テスターで、異なるパラメータで実行すると、取引結果が大きく異なるが、すべて同じである。
アンジェラさん、最適化が機能するためには、オプティマイザーによって変更された値を何らかの方法でアルゴリズムに使用する必要があり、特にインジケーターに渡す必要があります。インジケータを最適化したい場合は、パラメータを渡す必要があります。パラメータなしでインジケータを呼び出す場合（つまり2番目のケース iCustom(NULL, 0, "ART", 0, 1)）、実際にはパラメータを省略し、ARTのデフォルトパラメータで動作します（最適化はされていません）。最初のオプションであるパラメータ付きのフルコールは、最適化のために必要なものです。ほとんどの場合、パラメータを正しく渡していないことが問題です。例えば、インジケータ内のその数が少ない場合に、より良い値を渡したり、逆に、すべてのパラメータを渡さなかったりする場合です。インジケータが秘密なら、せめてそのパラメータのリストを教えてください。
インジケータからEAに送られるパラメータの順番が一致していなかったのが原因でした。
は、Expert Advisorの中で
extern int MA_Period=151; // 101 10 201
extern double KFK=0.9; // 0.7 0.005 1.
逆にインジケータで
extern double KFK=0.9; // 0.7 0.005 1.
extern int MA_Period=151; // 101 10 201
は、可視化モードではうまくいきましたが、最適化モードでは うまくいきませんでした。
おめでとうございます。また、パラメータを渡す際にも、細心の注意を払うことに慣れるまでは苦労したことを覚えています。ここで、Expert Advisorに全てのexternを含むインジケータコードの一部をコピーし、サンプルを見ながらiCustomを 書き込んでみます。ちょっとオブラートに包んでいますが、それ以来、エラーはありません。
もうひとつ。komposterさんの イラスト風iCustomを調べてみました。すべてが手のひらの上にある。
私のTSの第2版をデバッグしていますが、第1版と比較して、ドローダウンが2倍になったにもかかわらず、取引数が増え、最適化できるパラメータの数が大幅に減少しています。
800回以上の実行は心もとないし、6月の最適化の結果は、同じ期間の初期パラメータでのテストより悪い。6月、7月、8月と3つの統計を持ってきましたが、今のところBuyしかデバッグしていません。 このようなシステムを、安定した結果で最適化のために引き抜くことができるのか、それともすぐにでも新しいシステムの開発に着手すべきなのでしょうか？
mql-codeだけがExpert Advisorに関与している場合、800の実行が始値で遅くなることはないはずなので、何かが間違ってコーディングされているはずです。それとも私が何か勘違いしているのでしょうか。通常、ニューラルネットワークライブラリなどの外部バインディングを持つエキスパートは、とても遅いです。もちろん、mqlが多くのループをネストしている（または、いくつかの "貪欲な "インジケータの呼び出し）ことも想定できます。したがって、私はリファクタリングの必要性を想定した考えを繰り返すしかないのです ;-)- コードの一部または全体を再確認し、再変換する。
記事を書いている時点で8000本以上のうち800本が経過し、5時間の最適化が行われ、まだ2日残っていたのです。しかし、私は最後まで待たず、いくつかのパラメータの列挙範囲を狭め、再起動したところ、8時間ですべての最適化が完了したのです。
最高の結果です。
利益が出ている取引の数が負けている取引の数を上回っている、平均して利益が出ている取引が負けている取引より多いのは非常に良い兆候です。私の意見では、このシステムをあきらめずに、もっと長い期間、その挙動を研究する必要があります。また、別のクロスに貼ることもできます。