ローリングフォワードの実施方法 - ページ 8 12345678910111213 新しいコメント Igor Volodin 2016.04.18 22:39 #71 Youri Tarshecki:また、このOOSでは、どのようにウイニングセットが使える ようになるのですか？ OOSは内部で、テスターにOOS期間に取引させ、好きなパラメータを入れて、すでにセットが見つかっている状態です。 Mykola Demko 2016.04.18 22:42 #72 Alexandr Andreev:4年前、彼らはボルキング・トレーディングの調査を開始しました...非常に厳しく。そして、質問があるのですが、Volkingに何を求めているのでしょうか？デモでテストする必要がないように、システムが機能するかどうかを調べるため？かっこいいけど、どうせならデモで試してほしい。プロトシステムがボルキングで動くことを期待していると、そうではなく、彼は大規模なテスト中にすべてが間違っているとよく言うのです。ボルキングに巨大なサンプルを与えているので、どうしても（方向性を決めるために）縮小できないのです。そうしないと、ボルキングの原理全体がその場で壊れてしまうからです。そして、全計算の8割が無駄になってしまうのは、エージェントとの仕事の特殊性が原因です。つまり、最初の3日間で、今持っているものより悪い結果になることがわかったら、最後までテストを続けるということです。ボルキングトレードの戦略は、どれだけ一般的なものでなければならないか、おわかりになりますか？- 手動で最適化しようとすると、収益性の高いものをあらかじめ決めておくよりも、最適化するパラメータが多くなります。あなたが書いたものは、完全に理解不足であることを示しています。 定期的に最適化されるEAを評価するために必要なWF、それが1つです。第二に、最適化のための履歴の長さとEAのワークフローの信頼区間の 長さの両方をより正確に選択することができる。3つ目は、WFはフィッティングがあったかを示すものです。そして、これがWFの最大のメリットでしょう。 TheXpert 2016.04.18 22:49 #73 Alexandr Andreev:そして、質問があるのですが、ボルキングトレードに何を求めているのですか？サルを自動で淘汰する。実際、このようなものがあることは、取引戦略を自動化するすべての人にとって大きなプラスであり、助けになっています。そのためか、標準の端末機能には搭載されることはないでしょう )) Alexandr Andreev 2016.04.18 22:49 #74 Nikolay Demko:あなたの書いたものはすべて、この問題に対する完全な誤解を表しています。 WFは、一つには、定期的に過剰最適化されるEAを評価するために必要です。第二に、最適化する履歴の長さとEAの作業ストロークの信頼区間の 長さの両方をより正確に選択することができる。3つ目は、WFはフィッティングがあったかを示すものです。そして、それがWFの最大のメリットでしょう。私は2014年にこの問題を解決するためにmetaquestからグリッドを購入しました。そして、エージェントとの対話不足により、多くの不要な情報をエージェントに送らなければなりませんでした。はいそれは答えを与えるが、答えは与えるだろう - あなたが具体的なを与えない場合は、すべての悪い。 例えば、ここではストラテジーがあり、WFを介してストップレベルのみを送信していますが、これは正しくありません。できるだけ一般的なバリエーションを送るべきでしょう。 また、さらに上を目指すのであれば、もう一歩踏み込むべきでしょう。+ 何かをやりたければ、全くやらない方がいい。何かをやるなら、逆にやるべきだ。そして、この問題のポイントは、何を得るかではなく、それをどこでカウントするかということです。 Igor Volodin 2016.04.18 22:50 #75 elibrarius:遺伝的アルゴリズムを自作する？それはもう、内製のテスターで十分なのです。メタクオーツは100時間以上かけて開発したと思います。 100時間？10年ほど前に研究室で大学の実装を書いたのですが、何も複雑なことはないんですよ。 Forester 2016.04.18 22:50 #76 Alexandr Andreev: そして、大量のリソースが必要です。すべて、エージェントの仕事の仕方によって、すべての計算の80％が無駄になってしまうという理由からです。つまり、最初の3日間で「ハリネズミより結果が悪くなる」と理解した場合、何らかの理由で最後までテストを続けることになります。 テスト中にドローダウンが60%に達すると、ExpertRemove()が終了します。このドローダウンが3日目に発生した場合、これらのパラメータを持つ時間間隔の残りは計算されません。これは、計算を早くしているだけです。そして、質問があるのですが、ボルキングトレードに何を求めているのですか？デモで試さずにシステムが動くかどうか知るには？Volkingは、「最適化のバリエーション（勝利のセット）のうちの1つを選択する基準」を定義するのに役立つと思われます。Igor Volodin 100時間？10年ほど前に大学の研究室で実験を書いていたのですが、何も複雑なことはないんです。まあ、私は独学でプログラマをやっているんですけどね。私は反論しない - あなたはよく分かっている) Alexandr Andreev 2016.04.18 22:51 #77 言い換えれば、巨大なコンピューティングリソースを持って いる人のために、すべての落とし穴とニュアンスで既製のWFを実行することを議論する準備ができて、そうプロ+バージョンを言う Alexandr Andreev 2016.04.18 22:58 #78 elibrarius:テスト中にドローダウンが60%に達すると、ExpertRemove()が終了します。このドローダウンが3日目に発生した場合、これらのパラメータを持つ時間間隔の残りは計算されません。これは、計算を早くしているだけです。 volkingは、「最適化のバリエーション（勝者セット）の中から、実行するものを選ぶ基準」を決めるのに協力すべきだと思います。 悪いバリアントは問題の半分も解決しません。例えば、良いパスが全くない場合や、例えば、2%で最高のパスがある場合（全体のスコアが87）、新しいテストの過程で、10より高いスコアはないことを知っていますが、エージェントが現在の最高のスコアを知る機会がないので、リソースは再びドレインに落ちます。 Mykola Demko 2016.04.18 22:59 #79 Alexandr Andreev:私はこの問題を解決するために、2014年にmethaquetsからグリッドを購入しました。そして、エージェントとの対話不足により、多くの不要な情報をエージェントに送らなければなりませんでした。はい、答えを与えるが、答えは与えるだろう - あなたが具体的なを与えていない場合は、すべての悪い。 例えば、ここではストラテジーがあり、WFを介してストップレベルのみを送信していますが、これは正しくありません。できるだけ一般的なバリエーションを送るべきでしょう。 また、さらに上を目指すのであれば、もう一歩踏み込むべきでしょう。+ 何かをやりたければ、全くやらない方がいい。何かをやるなら、逆にやるべきだ。そして、この問題のポイントは、何を得るかではなく、それをどこでカウントするかですグリッド（クラウド）は別のものに最適化されているので、顕微鏡を使って釘を打つようなものです。正しく使うためには、GA検索をフォワーダーで何度も実行し、フォワーダーを正確に記録し、その記録から全体像を再構築する必要があるのです。クラウドはウォームアップに時間がかかるので、一回限りの最適化を目的としていますが、グリッドが立ち上がれば、すぐにすべてを計算し、またダウンしてしまうのです。各スタートアップにはスタートアップ・レディが存在することになるが、WFにはそうしたマイクロスターがたくさんある。MQがWFを自社で実装しない限り、使用中のリソースの仕組みを理解せずにハンパなことはない。自分でGAを書き、自分でテスターを書き（TheXpertの言うようにインジケータで簡略化できる）、その中でWFを実装する方が簡単です。 Alexandr Andreev 2016.04.18 22:59 #80 Igor Volodin: 100時間？10年ほど前、大学の研究室で実装を書いていたのですが、そこには複雑なものはありません。 それが、ここではプラットフォームそのものから離れるということです。ところで、大規模なプロジェクトの もう一つの問題は、MTをアップデートするときに、多くのエラーが発生することです。 12345678910111213 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
4年前、彼らはボルキング・トレーディングの調査を開始しました...非常に厳しく。
そして、質問があるのですが、Volkingに何を求めているのでしょうか？デモでテストする必要がないように、システムが機能するかどうかを調べるため？
かっこいいけど、どうせならデモで試してほしい。プロトシステムがボルキングで動くことを期待していると、そうではなく、彼は大規模なテスト中にすべてが間違っているとよく言うのです。
ボルキングに巨大なサンプルを与えているので、どうしても（方向性を決めるために）縮小できないのです。そうしないと、ボルキングの原理全体がその場で壊れてしまうからです。そして、全計算の8割が無駄になってしまうのは、エージェントとの仕事の特殊性が原因です。つまり、最初の3日間で、今持っているものより悪い結果になることがわかったら、最後までテストを続けるということです。
ボルキングトレードの戦略は、どれだけ一般的なものでなければならないか、おわかりになりますか？- 手動で最適化しようとすると、収益性の高いものをあらかじめ決めておくよりも、最適化するパラメータが多くなります。
あなたが書いたものは、完全に理解不足であることを示しています。
定期的に最適化されるEAを評価するために必要なWF、それが1つです。
第二に、最適化のための履歴の長さとEAのワークフローの信頼区間の 長さの両方をより正確に選択することができる。
3つ目は、WFはフィッティングがあったかを示すものです。そして、これがWFの最大のメリットでしょう。
そして、質問があるのですが、ボルキングトレードに何を求めているのですか？
サルを自動で淘汰する。実際、このようなものがあることは、取引戦略を自動化するすべての人にとって大きなプラスであり、助けになっています。
そのためか、標準の端末機能には搭載されることはないでしょう ))
あなたの書いたものはすべて、この問題に対する完全な誤解を表しています。
WFは、一つには、定期的に過剰最適化されるEAを評価するために必要です。
第二に、最適化する履歴の長さとEAの作業ストロークの信頼区間の 長さの両方をより正確に選択することができる。
3つ目は、WFはフィッティングがあったかを示すものです。そして、それがWFの最大のメリットでしょう。
私は2014年にこの問題を解決するためにmetaquestからグリッドを購入しました。そして、エージェントとの対話不足により、多くの不要な情報をエージェントに送らなければなりませんでした。
はいそれは答えを与えるが、答えは与えるだろう - あなたが具体的なを与えない場合は、すべての悪い。
例えば、ここではストラテジーがあり、WFを介してストップレベルのみを送信していますが、これは正しくありません。できるだけ一般的なバリエーションを送るべきでしょう。
また、さらに上を目指すのであれば、もう一歩踏み込むべきでしょう。+ 何かをやりたければ、全くやらない方がいい。何かをやるなら、逆にやるべきだ。そして、この問題のポイントは、何を得るかではなく、それをどこでカウントするかということです。
遺伝的アルゴリズムを自作する？それはもう、内製のテスターで十分なのです。メタクオーツは100時間以上かけて開発したと思います。
そして、大量のリソースが必要です。すべて、エージェントの仕事の仕方によって、すべての計算の80％が無駄になってしまうという理由からです。つまり、最初の3日間で「ハリネズミより結果が悪くなる」と理解した場合、何らかの理由で最後までテストを続けることになります。
テスト中にドローダウンが60%に達すると、ExpertRemove()が終了します。このドローダウンが3日目に発生した場合、これらのパラメータを持つ時間間隔の残りは計算されません。これは、計算を早くしているだけです。
Volkingは、「最適化のバリエーション（勝利のセット）のうちの1つを選択する基準」を定義するのに役立つと思われます。
Igor Volodin 100時間？10年ほど前に大学の研究室で実験を書いていたのですが、何も複雑なことはないんです。
まあ、私は独学でプログラマをやっているんですけどね。私は反論しない - あなたはよく分かっている)
テスト中にドローダウンが60%に達すると、ExpertRemove()が終了します。このドローダウンが3日目に発生した場合、これらのパラメータを持つ時間間隔の残りは計算されません。これは、計算を早くしているだけです。
volkingは、「最適化のバリエーション（勝者セット）の中から、実行するものを選ぶ基準」を決めるのに協力すべきだと思います。私はこの問題を解決するために、2014年にmethaquetsからグリッドを購入しました。そして、エージェントとの対話不足により、多くの不要な情報をエージェントに送らなければなりませんでした。
はい、答えを与えるが、答えは与えるだろう - あなたが具体的なを与えていない場合は、すべての悪い。
例えば、ここではストラテジーがあり、WFを介してストップレベルのみを送信していますが、これは正しくありません。できるだけ一般的なバリエーションを送るべきでしょう。
また、さらに上を目指すのであれば、もう一歩踏み込むべきでしょう。+ 何かをやりたければ、全くやらない方がいい。何かをやるなら、逆にやるべきだ。そして、この問題のポイントは、何を得るかではなく、それをどこでカウントするかです
グリッド（クラウド）は別のものに最適化されているので、顕微鏡を使って釘を打つようなものです。正しく使うためには、GA検索をフォワーダーで何度も実行し、フォワーダーを正確に記録し、その記録から全体像を再構築する必要があるのです。
クラウドはウォームアップに時間がかかるので、一回限りの最適化を目的としていますが、グリッドが立ち上がれば、すぐにすべてを計算し、またダウンしてしまうのです。各スタートアップにはスタートアップ・レディが存在することになるが、WFにはそうしたマイクロスターがたくさんある。
MQがWFを自社で実装しない限り、使用中のリソースの仕組みを理解せずにハンパなことはない。自分でGAを書き、自分でテスターを書き（TheXpertの言うようにインジケータで簡略化できる）、その中でWFを実装する方が簡単です。
100時間？10年ほど前、大学の研究室で実装を書いていたのですが、そこには複雑なものはありません。