最適化範囲 - ページ 4

 

最適化の課題は、テスト区間で安定した結果が得られるようなTSのパラメータを見つけることである。時間幅が広ければ広いほど、将来得られる結果も信頼できる......。テスト時には、ほぼ完全な情報を得ることができるのですが...。また、時間軸によるバランスカーブやエクイティカーブも見てみたいですね...。でも、きっと夢なんだろうな...。

質問:この曲線は何のためにあるのですか?その上に折れ線というか、ジグザグを描いて極限を決めること......。浮き沈みが激しい...その結果を分析し、パラメータを選定する...

今日、テストの後、我々は1つの極限を知っている:明らかに十分ではありません最大ドローダウン...

 
Vinsent_Vega писал(а)>>

なせばなるということで、ニュートロンの 言葉を信じるかどうか悩んでいるところです...。

最適化って、アドバイザーが最適化されただけなのか、それとも何か? 真剣に研究されていると思ったのですが・・・。(私自身はイェーゾフを読んでいないので、彼の数字である「4」だと思った)。


ヴィンセント、私は 信じるべき使徒ではありません。私の投稿で引用したものは、些細な繰り返しで簡単に検証できるものばかりです。

係数については、私には難しい直接の推論と、推定という重複しない2つの方法で決定することができます。EzhovとShumskyは、最適な物語の長さの調整可能なパラメータ数に対する依存性を、ユニットのオーダーの精度定数で解析的に示しました。この依存性は応用範囲に制限がないため、特に必要のない複雑な数学的計算で遊ばないように、いくつかの例を通して最適な値を見つけ、その定常性を確認すれば十分である。それが実現しました。

 

OK、ありがとうございました...:)


なぜ、こんなに取り上げているかというと、私にとってこの質問(最適化範囲)が今の中心だからです......。ライダーの 言うとおりかもしれません。多くの点で、それは心理学の問題です。自分の選択の信頼性を納得させたいのです...。でも、どちらかの最適化方式を選ぶには、それなりの理由(できれば本格的な科学的研究)が必要なんです...。


が、どうやら経験と勘に頼るしかなさそうだ...。

 
Vinsent_Vega писал(а)>>

私にとっては、この問題(最適化範囲)が今のところ中心なのですが......。ライダーの 言う通りかもしれない...。

実はライダーが 正しいのではなく、カルコが 正しいのです。

kharko さんが 書き込みました >>1

最適化の作業は、テストした時間枠で安定した結果が得られるようなTSのパラメータを見つけることです...。時間幅が広ければ広いほど、将来得られる結果も信頼できる......。

問題はもっと広く、逆説的に言えばもっとデリケートです。実際、戦略テスタの汎化誤差の依存性を示す式に注目すると、 P個の トランザクションの増加に伴い、E=Eapprox+ Ecomplex=d/W+W/Pと 単調に減少することがわかる。つまり、学習サンプルが大きければ大きいほど...である。しかし、これは市場の不変性(定常性)の前提の下で真実であるが、実際にはそれは変更可能であり、いくつかの Pから 始まる例は、役に立たない、さらに - 有害になる。このような条件下では、これ以上例数を増やしても状況が悪化するだけなので、その限界を明確にすることが重要である。これは、モデルの複雑さによる誤差が近似誤差と同程度か、後者よりわずかに小さく、kharko が 提案したようなゼロになる傾向がない場合に起こる。したがって、 k=3-6 付近にパラメータ P=k*Wによる 緩やかな最適が存在する。

そこに係数の由来があり、市場のプロセスの非定常性という性質があるのです。

 
Neutron >> :

本当はライダーが正しいのではなく、カーコが 正しいのですが.

問題はもっと幅広く、逆説的に言えばもっとデリケートです。実際、戦略テスタの汎化誤差の依存性を示す式を参照すると、トランザクション数Pの増加に伴い、E=Eapprox+ Ecomplex=d/W+W/P と単調に減少することがわかる。つまり、学習サンプルが大きければ大きいほど良い...。しかし、これは市場の不変性(定常性)を前提にしたものであり、実際には変化しやすく、いくつかのPから始まる例は役に立たない、しかも - 有害である。このような条件下では、これ以上例数を増やしても状況が悪化するだけなので、その限界を明確にすることが重要である。これは、モデルの複雑さによる誤差が近似誤差と同程度か、後者よりわずかに小さく、kharko が 提案したようなゼロになる傾向がない場合に起こる。したがって、k=3-6付近にパラメータP=k*Wによる緩やかな最適が存在する。

