Expert Advisors最適化のカスタム基準作成
はじめに
MetaTrader 5 クライアント端末は Expert Advisor パラメータを最適化する幅広い機会を提供します。またストラレジーテスタに含まれる最適化評価基準に対して、開発者には自身の基準を作成するチャンスが与えられています。これは Expert Advisorsを検証し最適化する数えきれない可能性に導きます。本稿ではそのような基準を、複雑なもの単純なもの双方、作成する実践的方法について記述します。
1. ストラテジーテスタ機能のレビュー
このテーマについては何度も話されてきましたので、ここでは手短に項目を挙げるだけとします。また本稿の前に下記資料を一読されることをお薦めします。
- 『MetaTrader5検証の基礎』 Expert Advisor を検証する技術的側面が詳しく取り上げられています。ティック作成モード、始値との連携、M1バーといった内容です。検証時インディケータの用と、環境変数のエミュレーション、標準イベントの処理について述べています。その上、複数通貨検証の基礎についても述べています。
- 『MQL5においてExpert Advisorsを検証し最適化するガイド』 Expert Advisorの入力パラメータの検証および最適化の課題を取り上げています。パラメータの調整処理、検証結果の解釈、最適なパラメータ選択について述べています。
- 『収益引き出しモデル化関数TesterWithdrawal() の使用』 ストラテジーテスタのアカウントから資金を引き出すモデル化をするTesterWithdrawal 関数の使用について述べています。また、ストラテジーテスタの資金消耗のアルゴリズム計算にこの関数が 与える影響も示しています。
そしてもちろん、クライアント端末に提供されているドキュメンテーション に精通することがなにより必要です。
2. Strategy Tester内蔵最適化評価基準
ドキュメンテーションを見ると、以下の記述に気づくでしょう。: 最適化 基準 は特定の要因で、その値が検証されたパラメータセットの質を決定する。最適化評価基準値が高いほど、既定のパラメータセットの検証結果は良くなると考えられます。
ここで重要な注意点があります。最適化評価基準は最適化の遺伝的アルゴリズムモードでのみ使用可能だということです。可能なパラメータ値の組合せを検証する際、Expert Advisorの最適なパラメータを選択する要因は何もないというのは明らかです。逆に検証結果を保存し、最適なパラメータの組合せを見つけるべくその結果を加工することができます。
ドキュメンテーションに記載されているように、ストラテジーテスタには以下が含まれています。遺伝的アルゴリズムで使用する最適化評価基準:
- 残高最大 - 残高の最高値
- 残高 + 最大収益要因 - 残高結果および 収益の最大値
- 残高 + 最大期待ペイオフ - 残高結果および 期待ペイオフの最大値
- 残高 + 最低ドローダウン - この場合、残高値およびドローダウンレベルを考慮に入れます。:(100% - ドローダウン)× 残高
- 残高+ 最大リカバリー要因 - 残高結果およびリカバリー要因
- 残高+ 最大分配率 - 残高結果および Sharpe 比率
- カスタム最大 - 最適化のカスタム基準ここでの最適化評価基準とはExpert Advisorの OnTester()関数の値です。このパラメータにより Expert Advisorの最適化にあらゆるカスタム値を使用することが可能となります。
最適化評価基準は図1に示すようにストラテジーテスタの設定 タブで選択することができます。
図1 Expert Advisorの最適化評価基準選択
リストの最後に挙げたカスタム最大基準 はもっとも興味をひかられるもので、その用途が本稿のテーマとするところです。
3. カスタム最適化基準の作成
まず最初におこなうことは、ユーザーがパラメータ組合せを自由におこなえるようにすること(図1に表示されたものに限るのではなく、カスタム)で、それは毎回 Expert Advisor を実行した後ストラテジーテスタによって計算されるものです。
たとえば、以下のバリアントがおもしろいと思います。: 最大残高 + 最小ドローダウン + トレード数 - トレード数が多いほど結果の信頼性は上がります。あるいは次のバリアントです。 - 最大残高 + 最小ドローダウン + 最大収益要因。もちろん、ストラテジーテスタ設定に含まれていないものの中で興味をひかれるものは他にたくさんあります。
そのような基準の組合せを最適化のシンプルな基準と呼びましょう。
ただし、そういった基準はトレードシステムの信頼性ある推定をするには十分ではありません。最小リスクで収益を上げるというトレーディングコンセプトの視点で見ると、次の基準が考えられます。個別のトレード結果に対して直線から最小偏差の、できるだけなめらかな残高曲線を得るためにパラメータを最適化します。
この基準を残高曲線による最適化基準と呼びましょう。
次に使用する最適化評価基準はトレードシステムの安全係数です。この係数については"Be In-Phase" 稿に記載があります。この基準はトレードシステムがどのようにマーケットへに対応しているか決めます。それはパラメータ最適化中に見つける必要のあるものです。それをトレードシステムの安全係数による最適化基準 (CSTS)と呼びましょう。
また、それをここで挙げている基準と自由に組み合わせることができるようにします。
4. OnTester() 関数
コード部分を書く前に、ストラテジーテスタにおける EA 最適化のカスタム基準用法をまとめます。
定義済み関数OnTester() は最適化のカスタム基準を作成します。この関数は特定の時間範囲で Expert Advisor の検証が渡されるごとにその終わりで自動的に呼ばれます。これはOnDeinit() 関数が呼ばれる直前に呼ばれます。
OnTester() 関数を使うには、図1にあるように最適化の高速遺伝的基本アルゴリズム モードを有効にする必要があることに再度注意を払ってください。
この関数の戻り値はダブル フォーマットです。これはストラテジーテスタの最適化に使用されるものです。
もう一度ドキュメンテーションを見てみます。
遺伝的最適化では一世代内で結果に対して降順でソートが行われます。それは最適化基準の視点から、最良結果は最大値を持つものであるということです。そのようなソートでは、最悪の値は最後に来、 のちには捨てられ、次世代を形成するのに使用されません。
よって、カスタム最適化基準を作成するときには、 Expert Advisorのトレーディングを推定するために使用される整数値を得る必要があります。値が大きいほどExpert Advisorのトレーディングは良好であると言えます。
5. 実験的Expert Advisorのプログラミング
ここからはストラテジーテスタを最適化する Expert Advisor を作成していきます。そのためにここで要求されることはシンプルで速いということです。それにより最適化のルーチン処理にかかる時間を節約します。また、望ましのはExpert Advisor の収益性があまり高くないことです。
実験的なExpert Advisor として"Several Ways of Finding a Trend in MQL5" 稿で述べられているものを利用し、それを改善します。特に3つの移動平均の「ファン」を基にしたEA です。改善点は、処理スピードを上げるためにインディケータ使用をやめること、 EA 自体にあるコードの計算部分を移動することです。これにより検証スピードが格段に上がります。(2年の範囲でほとんど3倍になります)。
入力パラメータを設定する部分は簡単です。
input double Lots = 0.1; input int MA1Period = 200; // period of the greatest moving average input int MA2Period = 50; // period of the medium moving average input int MA3Period = 21; // period of the smallest moving average
これから最適化していくのは移動平均の期間です。
Expert Advisor のストラクチャと処理は前述の記事に詳しく記載されていますので、ここでは省きます。主要な改善点は別の検証を通過するイベント完了のハンドラで、それはOnTester() 関数です。今はその部分は空になっており、コントロールを返します。
//--------------------------------------------------------------------- // The handler of the event of completion of another test pass: //--------------------------------------------------------------------- double OnTester() { return(0.0); }
EAのファイル、FanExpert.mq5 は本稿に添付があります。それは行われる取り引きという点においてFanTrendExpert.mq5 EA と一致していることがわかります。シグナルが存在していることとその方向の確認はチャート上に新規バーが開始されるときに行われます。
各通過の終わりで計算される検証結果を得るには、 TesterStatistics() が使われます。それは要求される、検証結果として計算された統計値を返します。それは関数 OnTester() および OnDeinit() からのみ呼ばれます。それ以外は結果は不明確です。
それではカスタム最適化基準を追加します。リカバリー要因の最大値に基づく最適な結果、すなわち「最大リカバリー要因」を見つける必要があるとします。そのためには、資金の残高ドローダウン最大値、検証の終わりの粗利益を知る必要があります。リカバリー要因は最大ドローダウンにおける収益の分配として計算されます。
まったくこの例と同じように行われます。というのもリカバリー要因はすでに計算された統計的検証結果リストに含まれているからです。
そのために以下の簡単なコードを OnTester() 関数に追加します。
//--------------------------------------------------------------------- // The handler of the event of completion of another test pass: //--------------------------------------------------------------------- double OnTester() { double profit = TesterStatistics(STAT_PROFIT); double max_dd = TesterStatistics(STAT_BALANCE_DD); double rec_factor = profit/max_dd; return(rec_factor); }
ゼロ除算チェックはコードを簡単にするためにコードから除外されています。最大ドローダウンはゼロとなることもあるので、このチェックは実際のExpert Advisorでは必要です。
では、前述の基準を作成します。:最大残高 + 最小ドローダウン + トレード数 - 残高 + 最小ドローダウン + トレード数です。
そのために次のように OnTester() 関数を変えます。
double OnTester() { double param = 0.0; // Balance max + min Drawdown + Trades Number: double balance = TesterStatistics(STAT_PROFIT); double min_dd = TesterStatistics(STAT_BALANCE_DD); if(min_dd > 0.0) { min_dd = 1.0 / min_dd; } double trades_number = TesterStatistics(STAT_TRADES); param = balance * min_dd * trades_number; return(param); }
ここではドローダウンと逆の値を取ります。なぜなら別の条件が同じだとすると、ドローダウンが小さいほど、状況は良いといえるからです。2009.06.01 ~ 2011.06.03 期間、 Н1 の時間枠でMA1Periodパラメータにより作成された最適化基準を使用してFanExpert EAの最適化を実行します。移動平均値範囲を 100 ~ 2000に設定します。
最適化の最後で、以下のような最良パラメータによってソートされた値のテーブルを取得します。
図2 最大残高 + 最小ドローダウン + トレード数基準で最適化した最良結果
最良パラメータをここにリストアップします。(結果 表で)
では最悪パラメータを見ていきます。
図3 最大残高 + 最小ドローダウン + トレード数基準で最適化した最悪結果
2種類の表を比較すると、ドローダウンと収益がトレード数に従って判断されているのが判ります。要するにわれわれの最適化基準は役に立っているのです。また、最適化グラフ(折れ線グラフ)も確認できます。
図4 最大残高 + 最小ドローダウン + トレード数基準の最適化グラフ
横軸は最適化パラメータを、縦軸は最適化基準を表します。設定された基準が最大値を表しているのは明らかです。それは期間の980 ~ 1200 の範囲に位置しています。
これは全面的な調査ではなくパラメータの遺伝的最適化だったことを理解し思い出す必要があります。そのため、図2および図3の表には複数世代で自然な選択を渡した存続可能なパラメータが含まれているのです。おそらくいくつか問題ないバリアントが廃棄されてしまっていると思われます。
期間1106に対する残高/資本曲線は以下です。
図5 MA1Period = 1106 期間に対する残高/資本曲線
6. カスタム最適化基準のクラス作成
シンプルな最適化基準の作成方法と使用方法を学習しました。ここから Expert Advisorsで最適化基準の使用を簡素化するクラスを作成していきます。そのようなクラスに対する主要な要件のひとつは使い勝手がよいことに加えて処理スピードです。最適化基準の計算はすばやく行う必要があります。そうでないと結果を長く待つことになります。
MetaTrader 5 により最適化をするためにクラウド計算技術を使用することが可能です。これはたいへん大きなブレークスルーです。というのも大きなパラメータの数字処理には巨大な計算力が必要とされるからです。われわれのクラスを作成するために、プログラム的にあまり洗練されたものでないとしても、もっとも簡単で速い方法を採用することにします。
作成のために、クライアント端末と同送の標準的データ整列クラス を使用していきます。
まず計算された検証の統計結果を分類することから始めます。
- 検証結果と最適化基準のが正比例の浮動小数点型または整数型。
言い方を変えると、検証結果値が大きいほど、最適化基準値は良好で大きいということです。検証のそのような結果の特筆すべき例は検証の終わり時点での粗利益 STAT_PROFITです。値は浮動小数点型で負の無限大(実際にはそれはデポジット値で制限されています)から正の無限大に変化します。
その他このタイプの検証結果例は トレード数 STAT_TRADESです。一般的に、トレード数が増えると最適化結果の信頼性は高まります。値は整数型でゼロから正の無限大に変化します。
- 検証結果と最適化基準が反比率の浮動小数点型または整数型。
言い方を変えると、検証結果値が小さいほど、最適化基準値は良好で大きいということです。このタイプの検証結果例は資金残高の最大ドローダウンSTAT_BALANCE_DD およびその他あらゆるドローダウンです。
このタイプの検証結果を得るには、最適化基準値の計算の逆数を得ます。エラーを防ぐため、もちろんゼロ除算チェックを実装する必要があります。
最適化のカスタム基準作成の基本クラス、 TCustomCriterion はひじょうにシンプルです。それは基本機能を決めます。このクラスは以下です。
class TCustomCriterion : public CObject { protected: int criterion_level; // type of criterion public: int GetCriterionLevel(); virtual double GetCriterion(); // get value of the result of optimization };
仮想メソッド TCustomCriterion::GetCriterion は派生クラスにオーバーライドする必要があります。これが各検証通過時に Expert Advisor 検証の統合結果値を返す主要なメソッドです。
TCustomCriterion::criterion_level クラスメンバはこのクラスインスタンスに固有のカスタム基準タイプを格納します。それはのちにそのタイプによってオブジェクトを識別するために使用されます。
ここで、最適化に必要なクラスをすべてこのクラスから継承します。
TSimpleCriterion クラスは検証の特定統計結果に対応する「シンプルな」カスタム基準を作成します。それは以下のように決定されます。
class TSimpleCriterion : public TCustomCriterion { protected: ENUM_STATISTICS stat_param_type; public: ENUM_STATISTICS GetCriterionType(); // get type of optimized stat. parameter public: virtual double GetCriterion(); // receive optimization result value TSimpleCriterion(ENUM_STATISTICS _stat); // constructor };
ここでパラメータを伴うコンストラクターを使用します。以下はその実装です。
//--------------------------------------------------------------------- // Constructor: //--------------------------------------------------------------------- TSimpleCriterion::TSimpleCriterion(ENUM_STATISTICS _stat) : stat_param_type( _stat ) { criterion_level = 0; }
MQL5 言語 におけるこの新しい機能はクラスインスタンスを作成するのに有用です。また、検証通過の最終段階で最適化結果を取得するのに使用する仮想メソッドTSimpleCriterion::GetCriterion をオーバーライドします。その実装は以下のように簡単です。
//--------------------------------------------------------------------- // Get the result of optimization: //--------------------------------------------------------------------- double TSimpleCriterion::GetCriterion() { return(TesterStatistics(stat_param_type)); }
ご覧のように、それは対応する検証の統計結果を返すだけです。
次の「シンプルな」最適化のカスタム基準は TSimpleDivCriterionクラスを用いて作成されます。これは検証結果値と最適化基準が反比例 する基準を作成します。
TSimpleDivCriterion::GetCriterion メソッドは以下のようなものです。
//--------------------------------------------------------------------- // Get value of the optimization result: //--------------------------------------------------------------------- double TSimpleDivCriterion::GetCriterion() { double temp = TesterStatistics(stat_param_type); if(temp>0.0) { return(1.0/temp); } return(0.0); }
このコードにこれ以上記述はまったく必要ありません。
あと2つ「シンプルな」最適化のカスタム基準タイプはクラス TSimpleMinCriterion および TSimpleMaxCriterion です。それらはそれぞれ下と上両方からの検証の統計結果の限られた値を持つ基準を作成します。
最適化の途中、 故意に誤った値を廃棄する必要がある場合に有用です。たとえば、トレードの最小数、最大ドローダウン値などを限定することができます。
TSimpleMinCriterionクラスの記述は以下です。
class TSimpleMinCriterion : public TSimpleCriterion { double min_stat_param; public: virtual double GetCriterion(); // receive optimization result value TSimpleMinCriterion(ENUM_STATISTICS _stat, double _min); };
ここでは2つのパラメータを持つコンストラクタを使用します。_min パラメータは検証の統計結果の最小値を設定します。別の検証通過が指定値よりも小さい値を取得する結果に終われば、その結果は廃棄されます。
以下はTSimpleMinCriterion ::GetCriterion メソッドの実装です。
//--------------------------------------------------------------------- // Get value of the optimization result: //--------------------------------------------------------------------- double TSimpleMinCriterion::GetCriterion() { double temp = TesterStatistics(stat_param_type); if(temp<this.min_stat_param) { return(-1.0); } return(temp); }
TSimpleMaxCriterion クラスは同様に作成されますから、これ以上の記述は必要ないと思います。「シンプルな」カスタム基準のその他クラスは前述のクラスと似ています。それらは本稿添付のCustomOptimisation.mqh ファイルにあります。最適化に使用されるその他クラスの作成には同じ原理が適用されます。
前述のクラスを使用する前に基準セット処理をしやすくするためのコンテナクラスを作成します。このためにはまた標準的なデータ整理用クラスを使用します。基準のシンプルな処理が必要なので、これに最も適したクラスはCArrayObjです。それにより CObject クラスから派生する動的オブジェクト配列を整理することができます。
以下はコンテナクラス TCustomCriterionArray の記述です。
class TCustomCriterionArray : public CArrayObj { public: virtual double GetCriterion( ); // get value of the optimization result };
そこにあるメソッドはただ一つだけです。 - TCustomCriterionArray::GetCriterionで、これは各検証を通過する最終段階で最適化基準値を返します。以下がそれの実装です。
double TCustomCriterionArray::GetCriterion() { double temp = 1.0; int count = this.Total(); if(count == 0) { return(0.0); } for(int i=0; i<count; i++) { temp *= ((TCustomCriterion*)(this.At(i))).GetCriterion(); if(temp <= 0.0) { return(temp); } } return(temp); }
注意事項としては、基準処理中に負の値にでくわすと、それ以降サイクルを通過するのは無意味となります。また、2つの負の値の乗算結果として正の値を得た場合、除外します。
7. カスタム最適化基準クラスの使用
これで、Expert Advisors最適化中に「シンプルな」カスタム基準を使用するのに必要なものは出そろいました。「実験的」 EA FanExpertを改善する一連のステップを分析します。
- カスタム基準クラスの記述を持つインクルードファイルを追加します。
#include <CustomOptimisation.mqh>
- カスタム基準を使用するためにコンテナクラスのオブジェクトにポインターを追加します。
TCustomCriterionArray* criterion_Ptr;
- カスタム基準を使用するためにコンテナクラスのオブジェクトに対しポインターを初期化します。
criterion_array = new TCustomCriterionArray(); if(CheckPointer(criterion_array) == POINTER_INVALID) { return(-1); }
それは OnInit 関数で行われます。オブジェクトの作成が失敗した場合は、負の値を返します。この場合、Expert Advisor は処理を停止します。
- 要求される最適化基準をExpert Advisorに追加します。
criterion_Ptr.Add(new TSimpleCriterion(STAT_PROFIT)); criterion_Ptr.Add(new TSimpleDivCriterion(STAT_BALANCE_DD)); criterion_Ptr.Add(new TSimpleMinCriterion(STAT_TRADES, 20.0));
ここでは、最大収益+最小ドローダウン+最大トレード数 でEA を最適化すると決めました。また、トレード件数20未満の結果を出すExpert Advisor の外部パラメータセットは廃棄します。
- OnTester 関数に対応する呼び出しを追加します。
return(criterion_Ptr.GetCriterion());
- OnDeinit 関数には、コンテナオブジェクト削除用コードを追加します。
if(CheckPointer(criterion_Ptr) == POINTER_DYNAMIC) { delete(criterion_Ptr); }
これが最適化に必要なすべてです。最適化を実行し、すべてが意図したとおり動作しているか確認します。そのために、下の図のようにストラテジーテスタの設定 タブでパラメータを設定します。
図6 ストラテジーテスタの設定
図7に示されるようにストラテジーテスタの 入力パラメータタブで入力パラメータの最適化範囲を設定します。
図7 最適化入力パラメータ
最適化に「クラウド」エージェントを使用します。そのあtめにエージェント タブで以下のパラメータを設定します。
図8 検証エージェントのパラメータ
開始 ボタン(図6)をクリックし、最適化が完了するのを待ちます。「クラウド」計算技術を使用する場合、最適化はひじょうに速く行われます。最後に指定の基準による以下のような最適化結果を得ます。
図9 最適化結果
ここでの「実験的」Expert Advisor は問題なく最適化されました。「クラウド」エージェントの使用により、最適化は13分で終わりました。この基準を確認するための EA は本稿の添付ファイル FanExpertSimple.mq5 にあります。
8. 残高曲線分析を基にしたカスタム最適化基準クラスの作成
このクラスを作成する基本は記事『Expert Advisor作業時の残高曲線傾斜制御』 にあります。この最適化基準の狙いは残高線が最大限直線に近づくようにすることです。直線への接近度は、トレード結果のそこからの標準偏差値によって判断されます。直線の式はストラテジーテスタ内取り引き結果によって描かれる回帰ラインに対して計算されます。
負の結果残高曲線を排除するために、別の制限を加えます。結果としての収益は指定の値より大きく、トレード数は指定値より小さくなってはいけない、というものです。
よってこの最適化基準は結果収益およびトレード数を考慮した直線からのトレード結果の標準偏差値に反比例しています。
残高曲線に基づく最適化基準を実装するには、前述の記事にあるTBalanceSlope クラスが必要です。それを変更します。パラメータを持つコンストラクタ(便宜上)を使い、線形回帰の計算に標準偏差計算を追加します。このコードは本稿の添付ファイル BalanceSlope.mqh にあります。
Expert Advisor にこの最適化基準を追加する一連のステップは上記同様です。そして以下が最適化基準の記述です。
criterion_Ptr.Add(new TBalanceSlopeCriterion(Symbol( ), 10000.0));
残高曲線基準に加え、ここで作成した別の基準も追加することができます。読者のみなさんには、異なる検証の統計パラメータセットを用いて実験する可能性を残しておきたいと思います。
では設定した基準により最適化を実行します。もっと数多くのトレードを取得するには時間枠 H4 、期間 2010.01.01 ~2011.01.01 、対象シンボルEURUSDで最適化を行います。結果セットを取得します。
図10 残高曲線による最適化結果
ここで最適化の質を判断する必要があります。主要な基準は 最適化期間外でのExpert Advisor の動作だと思います。それを確認するために期間 2010.01.01~2011.06.14 を対象にひとつだけ検証を行います。
最適なパラメータセットから得た2とおりの結果(最終収益は同じような値です)を中央からの結果を持つ最良結果と比較します。最適化期間外の結果は赤線で区切られています。
図11 最適化の最良結果
一般的に曲線の変動は悪くはなりません。収益性は 1.60 から 1.56へとわずかに下がっています。
図12 検証の中央結果
最適化の外側ではExpert Advisorは収益的ではありません。収益性は 2.17から 1.75へと大きく下がっています。
残高曲線と最適化されたパラメータの動作継続期間の間の相関関係についての仮説は確かに存在するという結論を導くことができます。この基準を用いた満足のいく結果が Expert Advisorにとって到達不可能な場合、確実にバリアントを除外することはできません。この場合は別の分析や実験が必要となります。
おそらく、この基準については可能な(が合理的な)最大期間を使う必要があるでしょう。この基準を確認する Expert Advisor は 本稿の添付ファイル FanExpertBalance.mq5 にあります。
9. 安全トレードシステムの係数を基にしたカスタム最適化基準クラスの作成
記事"Be in-Phase" で述べられているとおり、安全トレードシステム係数 (CSTS) は以下の式を使って計算されます。
ここで
- Avg.Win - 収益性ある取り引きの平均値
- Avg.Loss - 取り引きを失う平均値
- %Win - 収益性ある取り引きの割合
CSTS 値が1より小さければ、トレーディングシステムは取り引きリスクが高いゼロにあたります。値がもっと小さくても収益性のないトレーディングとしてのゼロを指し示します。CSTS値が大きければ、トレードシステムはマーケットに適切であり、収益性があると言えます。
CSTS 計算に必要な統計値はすべて各検証に通過したのちのストラテジーテスタにあります。残っているのは TCustomCriterion から派生する TTSSFCriterionクラスの作成と、それにGetCriterion() メソッドを実装することです。以下がコードにこのメソッドを実装する記述です。
double TTSSFCriterion::GetCriterion() { double avg_win = TesterStatistics(STAT_GROSS_PROFIT) / TesterStatistics(STAT_PROFIT_TRADES); double avg_loss = -TesterStatistics(STAT_GROSS_LOSS) / TesterStatistics(STAT_LOSS_TRADES); double win_perc = 100.0 * TesterStatistics(STAT_PROFIT_TRADES) / TesterStatistics(STAT_TRADES); // Calculated safe ratio for this percentage of profitable deals: double teor = (110.0 - win_perc) / (win_perc - 10.0) + 1.0; // Calculate real ratio: double real = avg_win / avg_loss; // CSTS: double tssf = real / teor; return(tssf); }
この最適化基準には短期間が適していると考えます。ただし、一致するのを避けるために最適化結果の中央にある結果を取るのがよいでしょう。
読者のみなさんがご自身で最適化を行うチャンスを提供しましょう。この基準を確認する Expert Advisor は 本稿の添付ファイル FanExpertTSSF.mq5 にあります。
おわりに
いずれにしても、カスタム最適化基準を作成する機能実装に対するそのようなシンプルなソリューション(ひとつの統合レートのみ使用した)は、その他のバリアントに比べるとほとんど完璧です。それによりトレードシステムの開発バーを高いレベルに挙げることができるのです。また「クラウド」技術を使用することで最適化に伴う限界をかなり減少します。
さらに進化した方法は、異なる情報源で述べられているように、数学的また統計的に実証される基準と関連しているかもしれません。われわれにはそのためのツールがあるのです。
MetaQuotes Ltdによってロシア語から翻訳されました。
元の記事: https://www.mql5.com/ru/articles/286
- 無料取引アプリ
- 8千を超えるシグナルをコピー
- 金融ニュースで金融マーケットを探索