ローリングフォワードの実施方法 - ページ 10 1...345678910111213 新しいコメント Igor Volodin 2016.04.18 23:23 #91 Alexandr Andreev: WFで仕事をする場合、それはあくまでリソースの問題であり、非常に強力なものです。数カ所（3〜6カ月でも）でフォワードの吸い込みが見られる場合は、処理を中断して問題を整理します。優れたシステムは、最適化可能なパラメータが非常に少ない（理想的には1〜2）。 しかし、何でもかんでもWFベースの自動巻き取り機を作ろうと思ったら、それは建物ではなく、煉瓦の仕事です。 Alexandr Andreev 2016.04.18 23:23 #92 Nikolay Demko: ポイントは、簡略化された信号の計算方式にあります。全てはすでに簡素化されており、重要なのは手数料を数えることを忘れないことです;)一般的には、お互いの成功を祈り合うのが正しいと思いますところで、私は約140000 +主な "戦略 "の入力で、それぞれが唯一のいくつかの50から500のパスを持って、このすべてのキーとしてWF（+トリックや他の小さなものの多くは）、しかしちょうど本当にそれをカウントしない、さらに各システム上のレポートを保存することはすでに問題になっています。もし、WFを具体的にチェックするのであれば、WFという概念そのものを肩から切り落とすことになるのです。 Alexandr Andreev 2016.04.18 23:26 #93 Igor Volodin:フォワードがいくつかのセクションで（3〜6ヶ月でも）最悪だと分かったら、プロセスを停止して問題を解決するのです。優れたシステムは、最適化可能なパラメータが非常に少ない（理想的には1〜2）。 でも、何でもかんでもWFベースの自動巻き付けにするなら、工事ではなく、レンガの仕事ですからね。 例えば、プロット上で事前に利益を上げるシステムを利用し、WFが私の利益確定レベルを 変更するのを見た場合、それはクールでしょうか？そんなことをしたら、せっかくのアイデアが台無しです。 Igor Volodin 2016.04.18 23:28 #94 Alexandr Andreev: では、以前は利益を上げていたシステムを、WFを見てテイクプロフィットレベルを 変更したら、それはクールなことなのでしょうか？そんなことをしたら、せっかくのアイデアが台無しです。WFの考え方はシンプルです。ゴミを投入してお菓子をもらう、という発想が違うんですね。 Mykola Demko 2016.04.18 23:29 #95 Alexandr Andreev:全てはすでに簡素化されており、重要なのは手数料を数えることを忘れないことです;)一般的には、お互いの成功を祈り合うのが正しいと思いますところで、私は約140000 +主な "戦略 "の入力で、それぞれが唯一の50から500のパスを持って、このすべてのキーとしてWF（+トリックや他の小さなものの多くは）、それを計算することは単に現実的ではないですが、それぞれのシステム上のレポートを保存することはすでに問題です。リソース不足は、単に破滅的なものです。もし私たちが何か特定のものでWFをチェックするなら、また私たちはWFのアイデアそのものを肩から切り離してしまうことになります。 140,000,000って...干し草の中の針を探してるようなもんだろ。具体的に絞ったほうがいい。 Aleksei Kuznetsov 2016.04.18 23:34 #96 Alexandr Andreev:全てはすでに簡素化されており、重要なのは手数料を数えることを忘れないことです;)一般的には、お互いの成功を祈り合うのが正しいと思いますところで、私は約140000 +主な "戦略 "の入力で、それぞれが唯一のいくつかの50から500のパスを持って、このすべてのキーとしてWF（+トリックや他の小さなものの多くは）、しかしちょうど本当にそれをカウントしない、さらに各システム上のレポートを保存することはすでに問題になっています。リソース不足は、単に破滅的なものであり、もし我々が何か特定のものでWFをチェックするなら、また我々はWFのアイデアそのものを肩から切り離してしまうことになります。 どこでこんなにたくさんの戦略を手に入れたのですか？一つの戦略を何ヶ月もかけて扱うこともあるでしょうが...。市場で他のEAをテストして、どのEAを購入するか選んでいるのですか？ Alexandr Andreev 2016.04.18 23:35 #97 Igor Volodin: WFの考え方はシンプルです。ゴミを投入してお菓子をもらう、という発想が違うんですね。何がゴミで何が甘いのか、それを見極める能力が機械より優れているとなぜ思えるのか--そうだとしたら、なぜコンピューターをまったく信用しないのか。もしストラテジーが1-2個のパラメーターしか持っていないなら、それはすでに決まっていることで、そのような判断には原理的に適していないというだけです。もしストラテジーが事前に定義されていない（特定の状況用に設計されていない）場合、WFは利益の出るセットを選択し、それをチェックし、すべてがOKなら成功とし、別の時間ステップでやり直す（もしストラテジーが事前に定義されているなら、論理的にはすべてのパスの70％が利益になるはずで、WFは何のために必要なのか）。 Igor Volodin 2016.04.18 23:45 #98 ウレインの言葉Nikolay Demko:あなたの書いたものはすべて、この問題に対する完全な誤解を表しています。あなたには、あなたによって発明された新しいやり方があるのです。どちらかというと、WFに関する良いフレーズです。WFテストでは、適度な「自由度」を保ちながら、取引システムを開発することができます。 Alexandr Andreev 2016.04.19 00:01 #99 Igor Volodin: ウレインの言葉でお答えします。 あなたが発明した新しい道がある議論する気もない。しかし、単一の研究（個々の価値観）のためにWFを作ることは、IMHOの行き詰まりです ;)テストの任意の方法は、それに置かれ、どちらも多くも少なく、そして大衆のために他のと実現するために、すべてのいつものように正確に与えるが。 Youri Tarshecki 2016.04.19 06:48 #100 Alexandr Andreev:議論する気もない。しかし、単一の研究（個々の価値観）のためにWFを作ることは、IMHOの行き詰まりです ;)どのようなテスト方法でも、入れたものがそのまま出て、それ以上でも以下でもなく、大衆にとっては他に実現するものがなく、すべてがいつも通りなのだが。むしろ、この立場には賛成です。私は「分割テスト」を試みました。異なるコードのバリエーションに対して、「責任ある」変数を選び出し、それだけを最適化し、時間を節約し、全体の結果に目をつぶって前向きに比較しました - しかしそれはうまくいきませんでした。良いシステムであれば、各部分は相互依存関係にあり、一つのバランスが崩れるとシステム全体が破綻するのは明らかです。 (ちなみに、変数の数が少ないと動作するシステムがないのはそのためです）。飛行機と同じで、少なくとも1つの機能が飛行条件に適応しなければ、遅かれ早かれ墜落してしまうのです。また、その機能は外見上は離着陸というシンプルなものですが、複雑な飛行機であればあるほど、より多くの要素を考慮し、信頼性を高めています）。一方、ある変数はシステムの長期的な「記憶」を、ある変数は「運用」を担っていることは明らかである。ですから、長い目で見て、最適化期間の異なるグループに分ける方法はすでに考えています。しかし、その間、すべての変数の裏付けは同じで、それは正しくないのです。しかし、ボルキングフォワードはこの問題も解決することができるのです。また、 スピードアップの ために、いろいろなものが犠牲になることも問題です。例えば、こんな感じです。1.ダニでレースする意味がない。VFにおけるテストは相対的なものが多く、最適な選択肢を選ぶために環境条件の超精密なマッチングは必要ない。つまり、良い解決策はやはり良い解決策なのです。2.変数は、1つずつ最適化することができ、全部を最適化することはできません。この場合、クラウドが行くそうすると、クラウドは独自の道を進み、エージェントがなくても多かれ少なかれ大丈夫になります。とはいえ、最適化の質は変わらないと、 私は 確認しています。これは、ボルキネス中に、ヒストリーの別々の断片が、ある変数に対して複数回 最適化されるからでしょう。そして、このポイント状況での変数の未捕捉の相互作用は、常に次のステップで顕在化する可能性があるのです。3. 途中で失敗した解決策をキャッチして次のタスクに移ることが可能である。ここには創造性の余地がある（ベンチマークとの比較、明らかなマイナスへの反応など）。 1...345678910111213 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
WFで仕事をする場合、それはあくまでリソースの問題であり、非常に強力なものです。
数カ所（3〜6カ月でも）でフォワードの吸い込みが見られる場合は、処理を中断して問題を整理します。
優れたシステムは、最適化可能なパラメータが非常に少ない（理想的には1〜2）。
しかし、何でもかんでもWFベースの自動巻き取り機を作ろうと思ったら、それは建物ではなく、煉瓦の仕事です。
ポイントは、簡略化された信号の計算方式にあります。
全てはすでに簡素化されており、重要なのは手数料を数えることを忘れないことです;)一般的には、お互いの成功を祈り合うのが正しいと思います
ところで、私は約140000 +主な "戦略 "の入力で、それぞれが唯一のいくつかの50から500のパスを持って、このすべてのキーとしてWF（+トリックや他の小さなものの多くは）、しかしちょうど本当にそれをカウントしない、さらに各システム上のレポートを保存することはすでに問題になっています。
もし、WFを具体的にチェックするのであれば、WFという概念そのものを肩から切り落とすことになるのです。
フォワードがいくつかのセクションで（3〜6ヶ月でも）最悪だと分かったら、プロセスを停止して問題を解決するのです。
優れたシステムは、最適化可能なパラメータが非常に少ない（理想的には1〜2）。
でも、何でもかんでもWFベースの自動巻き付けにするなら、工事ではなく、レンガの仕事ですからね。
では、以前は利益を上げていたシステムを、WFを見てテイクプロフィットレベルを 変更したら、それはクールなことなのでしょうか？そんなことをしたら、せっかくのアイデアが台無しです。
WFの考え方はシンプルです。ゴミを投入してお菓子をもらう、という発想が違うんですね。
全てはすでに簡素化されており、重要なのは手数料を数えることを忘れないことです;)一般的には、お互いの成功を祈り合うのが正しいと思います
ところで、私は約140000 +主な "戦略 "の入力で、それぞれが唯一の50から500のパスを持って、このすべてのキーとしてWF（+トリックや他の小さなものの多くは）、それを計算することは単に現実的ではないですが、それぞれのシステム上のレポートを保存することはすでに問題です。
リソース不足は、単に破滅的なものです。もし私たちが何か特定のものでWFをチェックするなら、また私たちはWFのアイデアそのものを肩から切り離してしまうことになります。
全てはすでに簡素化されており、重要なのは手数料を数えることを忘れないことです;)一般的には、お互いの成功を祈り合うのが正しいと思います
ところで、私は約140000 +主な "戦略 "の入力で、それぞれが唯一のいくつかの50から500のパスを持って、このすべてのキーとしてWF（+トリックや他の小さなものの多くは）、しかしちょうど本当にそれをカウントしない、さらに各システム上のレポートを保存することはすでに問題になっています。
リソース不足は、単に破滅的なものであり、もし我々が何か特定のものでWFをチェックするなら、また我々はWFのアイデアそのものを肩から切り離してしまうことになります。
WFの考え方はシンプルです。ゴミを投入してお菓子をもらう、という発想が違うんですね。
何がゴミで何が甘いのか、それを見極める能力が機械より優れているとなぜ思えるのか--そうだとしたら、なぜコンピューターをまったく信用しないのか。
もしストラテジーが1-2個のパラメーターしか持っていないなら、それはすでに決まっていることで、そのような判断には原理的に適していないというだけです。もしストラテジーが事前に定義されていない（特定の状況用に設計されていない）場合、WFは利益の出るセットを選択し、それをチェックし、すべてがOKなら成功とし、別の時間ステップでやり直す（もしストラテジーが事前に定義されているなら、論理的にはすべてのパスの70％が利益になるはずで、WFは何のために必要なのか）。
あなたの書いたものはすべて、この問題に対する完全な誤解を表しています。
あなたには、あなたによって発明された新しいやり方があるのです。
どちらかというと、WFに関する良いフレーズです。
WFテストでは、適度な「自由度」を保ちながら、取引システムを開発することができます。
ウレインの言葉でお答えします。 あなたが発明した新しい道がある
議論する気もない。しかし、単一の研究（個々の価値観）のためにWFを作ることは、IMHOの行き詰まりです ;)
テストの任意の方法は、それに置かれ、どちらも多くも少なく、そして大衆のために他のと実現するために、すべてのいつものように正確に与えるが。
議論する気もない。しかし、単一の研究（個々の価値観）のためにWFを作ることは、IMHOの行き詰まりです ;)
どのようなテスト方法でも、入れたものがそのまま出て、それ以上でも以下でもなく、大衆にとっては他に実現するものがなく、すべてがいつも通りなのだが。
むしろ、この立場には賛成です。私は「分割テスト」を試みました。異なるコードのバリエーションに対して、「責任ある」変数を選び出し、それだけを最適化し、時間を節約し、全体の結果に目をつぶって前向きに比較しました - しかしそれはうまくいきませんでした。良いシステムであれば、各部分は相互依存関係にあり、一つのバランスが崩れるとシステム全体が破綻するのは明らかです。
(ちなみに、変数の数が少ないと動作するシステムがないのはそのためです）。飛行機と同じで、少なくとも1つの機能が飛行条件に適応しなければ、遅かれ早かれ墜落してしまうのです。また、その機能は外見上は離着陸というシンプルなものですが、複雑な飛行機であればあるほど、より多くの要素を考慮し、信頼性を高めています）。
一方、ある変数はシステムの長期的な「記憶」を、ある変数は「運用」を担っていることは明らかである。ですから、長い目で見て、最適化期間の異なるグループに分ける方法はすでに考えています。しかし、その間、すべての変数の裏付けは同じで、それは正しくないのです。しかし、ボルキングフォワードはこの問題も解決することができるのです。
また、 スピードアップの ために、いろいろなものが犠牲になることも問題です。例えば、こんな感じです。
1.ダニでレースする意味がない。VFにおけるテストは相対的なものが多く、最適な選択肢を選ぶために環境条件の超精密なマッチングは必要ない。つまり、良い解決策はやはり良い解決策なのです。
2.変数は、1つずつ最適化することができ、全部を最適化することはできません。この場合、クラウドが行くそうすると、クラウドは独自の道を進み、エージェントがなくても多かれ少なかれ大丈夫になります。とはいえ、最適化の質は変わらないと、 私は 確認しています。これは、ボルキネス中に、ヒストリーの別々の断片が、ある変数に対して複数回 最適化されるからでしょう。そして、このポイント状況での変数の未捕捉の相互作用は、常に次のステップで顕在化する可能性があるのです。
3. 途中で失敗した解決策をキャッチして次のタスクに移ることが可能である。ここには創造性の余地がある（ベンチマークとの比較、明らかなマイナスへの反応など）。