ローリングフォワードの実施方法 - ページ 8

新しいコメント
 
Youri Tarshecki:
また、このOOSでは、どのようにウイニングセットが使える ようになるのですか？
OOSは内部で、テスターにOOS期間に取引させ、好きなパラメータを入れて、すでにセットが見つかっている状態です。
 
Alexandr Andreev:

4年前、彼らはボルキング・トレーディングの調査を開始しました...非常に厳しく。

そして、質問があるのですが、Volkingに何を求めているのでしょうか？デモでテストする必要がないように、システムが機能するかどうかを調べるため？

かっこいいけど、どうせならデモで試してほしい。プロトシステムがボルキングで動くことを期待していると、そうではなく、彼は大規模なテスト中にすべてが間違っているとよく言うのです。

ボルキングに巨大なサンプルを与えているので、どうしても（方向性を決めるために）縮小できないのです。そうしないと、ボルキングの原理全体がその場で壊れてしまうからです。そして、全計算の8割が無駄になってしまうのは、エージェントとの仕事の特殊性が原因です。つまり、最初の3日間で、今持っているものより悪い結果になることがわかったら、最後までテストを続けるということです。

ボルキングトレードの戦略は、どれだけ一般的なものでなければならないか、おわかりになりますか？- 手動で最適化しようとすると、収益性の高いものをあらかじめ決めておくよりも、最適化するパラメータが多くなります。

あなたが書いたものは、完全に理解不足であることを示しています。

定期的に最適化されるEAを評価するために必要なWF、それが1つです。

第二に、最適化のための履歴の長さとEAのワークフローの信頼区間の 長さの両方をより正確に選択することができる。

3つ目は、WFはフィッティングがあったかを示すものです。そして、これがWFの最大のメリットでしょう。

 
Alexandr Andreev:

そして、質問があるのですが、ボルキングトレードに何を求めているのですか？

サルを自動で淘汰する。実際、このようなものがあることは、取引戦略を自動化するすべての人にとって大きなプラスであり、助けになっています。

そのためか、標準の端末機能には搭載されることはないでしょう ))

 
Nikolay Demko:

あなたの書いたものはすべて、この問題に対する完全な誤解を表しています。

WFは、一つには、定期的に過剰最適化されるEAを評価するために必要です。

第二に、最適化する履歴の長さとEAの作業ストロークの信頼区間の 長さの両方をより正確に選択することができる。

3つ目は、WFはフィッティングがあったかを示すものです。そして、それがWFの最大のメリットでしょう。

私は2014年にこの問題を解決するためにmetaquestからグリッドを購入しました。そして、エージェントとの対話不足により、多くの不要な情報をエージェントに送らなければなりませんでした。

はいそれは答えを与えるが、答えは与えるだろう - あなたが具体的なを与えない場合は、すべての悪い。

例えば、ここではストラテジーがあり、WFを介してストップレベルのみを送信していますが、これは正しくありません。できるだけ一般的なバリエーションを送るべきでしょう。

また、さらに上を目指すのであれば、もう一歩踏み込むべきでしょう。+ 何かをやりたければ、全くやらない方がいい。何かをやるなら、逆にやるべきだ。そして、この問題のポイントは、何を得るかではなく、それをどこでカウントするかということです。

 
elibrarius:

遺伝的アルゴリズムを自作する？それはもう、内製のテスターで十分なのです。メタクオーツは100時間以上かけて開発したと思います。

100時間？10年ほど前に研究室で大学の実装を書いたのですが、何も複雑なことはないんですよ。
 
Alexandr Andreev:
そして、大量のリソースが必要です。すべて、エージェントの仕事の仕方によって、すべての計算の80％が無駄になってしまうという理由からです。つまり、最初の3日間で「ハリネズミより結果が悪くなる」と理解した場合、何らかの理由で最後までテストを続けることになります。

テスト中にドローダウンが60%に達すると、ExpertRemove()が終了します。このドローダウンが3日目に発生した場合、これらのパラメータを持つ時間間隔の残りは計算されません。これは、計算を早くしているだけです。

そして、質問があるのですが、ボルキングトレードに何を求めているのですか？デモで試さずにシステムが動くかどうか知るには？

Volkingは、「最適化のバリエーション（勝利のセット）のうちの1つを選択する基準」を定義するのに役立つと思われます。

Igor Volodin 100時間？10年ほど前に大学の研究室で実験を書いていたのですが、何も複雑なことはないんです。

まあ、私は独学でプログラマをやっているんですけどね。私は反論しない - あなたはよく分かっている)

 
言い換えれば、巨大なコンピューティングリソースを持って いる人のために、すべての落とし穴とニュアンスで既製のWFを実行することを議論する準備ができて、そうプロ+バージョンを言う
 
elibrarius:

テスト中にドローダウンが60%に達すると、ExpertRemove()が終了します。このドローダウンが3日目に発生した場合、これらのパラメータを持つ時間間隔の残りは計算されません。これは、計算を早くしているだけです。

volkingは、「最適化のバリエーション（勝者セット）の中から、実行するものを選ぶ基準」を決めるのに協力すべきだと思います。
悪いバリアントは問題の半分も解決しません。例えば、良いパスが全くない場合や、例えば、2%で最高のパスがある場合（全体のスコアが87）、新しいテストの過程で、10より高いスコアはないことを知っていますが、エージェントが現在の最高のスコアを知る機会がないので、リソースは再びドレインに落ちます。
 
Alexandr Andreev:

私はこの問題を解決するために、2014年にmethaquetsからグリッドを購入しました。そして、エージェントとの対話不足により、多くの不要な情報をエージェントに送らなければなりませんでした。

はい、答えを与えるが、答えは与えるだろう - あなたが具体的なを与えていない場合は、すべての悪い。

例えば、ここではストラテジーがあり、WFを介してストップレベルのみを送信していますが、これは正しくありません。できるだけ一般的なバリエーションを送るべきでしょう。

また、さらに上を目指すのであれば、もう一歩踏み込むべきでしょう。+ 何かをやりたければ、全くやらない方がいい。何かをやるなら、逆にやるべきだ。そして、この問題のポイントは、何を得るかではなく、それをどこでカウントするかです

グリッド（クラウド）は別のものに最適化されているので、顕微鏡を使って釘を打つようなものです。正しく使うためには、GA検索をフォワーダーで何度も実行し、フォワーダーを正確に記録し、その記録から全体像を再構築する必要があるのです。

クラウドはウォームアップに時間がかかるので、一回限りの最適化を目的としていますが、グリッドが立ち上がれば、すぐにすべてを計算し、またダウンしてしまうのです。各スタートアップにはスタートアップ・レディが存在することになるが、WFにはそうしたマイクロスターがたくさんある。

MQがWFを自社で実装しない限り、使用中のリソースの仕組みを理解せずにハンパなことはない。自分でGAを書き、自分でテスターを書き（TheXpertの言うようにインジケータで簡略化できる）、その中でWFを実装する方が簡単です。

 
Igor Volodin:
100時間？10年ほど前、大学の研究室で実装を書いていたのですが、そこには複雑なものはありません。
それが、ここではプラットフォームそのものから離れるということです。ところで、大規模なプロジェクトの もう一つの問題は、MTをアップデートするときに、多くのエラーが発生することです。
12345678910111213
新しいコメント