リーグ・オブ・トレーディング・システムズこれからもよろしくお願いします。 - ページ 66 1...596061626364656667686970717273...360 新しいコメント Georgiy Merts 2019.01.03 12:53 #651 Maxim Dmitrievsky:...はオプティマイザーで調整します。この場合、量はどのような組み合わせでも問題なく、ゴミを入れればゴミが出ます。これは些細な論理から導かれるもので、超能力者である必要さえないのです。 最適化とは、とにかくフィッティングが重要なのです。しかし、私の意見では、リーグでは - それはほとんどのKodoBaseの専門家のそれよりもはるかに少ないです。 例えば、フリップド・チャンネル・システムでは、トリム・パラメータはチャンネル周期1つだけです。 さらに、私の最適化は「マルチレイヤー」です。つまり、多くのパラメータがある場合(例えば、Breakevenも設定する場合)、まずBreakevenなしですべてが最適化される、つまりBreakevenなしでもシステムが機能する、ということです。そして、その後に初めて損益分岐点パラメータを選択し、さらにシステムを改善するのです。 これが「ゴミ」なら......何が「非ゴミ」なのか、私にはわからない。 Andrey Khatimlianskii 2019.01.03 12:55 #652 Georgiy Merts:段差がないので、見えない!?今のところ、何をやってもダメなんです。では、シグナルを開いて何かを見せても、何もないのでは意味がないのでは? 「テストはスクリプトを使って自動的に行われ、見つかったパラメータは直ちにリーグで「採点」され、さらに、すべてのテストデータは削除されるからです。過剰最適化の瞬間に - 私はテストレポートを "傍受 "することができます - 過剰最適化を必要としたそれらのマジシャンの2個 - 私は投稿しています。それ以前のものはすべてなくなりました。ところで、今日、多くのシステムが停止しました。明日、スクリプトはそれらのシステムの再最適化を開始し、私はそれらのテスターレポートを投稿することができます。それは私の質問の答えになっていない。 テスターで動作させるシステムを選択するアルゴリズムが欲しい。そして、それをテストすること。デモは全く必要ない、時間の無駄。 Maxim Dmitrievsky 2019.01.03 13:04 #653 Georgiy Merts:最適化とは、とにかくフィッティングが重要です。しかし、私の意見では、リーグでは - それは、ほとんどのKodoBaseの専門家に比べてはるかに少ないです。 例えば、フリップド・チャンネル・システムでは、トリム・パラメータはチャンネル周期1つだけです。 さらに、私の最適化は「マルチレイヤー」です。つまり、多くのパラメータがある場合(例えば、Breakevenも設定する場合)、まずBreakevenなしですべてが最適化される、つまりBreakevenなしでもシステムが機能する、ということです。そして、その後に初めて、さらにシステムを改善するブレークイーブン設定を選択するのです。 ゴミ」なら「ゴミでない」ものをと言うのは難しいですね。最適化とは、基本的なパターンはあるが、それをよりよく機能させるためにTSのパラメータを改善する必要がある場合である。また、最適化した後に初めてTS自体が動き出し、それ以前は動かなかったとなると、それは悪い最適化だと思います。 大雑把に言うと、チューニングしなくても動くならゴミにはならないが、オプションでチューニングすることはできる。そして、そのようなシステムはもともと非常に少ないので、残りのゴミを全部運んで発火するまで待つ必要があるのか、というのが合理的な問題です。 Реter Konow 2019.01.03 13:12 #654 Georgiy Merts:... ゴミ」なら......何が「ゴミでない」のか、私にはわからない。ジョージ、論理的に考えよう。 500のトレーディングシステムを持っていますね。セットの中からランダムに5つのシステムが一定の利益を与え、残りは損失を与えます。実際にシステムを選択する基準は、ストップロスである。他にはありません。そんな取引は破滅につながる。 2.システム改善のツールとしての最適化は、両足が不自由である。システムはセンスによってのみ改善される。そして、あなたはそれを無視している。プロセスを理解することで、初めて 意味が生まれる。そして、理解することで見えてくるものがあります。 極度の赤字 市場パラメータがあるため、適切なイメージを描くことができない。したがって、最適化は実生活にシステムを適用した場合の結果に影響を及ぼさない。なぜなら、REALでは、オプティマイザーに入力するよりも、 計り知れないほど多くの パラメータが考慮されるからです。 Реter Konow 2019.01.03 14:12 #655 建設的に考えてみる。技術的には難しいが。 最初は「戦略を考えなさい」とアドバイスしたかったのですが、リーグの実験の本質はその逆だと気づきました。 名付けて。 何も考えずにシステムを構築する。最適化する、実行する、最適化する。選択する。実験の主な目的 市場ダイナミクスの各時期にシステムを選択するアルゴリズムを見つける。 その際、条件として「システムは何でもいい」ということがあります。本質を難しく考える必要はないのです。主な判断基準 - テスターでの利益。 この実験は確かに面白い。 しかし、その結果はジョージの願望とは一致しない。彼は、ランダムダイナミクスにおけるランダムシステムの選択アルゴリズムを見つけたいのだが、そのアルゴリズムが見つからない...。 そのアルゴリズムが聖杯 なのだから...。 実際の結果は、システムそのもの、そしてその適用方法に意味がなければならないことを証明している。 私は、ジョージが、現在のマーケットのダイナミクスに適応できるような、意味のある単一のロボットを作ることを提案します。しかし、最適化でもなく、MOでもなく、意味のある評価によって適応 する。(課題はAIを作ることに近い)。 Georgiy Merts 2019.01.03 14:15 #656 Andrey Khatimlianskii:これでは答えにならない。 テスターで動作させるためには、システム選択アルゴリズムが必要です。そして、それをテストすること。デモは全く必要ない、時間の無駄。しています。でも、石花は出てこない...。 ここからは明確で、リーグはテスターの中で(またはスクリプトとテスターの助けを借りて)右の最適なTSを選択することができます。しかし、まず第一に、テスターに選択アルゴリズムを詰め込む前に、それを発明する必要があります !つまり、少なくとも何かを「獲る」ためには。その中から最適なものを選んで、このアルゴリズムで選んだシステムが安定的に動くかどうかをテスターで確認することができるのです。それがないんです。 リーグ・フォー・シェアード・プロジェクトを準備する際には、まさにこの選択アルゴリズムで再び実験を開始するつもりです。 また、「デモは必要ない」ということについてですが、私はそうは思いません。システムの安定性を確認するためにも、デモは必要なのです。テスターで動作し、今後も動作することを確認するため。 Georgiy Merts 2019.01.03 14:24 #657 Maxim Dmitrievsky:最適化とは、すでに基本的なパターンがあるが、それをよりよく機能させるためにTSのパラメータを調整する必要がある場合である。また、最適化した後に初めてTS自体が動き出し、それ以前は動かなかったとしたら、これは悪い最適化です。 大雑把に言うと、チューニングしなくても動くならゴミにはならないが、オプションでチューニングすることはできる。そして、そのようなシステムはもともと非常に少ないので、残りのゴミを全部運んで発火するまで待つ必要があるのか、というのが合理的な問題です。まあ、最初の発言には完全に同意します。それが私の仕事です。 議論になるのは、ゴミを持ち運ぶ必要があるかどうかということです。大雑把に言えば、中堅、いや下堅が必要なのか。 そう、知る由もないのだが。使用と改良のために、貿易の品質が80%未満でない高次部門のTCのみが考慮され、すべてが悪化していることは明らかである - それはより多くの「バラスト」です。 ただ、私の時間を奪うことはなく、CPUの時間だけです。毎朝、最適化が必要なシステムのリストを作成するスクリプトを実行し、最適化を行うだけです。後はEX-moduleを再コンパイルしてUPUで 更新するだけです。上位部門だけであろうと、3つ全部であろうと、私の体への負担は全く同じです。だから、今のところ、672のTCはすべてデモで動作します。 もし、サポートの複雑さ - なら、この問題は問題であり、もちろん、私は「ゴミTC」に悩まされることはないでしょう。 削除済み 2019.01.03 14:28 #658 Georgiy Merts:えー...リーグが既知のパターンしか使っていないのに、どうして「本当のパターンを利用していない」ことになるのでしょうか? 過去のお気に入りはChnTrendSP - 固定ストップでチャンネルブレイク - パターンではないのでしょうか。 バランスによって現在のお気に入り - EMAFlatSP - 価格と固定ストップとEMAの交差によって決定されるカウンタートレンドへの参入、 - それはパターンではありませんか? あなたは「本当のパターン」をどう思いますか? グォルグォルグォルグォルグォルグォルグォルグォルグォルグォルグォルグォルグォルグォルグォルグォルグォルグォルグォルグォルグォルグォルグォルグォルグォルグォルグォルグォル Georgiy Merts 2019.01.03 14:32 #659 Реter Konow:ジョージ、こんにちは。あなたは私のアイデアをたくさん批判していますが、あなたのスレッドを読むと、あなたのアイデアも同じように批判されていることがわかります。どうやら、それがこのフォーラムの伝統のようです。リーグの本質について、私の意見を述べさせてください。残念ながら、このような形での連盟の考え方は、意図せずしてトレーディングの信用を失墜させることになる。あなたのやり方は、取引の本質を奪っている。なぜ?なぜなら質」ではなく、「量」を選んだのですね。あなたは質より量を選んだのです。品質、あなたの練習で、最適化によって達成されるが、トレーディングシステムのアイデアはありません!。(トレードの考え方は、無駄な「罠」のパターンの数でマーケットを打ち負かすことである)。どんなシステムでも、最適化によってストーリーに合うように調整する。しかし、それは意味あるものでも、安定したものでもありません。つまり、あなた自身がゴミを作り、最適化によってその(可能な)価値を錯覚し、その都度ゴミであることを納得して捨てているのです。 トレーディングの信用を知らず知らずのうちに失墜させ、トレーディングシステムを作ることの無意味さを皆に思い知らせることになるのです。 無意識にやっていることだと思いますが、潜在意識ではこうなっているんです。 1.私はそうは思いません。リーグのTSはどれもかなり有名で、広く使われている技術です。記号によって、どちらか一方にしか使えないものがあります。ここでは、むしろマキシムの「ハイディビジョンだけが必要で、他はゴミ」という意見に賛成です。そういうことです。 ハイディビジョンでは、シンボルの挙動に合わせたシステムが機能します。そして、そうでないものは......中下級編に進みます。 ただ、同じシステムがハイディビジョンでしばらくうまく機能したかと思うと、突然機能しなくなることが何度もありました。私がすでに述べた明るい例、GBPUSDのチャンネルの崩壊 は、半年間ずっとシステムが非常によく機能していました。そして......バーンで、何かが変わったのか、今はランキング上位にすら入れません。ここで、中堅・下位の部門は、まさに「かつての人気者」を見るために面白いのです。 2.品質は最適化では全く達成できない。この点についても、マキシムに同意します。システムは、最適化しなくても少なくとも一定の結果を示すはずで、最適化はそれを向上させるだけなのです。まさにその「パターン・トラップ」によって、クオリティが実現されているのです。各シンボルについて、すべてのバリアントを実行します。どれが効果的か確認するために。そして、それを使い続け、改善し、さらに良いものにしていかなければならないのです。 3.大丈夫です。しかし、シンボルの動作にシステムが従わなければ、いくら最適化しても従わない。ここで3回目のマキシムの言葉に触れておくと、掲載されたレポートの1回目はくだらないものだった。つまり、ベストバリエーションシステムでも、かなりいい加減なトレードになってしまうのです。このようなシステムの本質は、どの手法が有効でないかを確認することにある。 Georgiy Merts 2019.01.03 14:34 #660 Реter Konow:一時的に安定した "アンダーシステム "を切り替えるためのアルゴリズムを探しているのですね。 仮にそのアルゴリズムが見つかったとしたら、それはすぐに聖杯と なる。その時点で、支店を閉鎖するのです。 結局、パラメータの塊のような複雑な1台のロボットが出来上がって しまうことに変わりはないのです。やはり、時間的に安定した「アンダーシステム」を1つにまとめる必要がありそうです。 まだそこまで到達していないだけでしょう。 でも、論理的に考えると、それこそが狙いなんですよね。)なぜ「大量のパラメータを持つ」のか? なるべくパラメータを取っ払うことを目標にしているんです。 そして、システム間の切り替えアルゴリズムも、可能であればパラメータレスであることが望ましい。 1...596061626364656667686970717273...360 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
...はオプティマイザーで調整します。この場合、量はどのような組み合わせでも問題なく、ゴミを入れればゴミが出ます。これは些細な論理から導かれるもので、超能力者である必要さえないのです。
最適化とは、とにかくフィッティングが重要なのです。しかし、私の意見では、リーグでは - それはほとんどのKodoBaseの専門家のそれよりもはるかに少ないです。
例えば、フリップド・チャンネル・システムでは、トリム・パラメータはチャンネル周期1つだけです。
さらに、私の最適化は「マルチレイヤー」です。つまり、多くのパラメータがある場合(例えば、Breakevenも設定する場合)、まずBreakevenなしですべてが最適化される、つまりBreakevenなしでもシステムが機能する、ということです。そして、その後に初めて損益分岐点パラメータを選択し、さらにシステムを改善するのです。
これが「ゴミ」なら......何が「非ゴミ」なのか、私にはわからない。
段差がないので、見えない!?今のところ、何をやってもダメなんです。では、シグナルを開いて何かを見せても、何もないのでは意味がないのでは?
「テストはスクリプトを使って自動的に行われ、見つかったパラメータは直ちにリーグで「採点」され、さらに、すべてのテストデータは削除されるからです。過剰最適化の瞬間に - 私はテストレポートを "傍受 "することができます - 過剰最適化を必要としたそれらのマジシャンの2個 - 私は投稿しています。それ以前のものはすべてなくなりました。ところで、今日、多くのシステムが停止しました。明日、スクリプトはそれらのシステムの再最適化を開始し、私はそれらのテスターレポートを投稿することができます。
それは私の質問の答えになっていない。
テスターで動作させるシステムを選択するアルゴリズムが欲しい。そして、それをテストすること。デモは全く必要ない、時間の無駄。
最適化とは、とにかくフィッティングが重要です。しかし、私の意見では、リーグでは - それは、ほとんどのKodoBaseの専門家に比べてはるかに少ないです。
例えば、フリップド・チャンネル・システムでは、トリム・パラメータはチャンネル周期1つだけです。
さらに、私の最適化は「マルチレイヤー」です。つまり、多くのパラメータがある場合(例えば、Breakevenも設定する場合)、まずBreakevenなしですべてが最適化される、つまりBreakevenなしでもシステムが機能する、ということです。そして、その後に初めて、さらにシステムを改善するブレークイーブン設定を選択するのです。
ゴミ」なら「ゴミでない」ものをと言うのは難しいですね。
最適化とは、基本的なパターンはあるが、それをよりよく機能させるためにTSのパラメータを改善する必要がある場合である。また、最適化した後に初めてTS自体が動き出し、それ以前は動かなかったとなると、それは悪い最適化だと思います。
大雑把に言うと、チューニングしなくても動くならゴミにはならないが、オプションでチューニングすることはできる。そして、そのようなシステムはもともと非常に少ないので、残りのゴミを全部運んで発火するまで待つ必要があるのか、というのが合理的な問題です。
...
ゴミ」なら......何が「ゴミでない」のか、私にはわからない。
ジョージ、論理的に考えよう。
建設的に考えてみる。技術的には難しいが。
最初は「戦略を考えなさい」とアドバイスしたかったのですが、リーグの実験の本質はその逆だと気づきました。
名付けて。
実験の主な目的 市場ダイナミクスの各時期にシステムを選択するアルゴリズムを見つける。
その際、条件として「システムは何でもいい」ということがあります。本質を難しく考える必要はないのです。主な判断基準 - テスターでの利益。
この実験は確かに面白い。 しかし、その結果はジョージの願望とは一致しない。彼は、ランダムダイナミクスにおけるランダムシステムの選択アルゴリズムを見つけたいのだが、そのアルゴリズムが見つからない...。
そのアルゴリズムが聖杯 なのだから...。
実際の結果は、システムそのもの、そしてその適用方法に意味がなければならないことを証明している。
私は、ジョージが、現在のマーケットのダイナミクスに適応できるような、意味のある単一のロボットを作ることを提案します。しかし、最適化でもなく、MOでもなく、意味のある評価によって適応 する。(課題はAIを作ることに近い)。
これでは答えにならない。
テスターで動作させるためには、システム選択アルゴリズムが必要です。そして、それをテストすること。デモは全く必要ない、時間の無駄。
しています。でも、石花は出てこない...。
ここからは明確で、リーグはテスターの中で(またはスクリプトとテスターの助けを借りて)右の最適なTSを選択することができます。しかし、まず第一に、テスターに選択アルゴリズムを詰め込む前に、それを発明する必要があります !つまり、少なくとも何かを「獲る」ためには。その中から最適なものを選んで、このアルゴリズムで選んだシステムが安定的に動くかどうかをテスターで確認することができるのです。それがないんです。
リーグ・フォー・シェアード・プロジェクトを準備する際には、まさにこの選択アルゴリズムで再び実験を開始するつもりです。
また、「デモは必要ない」ということについてですが、私はそうは思いません。システムの安定性を確認するためにも、デモは必要なのです。テスターで動作し、今後も動作することを確認するため。
最適化とは、すでに基本的なパターンがあるが、それをよりよく機能させるためにTSのパラメータを調整する必要がある場合である。また、最適化した後に初めてTS自体が動き出し、それ以前は動かなかったとしたら、これは悪い最適化です。
大雑把に言うと、チューニングしなくても動くならゴミにはならないが、オプションでチューニングすることはできる。そして、そのようなシステムはもともと非常に少ないので、残りのゴミを全部運んで発火するまで待つ必要があるのか、というのが合理的な問題です。
まあ、最初の発言には完全に同意します。それが私の仕事です。
議論になるのは、ゴミを持ち運ぶ必要があるかどうかということです。大雑把に言えば、中堅、いや下堅が必要なのか。 そう、知る由もないのだが。使用と改良のために、貿易の品質が80%未満でない高次部門のTCのみが考慮され、すべてが悪化していることは明らかである - それはより多くの「バラスト」です。
ただ、私の時間を奪うことはなく、CPUの時間だけです。毎朝、最適化が必要なシステムのリストを作成するスクリプトを実行し、最適化を行うだけです。後はEX-moduleを再コンパイルしてUPUで 更新するだけです。上位部門だけであろうと、3つ全部であろうと、私の体への負担は全く同じです。だから、今のところ、672のTCはすべてデモで動作します。 もし、サポートの複雑さ - なら、この問題は問題であり、もちろん、私は「ゴミTC」に悩まされることはないでしょう。
えー...リーグが既知のパターンしか使っていないのに、どうして「本当のパターンを利用していない」ことになるのでしょうか?
過去のお気に入りはChnTrendSP - 固定ストップでチャンネルブレイク - パターンではないのでしょうか。
バランスによって現在のお気に入り - EMAFlatSP - 価格と固定ストップとEMAの交差によって決定されるカウンタートレンドへの参入、 - それはパターンではありませんか?
あなたは「本当のパターン」をどう思いますか?
ジョージ、こんにちは。あなたは私のアイデアをたくさん批判していますが、あなたのスレッドを読むと、あなたのアイデアも同じように批判されていることがわかります。どうやら、それがこのフォーラムの伝統のようです。
リーグの本質について、私の意見を述べさせてください。
残念ながら、このような形での連盟の考え方は、意図せずしてトレーディングの信用を失墜させることになる。あなたのやり方は、取引の本質を奪っている。なぜ?
なぜなら
つまり、あなた自身がゴミを作り、最適化によってその(可能な)価値を錯覚し、その都度ゴミであることを納得して捨てているのです。
トレーディングの信用を知らず知らずのうちに失墜させ、トレーディングシステムを作ることの無意味さを皆に思い知らせることになるのです。
無意識にやっていることだと思いますが、潜在意識ではこうなっているんです。
1.私はそうは思いません。リーグのTSはどれもかなり有名で、広く使われている技術です。記号によって、どちらか一方にしか使えないものがあります。ここでは、むしろマキシムの「ハイディビジョンだけが必要で、他はゴミ」という意見に賛成です。そういうことです。 ハイディビジョンでは、シンボルの挙動に合わせたシステムが機能します。そして、そうでないものは......中下級編に進みます。
ただ、同じシステムがハイディビジョンでしばらくうまく機能したかと思うと、突然機能しなくなることが何度もありました。私がすでに述べた明るい例、GBPUSDのチャンネルの崩壊 は、半年間ずっとシステムが非常によく機能していました。そして......バーンで、何かが変わったのか、今はランキング上位にすら入れません。ここで、中堅・下位の部門は、まさに「かつての人気者」を見るために面白いのです。
2.品質は最適化では全く達成できない。この点についても、マキシムに同意します。システムは、最適化しなくても少なくとも一定の結果を示すはずで、最適化はそれを向上させるだけなのです。まさにその「パターン・トラップ」によって、クオリティが実現されているのです。各シンボルについて、すべてのバリアントを実行します。どれが効果的か確認するために。そして、それを使い続け、改善し、さらに良いものにしていかなければならないのです。
3.大丈夫です。しかし、シンボルの動作にシステムが従わなければ、いくら最適化しても従わない。ここで3回目のマキシムの言葉に触れておくと、掲載されたレポートの1回目はくだらないものだった。つまり、ベストバリエーションシステムでも、かなりいい加減なトレードになってしまうのです。このようなシステムの本質は、どの手法が有効でないかを確認することにある。
一時的に安定した "アンダーシステム "を切り替えるためのアルゴリズムを探しているのですね。
仮にそのアルゴリズムが見つかったとしたら、それはすぐに聖杯と なる。その時点で、支店を閉鎖するのです。
結局、パラメータの塊のような複雑な1台のロボットが出来上がって しまうことに変わりはないのです。やはり、時間的に安定した「アンダーシステム」を1つにまとめる必要がありそうです。
まだそこまで到達していないだけでしょう。
でも、論理的に考えると、それこそが狙いなんですよね。)
なぜ「大量のパラメータを持つ」のか?
なるべくパラメータを取っ払うことを目標にしているんです。
そして、システム間の切り替えアルゴリズムも、可能であればパラメータレスであることが望ましい。