この係数の由来は、市場におけるプロセスの非定常性という性質にある。

神は正しさと彼女とともにある...。私は主張しませんし、そのような権利を自分自身で見つけることはできません )))...私は非常にあなたのk=3-6を信じて、どんなフォワードもせずに行いたい...... ((......しかし何かが私を許さない、そして最も重要なのは、ルーチン作業が少なくなっていないこと:あなたは最適化装置に、ある間隔での取引数を設定できます - まったく別の会話が起こるでしょう......)

イェジョフなどへのリンクは可能ですか?

 
rider писал(а)>>

とイェジョフへのリンクなどをお願いできますか?

キャッチ、64-66ページ。

ファイル:
ts.zip  1592 kb
 
ありがとうございます
 
Neutron писал(а)>>

いやいや、待てよ!

単体での案件の頻度、単体でのテスト履歴上の最適な数値。取引結果を見てTSのパラメータを最適化する - いくつかの機能の最大値を見つける、この場合、それは累積所得または収益性(トランザクションあたりのポイント数)である可能性があります。調整可能なパラメータの数がある場合、テスターが戦略を最適化するための最も最適な取引数を見つける必要があります。時間ではなく、すなわち市場への参入と撤退の数に注意してください。

つまり、最適な取引数より多くても少なくてもいけないという、取引数だけがタスクに含まれているのです。最適な収益性、つまりトレードを発見したことになります。ある時期を過ぎると、過剰最適化が始まり、そればかりやってしまう。ストラテジーテスターにどう実装するか?考えないといけないのは...

....

テスターで最適化された5つのパラメータ(例えば、ウェービング期間)がある場合、最適な履歴の長さは、テスターがその上で4*5=20回の取引を行うようなものでなければなりません。1日~200日の履歴を残すことができますが、すべては採用した戦略次第です。この数を減らすと、テスターが履歴にフィットし、増やすと近似の質が悪くなり、結果として予測精度が悪くなる。

あなたの投稿から抜粋して引用...。結論から言うと...

フィッティングパラメータの数によって、最適な取引回数があると主張されていますが...。よし...そうしましょう.

さて、我々の仕事は、TSが推定された最適な取引回数を実行した最適な時間範囲を各ランで見つけることである......。つまり、あるパラメータは1日の履歴で十分だし、あるパラメータは1年でも十分でない...ということです。このようなバリエーションは適さない...

よし...作業を簡略化しよう...。一定の時間間隔を空けよう...。最適な取引数を得られるランだけを考えてみよう...。

どれが一番いいんだろう?答えは明白だ...。数学的期待値が最も高いのは...。

しかし、スクリーンアウトしたランはどうなるのでしょうか...?使い勝手が悪いのでは?

最適な取引回数をNとすると...。そのトレード数でランがある...。しかし、そのK倍もの案件があり...。

理想的なランは1回の取引で済むが、取引回数が理想的でない別のランは、すでにK回の取引をしている......。

では、パーフェクトランとノンパーフェクトランで得られる利益を比較してみましょう...。そのためには、取引回数に対応する期待ペイオフの値を掛け合わせる...。

理想的でないランの利益が大きく見える場合は、最適とは異なる取引量が得られたため、このランの最適化に大きな期間を取りすぎたことを意味する...。もうひとつ、矛盾が...。

最適な取引回数の条件を満たす1回の実行でも、その後、時間間隔を右か左にずらすだけで、取引回数が異なる結果になる......。

結論:提案された最適化方法はユートピアである。

 

to中性子

取引数についてもう一つ。私のEAには最大注文数というパラメータがあり、パラメータが正しく選択されていれば、EAが行う同時取引数の増加によって利益が増加しますが、一方で、EAの入力パラメータ 数に関連して、ある時間枠における最適でない取引数が得られますが、これにどう対処すればいいでしょうか。

 

このような最適化、バックテストを検討してみませんか?

int start()
{
   if(IsTesting()==true)
   {
      if(IsOptimization()==true && DayOfWeek()&0xE==DayOfWeek())return;
      if(IsOptimization()==false && DayOfWeek()&0xE!=DayOfWeek())return;
   }
//код советника
//код советника
}

の代わりに

DayOfWeek()
を使えば、例えば別の関数を置くことができます。

Month()

またはその逆で、より小さいもの。

  Hour()