最適化結果の自動選択のための基準。 - ページ 6

 
Figar0 >>:

Т.е. если я правильно понял, как бы оценивать не результат, а качество сделок, насколько сделки отвечают тому, что заложено в систему?

Надо покрутить в голове.

一般的には、そうですね。なるべくトレードの絵が見えるようにするのがポイントです。フィルターが危険な取引を見逃したとしても、何らかの方法でマークし、トリガーされる可能性を見ておく必要があります。もし、このフィルターがメインシグナルの半径より近いところで取引のトリガーとなる確率のリスクを動かせば、将来このフィルターが設定されることになる。そして、収益性の高いものを大きく食ってしまうとまずい。信号の最も近い開口半径にあるものをすべて開いて、それを維持しようとするのは簡単です。要は半径をはっきりさせることです。

 

もしTSがうまく利益を上げていて、可能な限りのトレードを行い、ドローダウンだけが絵を台無しにしているとしたら、この病気にも治療法があるのでは...。

要は、すべてのトレードを目の前にして...ということですね。

 
ちなみに、こんな 反省も...。
 

読んでみてください、読んでみてください...


言い忘れていましたが、私が出した計算式は、比例して増えるロットでしか適用できません。

 
ivandurak >>:
А как же распределение результатов сделок . Львиная доля прибыли может быть и в начале исследуемого периода .

好きなんです。私たちは、ダニ時間ではなく、天文時間で取引しています。取引回数に比例した時間で構築されたExpert Advisorは、控えめに言っても「あまり良くない」でしょうが、ほぼ理想的な直線を示すことができます:利益の半分は、最初の100回の取引で、最初の1年間に作られ、残りの半分は最後の100回で作られますが、5年後(ほぼ同じ量の成功取引があるので同じ傾斜の直線でもあります)です。システムの相対的な利益が時間間隔そのものに依存するような、形式的なことを考えよう。

もちろん、最適化の基準は1つではないし、ありえない。まあ、形式的には、何十種類もあるいろいろな基準の中から、そういう基準を作ることは可能なのですが、それに何の意味があるのでしょうか。

 
Mathemat >>:


Единого критерия, конечно, нет и не может быть. Ну формально такой можно составить из пары десятков разнородных критериев, но какой от него толк?

数学、 あなたの意見を聞いてもいいですか - パラメータにどのようなしきい値を設定する必要があります:取引数、期待ペイオフと、積分指数によるフィルタリングについて心配する前に、例えば、1年間の最適化で収益性?例えば、トレード<50、期待ペイオフ<50、収益性<2という結果を拒否した後、ランダムフライインかクラスターがあるので数千の結果の中から選ぶのは問題ないのですが、今はクラウドということになります。クラウドから、利益 * 利益率 / ドローダウン(%)が最も高い人を機械に選ばせています。

年間の最適化における案件数、期待されるペイオフ、収益性について、専門家の判断を仰ぎたい。

 

Vita писал(а) >> Я, к примеру, после отметания результатов: сделок < 50; матожидание < 50 и прибыльность < 2 не испытываю пробелемы выбора среди тысячи результатов, т.к. остаются либо случайные залетные, либо кластер, но нынче модно говорить облако. Из облака я для себя позволил автомату выбирать у кого больше Прибыль * Прибыльность / Просадка в %.

Vita、原則的にOKです。事前審査は案件数、M.O.S.、PFで、最終審査は「濁り」とともにかなりまともな積分基準で行われます。つまり、実際には、全体の手順として5つほどの基準でフィルタリングを行っているのです。

事前審査の数値自体(m.o.、できれば旧フルポイントで、つまり4桁で?)は、かなり理にかなったものだと思います。私なら、結果の統計的妥当性を高めるために、最低取引件数を増やす(例えば200件にする)でしょう。

 

ところで、この 記事、面白いですね。回帰の理論が好きなので、導入する価値があるかもしれません...。

利益 * 利益率 / ドローダウン(%)。これは良いのですが、テスト期間が利益指数に影響しないように、1日あたりの利益率(残高に比例して成長するロットの場合)、または1日あたりの利益指数(固定ロットの場合)に置き換える方が良いです。1日あたりの割合の計算方法がわからない場合は、こちらの計算式を参考にしてください。

Pr - 1日あたり/1取引あたりのパーセンテージ

Days_Sdelki - 日数または取引数(目的に応じて、取引の割合、1日あたりの割合が異なる)

Bal_begin-期首残高

Bal_end-期末時点の残高

Pr=(MathExp(((1/Days_Sdelki)*(MathLog(Bal_end/Bal_begin))))-1)*100。

 

または、以下のような関数です。


double Procent(double Days_Sdelki,double Bal_begin,double Bal_end)
{
if(Days_Sdelki>1 && Bal_begin!=0) return((MathExp(((1/Days_Sdelki)*(MathLog(Bal_end/Bal_begin)))-1)*100);
else return(0;
} } }.

 

私は便利な変数を1つ導入し、私の計算式の新しいバージョンをテストしています。


PipBar - Pips/Bars (全取引のPipsの合計を使用したバーの量で割ったもの)

PF - プロフィットファクター

SdDay - 1日あたりの取引数です。

ProcDay - 1日あたりの利益率(対数による複雑な計算式)

MD - 最大ドローダウン

SrD - 平均ドローダウン(各注文のドローダウンの合計を注文数で割ったもの)。


If(PF>3), Vigoda=2*SdDay+(PipBar/10)+(10*(ProcDay/((MD+SrD)/10)));
else Vigoda=(PF-1)*SdDay+(PipBar/10)+(10*(ProcDay/((MD+SrD)/10)));


今のところテストバリエーションですが、すでに満足のいく結果です...。