#property library#property copyright"Copyright 2016, MetaQuotes Software Corp."#property link"https://www.mql5.com"#property version"1.00"#property strictclass CFF{
public:
virtualdouble fun(double & x[]){return(0);}
virtualstring type(){return("");}
virtualdouble value(){return(0);}
virtualstring note(){return("");}
};
здесь участник пишет свои классы, если надоvoid function(CFF * aff,int n,double & params[],double & value) export{
Здесь участник пишет свой код и вызывает функцию так - aff.value(x); // x - это массив double//по окончанию поиска вернуть params (параметры соответствующие лучшему результату), value (лучший результат)
}
здесь участник создает свои вспомогательные функции
簡単な例です。最適化アルゴリズムは、どこかのチャートにぶら下がっている。Expert Advisorは、内蔵のテスターでフルサーチにより最適化 されています。そのため、通常の最適化アルゴリズムではなく、独自の最適化アルゴリズムを使用することができます。
もう一つの例。Expert Advisorは、チャートの中で動作し、取引を行います。取引結果をアルゴリズム（Expert Advisor の内部でも外部でもよい）にパラメータと一緒に保存し、新しいパラメータを受信して取引を継続します（あなたの場合は履歴を実行する必要がありますが、私の場合は「ライブ」最適化を使用することができます）。
といった具合に。つまり、これらの例では、アルゴリズムはタスクから完全に独立しているのである。
これらの例を、あえてトレードに当てはめてみたのです。私たちはトレーダーです。
何か普通じゃない。
Expert Advisorはテスターで既に最適化されていますが、独自の最適化アルゴリズムとどのような関係があるのでしょうか？
2つ目のケースは、もう少しわかりやすい。はい、単体で提供すれば、1つ1つ呼び出すことができます。そして、それを別工程で一気に行うことができます。なるほど、しかし、それではアルゴリズムが複雑になり、選手権の目的に集中できません。チャンピオンシップの目的は最適化アルゴリズムであり、その応用ではありません。理解できない人がたくさんいて、今、さらに複雑になっている。
という感じで、もちろん計時カウンターもあります。
1.何か普通じゃない。Expert Advisorの最適化はすでにテスターで実行されていますが、独自の最適化アルゴリズムとどのような関係があるのでしょうか。
2.2つ目のケースは、もう少しわかりやすい。はい、単体で提供すれば、1つ1つ呼び出すことができます。そして、それを別工程で一気に行うことができます。なるほど、でもこれではアルゴリズムが複雑化し、選手権の趣旨から外れてしまいますね。チャンピオンシップの目的は最適化アルゴリズムであり、その応用ではありません。それを理解していない人がたくさんいて、今、複雑になっているのです。
1.何の変哲もない、実生活に即したもの。社内のテスターが次々とテストを行い（1つのパラメータ-カウンターを引き継ぐ）、すべてのパラメータを無制限に最適化するようコントロールしています。
2.FFとの連携は、2つのバリエーションで行うことにしました。ですから、問題なく、誰でも最適化を行うことができます。
参加者は、1つ目と2つ目のどちらのテストスクリプトを扱うか、自由に選択することができます。
このコードでは、一度だけ呼び出すのではなく、アルゴリズムの主要な部分を外部に移し、その一部を参加者に課しているのです。初期条件により、参加者はアルゴリズム全体を隠蔽する権利を有する。
そこでの押しつけはどこにあるのでしょうか。何回、何を数えるかは、参加者のアルゴリズムが決めることです。アルゴリズムは、同じGAでもアーキテクチャが大きく異なることがあり、この例では、どのような動作原理のアルゴリズムでも使用することができます。
そこでサービス機能を示したのですが、参加者が必要としない場合は空っぽにすることができます。
そこでの押しつけはどこにあるのでしょうか。何回、何を数えるかは、参加者のアルゴリズムが決めることです。アルゴリズムは、同じGAでもアーキテクチャが大きく異なることがあり、この例では、どのような動作原理のアルゴリズムでも使用することができます。
そこでサービス機能を示したのですが、参加者が必要としない場合は空になっていることがあります。
また、エポック数と個体数を分散させるために、参加者関数にFFコールの許容数を渡す。
例えば、「FFの呼び出しは最大100回まで」とアルゴリズムに指示を出すと...。嗚呼、彼（アルゴリズム）は考えた、みんなを騙して50音だけ譜面を 呼び出そう、FFを50回だけ呼び出そう、とね。:)
いや、必要な数だけ数えさせればいい。そして、いつ止めるかは私たちが決める。やはり、FFコールの数は仕事の質を表す指標として評価されるでしょう。
例えば、「FFの呼び出しは最大100回まで」とアルゴリズムに指示を出すと...。嗚呼、彼（アルゴリズム）は考えた、みんなを騙して50音だけ譜面を 呼び出そう、FFを50回だけ呼び出そう、とね。:)
いや、必要な数だけ数えさせればいい。そして、いつ止めるかは私たちが決める。結局、FFの呼び出し回数が性能の指標として判断されることになる。
回数が少ないと狡いことを言うのはどうなんだろう。少なくてもいい、多くてもいい。何が問題なのか？
FF機能は、呼び出しをカウントする。許容量を超える場合は失格とする。
これは、おおよそ会員制ライブラリの雛形と言えるでしょう。
狡猾に電話回数を減らしてどうするんだ？少なくてもいい、多くてもいい。何が問題なのか？
ff関数は呼び出しをカウントする。それ以上が認められた場合、失格とする。
FFランは少ない方がいい、それがポイントです。これは少し厄介なことです。
アルゴリズムを限定する必要はなく、カウントさせる。自分で止めることを決めるか、強制的に止めるかのどちらかです。アルゴリズムは、何本が上限なのかを知る必要はない--誰も上限を知らないだろう。失格になることはありません。アルゴリズムができたように問題を解いていく。
唯一の失格は、結果を保存して、その後のチェックスクリプトの実行に使用しようとした場合です。