リーグ・オブ・トレーディング・システムズこれからもよろしくお願いします。 - ページ 70

[Georgiy Merts]

Vladimir Baskakov:
私は、やはり100％自動化に賛成です。最適化しすぎるのが理解できない、手動？それじゃあダメだ。

半分です。特別なスクリプトで最適化が必要なシステムを選択し、インストールファイルを準備します。次に、別のスクリプトで全システムをオプティマイザーで実行します。3つ目のスクリプトは、最適化 結果をもとに最適なパスを選択し、システム用のチューニング手順を記したファイルを作成するものである。これらのテキストをTCのクラスに転送し（まだフルオートマトンを信用していないので、ここでは私が完全にコントロールする）、実行モジュールを再コンパイルし、UPUで更新し、翌日にはこのプロセスを繰り返すのです。

[削除済み]

Georgiy Merts:

半分です。特別なスクリプトにより、過剰最適化が必要なシステムを選択し、インストールファイルを準備します。次に、別のスクリプトで全システムをオプティマイザーで実行します。3つ目のスクリプトは、最適化 結果をもとに最適なパスを選択し、システムチューニングの手順をテキスト化したファイルを作成するものである。これらのテキストをTCのクラスに転送し（まだフルオートマトンを信用していないので、ここでは私が完全にコントロールする）、実行モジュールを再コンパイルし、UPUで更新し、翌日にはこのプロセスを繰り返すのです。

グローバルに聞こえる、まあかっこいい

[Roman Shiredchenko]

Andrey Khatimlianskii:

1.最適なシステムを自動的に選択し、取引することを意味します。テスターでも、です。

2.すべてのXXXシステムで仮想的に取引し、指標を評価し、本番に持ち込むものを選び、その取引は本番で行われます。

仮想環境に煩わされたくなければ（既成のfxsaberもありますが）、統計用0.01ロット、結果用1.00で取引すればよいのです。

しかも、座ってデモを見る必要はなく、すべてが一度に明らかになるのです。

1.このTSのためにここにいる-かもしれない。常に "最高のシステムとその上の取引の自動選択 "ではありませんが。 TSのパラメータのいくつかの平均値があり、その選択は、おそらく、プログラムすることは容易ではない、我々はパラメータの各 "ミドル "値と歴史上のパラメータのすべての選択された "ミドル "値で見なければならず、このアプローチでちょうど "最高のシステムの自動選択とその上にトレード "はありません、私はより信頼できると思いますが、その。

2.絶対に正しい。まったくもって同感です。私自身、そんなアプローチに悩まされそうです。TSはまだそのようなテストができる状態ではないのですが...。

2016年から...:-) 全てが書かれているわけではありませんが、特に複雑なことはありません。時間がない、日々の糧に不安があるなど、この方向で自由奔放にクリエイティブな活動をすることはできません。

[Roman Shiredchenko]

Georgiy Merts:

ああ、アンドレイ...。なぜ、私の痛いところを突くんだ...

ベストなシステムを選ぶことが、最後の未解決問題です。 純粋にベストを取る」-結局、無理なのです。最高のパフォーマンスを発揮していたシステムが、突然動かなくなるのですから。とはいえ、テストはされているようで、デモではすでに十数件の成約が示されているのですが...。し かし、持続可能性というのは、結局のところ、ないんですよね...。そのため、チャートを見るときは、それらを比較して作業性を推し量るのです。そして、その結果、現実のシステムのインストールは、形式的なものよりも直感的なものが多いですね。どのようにコーディングするのですか？

そして仮想環境についてですが、もしすべてのシステムをデモに置き、あなたの言うとおり「統計のために0.01ロットの取引をする」ことができるのなら、強力なコンピューター（私は1台しか持っていません）を使う意味はあるのでしょうか？それが私の仕事です。屋根裏に古いパソコンがあって、そこに2つの端子があり、TCリーグの中・下位リーグが動作しているんです。トップ部門-UPUに 立つ（消灯することが多いので、トップ部門に使わせてもらっています）。

実は、私のTCリーグは「仮想環境」であり、常に自動運転でシステムをテストしているのです。ここではすべてがセットアップ済みで、テストパラメータの場合の再インストールの手順も、標準的でルーチン化されています。

問題は、最も持続可能なものを選択することにこそあるのです。私は「品質」というパラメーターがとても好きで、なんとか定式化しました。しかし、「安定性」というパラメーターは、私の手の届かないところにあります。今、私が主に取り組んでいるのはそれです。

:-)テストとその値の観点からパラメータを選択した後 - 実システムに直行して戦闘を開始します。デモ機から実機に入れるのが遅い、遅いから実機から外してパラメータの値をリセットしないといけない...。

もちろん実時間は、トレードとテスト時間の賢明なテストサンプルで、テストの20％〜30％です。

この日までは、2年間のテストがあり、1年前に戻って、1年前に進む」という やり方は、IMHOでは正しくありません。この日以降～TSはデモに設定し、最高のデモシステムの結果を投稿します。"ページより。62.

[Roman Shiredchenko]

Andrey Khatimlianskii:

これでは答えにならない。

テスターで動作させるためには、システム選択アルゴリズムが 必要です。そして、それをテストすること。デモは全く必要ない、時間の無駄。

いいですね、奥が深い...。:-)

まだ支店のそのページまで行っていないのですが...。というのも、私自身、トレードに対する考え方が違うので...。

[Roman Shiredchenko]

Georgiy Merts:

しています。でも、石花は出てこない...。

次に明確なのは、リーグがテスターで直接（あるいはスクリプトとテスターの助けを借りて）最適なTCを選択することも可能だということです。しかし、まず第一に、テスターに選択アルゴリズムを詰め込む前に、それを発明する必要があります !つまり、少なくとも何かを「獲る」ためには。その中から最適なものを選んで、このアルゴリズムで選んだシステムが安定的に動くかどうかをテスターで確認することができます。それがないんです。

そこで、「共有プロジェクトリーグ」の準備の際に、まさにこの選択アルゴリズムの実験に再び着手することになりました。

また、「デモは必要ない」ということについてですが、私はそうは思いません。システムの安定性を見るためにデモが 必要です。テスターで動作し、今後も動作することを確認するため。

お墓からお骨を持ち上げるのは勘弁してください。ロバート・パルドのリンク集をご覧ください。そこでは、最適化について、あらゆることを解説しています。

https://www.mql5.com/ru/forum/131853/page4#comment_3359617

必要なのはデモではなく、最適化処理後に与えられたパラメータの集合から平均値を選択するアルゴリズムやアプローチ（呼び方は自由）である。

[Georgiy Merts]

Roman Shiredchenko:

:-)パラメータのテストと選択の後、その値の観点から - すぐに実戦に。デモから本番に投入するのが遅い、遅いから本番から外してパラメータの値を取り直す...。

もちろん実時間は、トレードとテスト時間の賢明なテストサンプルで、テストの20％〜30％です。

この日までは、2年間のテストがあり、1年前に戻って、1年前に進む」という やり方は、IMHOでは正しくありません。この日以降～TSはデモに設定し、最高のデモシステムの結果を投稿します" ページより。62.

デモ口座は "TSの追加テスト "のために不要になりました(これも一役買っていますが）。デモ口座の主な目的は、「TSプール」であり、良好な取引履歴を示すシステムの一定の存在である。

リアルアカウントでの運用時間はテストの20%」についてですが、これは諸刃の剣で、2年間のテスト運用の後、TSの運用時間は最大5ヶ月、2年間のテストにデモでの6ヶ月のテストを加えると、TSの運用時間は最大7ヶ月となり、かなり長くなってしまいます。

現実的には、デモ口座は - 何も変わらない、まあ、私はデモ口座を持っていないでしょう、私はちょうど本物にそれを置くだろう - と質問は同じまま、何を置くためにトップ部門のTSの何百ものですか？

[Georgiy Merts]

Roman Shiredchenko:

お墓からお骨を上げるためのカウントはしないでください。ロバート・パルドのリンク集をチェック最適化もすべてカバーしてくれています。

https://www.mql5.com/ru/forum/131853/page4#comment_3359617

必要なのはデモではなく、最適化処理後に提案されたセットからパラメータの平均値を選択するアルゴリズムやアプローチ（好きなように呼んでください）です。

アルゴリズムやアプローチが必要だと主張する人はいないでしょう。だから、（パルドの推薦も踏まえて）何とかしようと思っているんです。そして、そのためのデモが必要なのです。毎回たくさんのシステムを最適化し直すのではなく、うまくいったものだけをしばらく使い続けることができるのです。

[Roman Shiredchenko]

Georgiy Merts:

1.デモ口座は「TSの追加チェック」のために必要ではなくなりました（その役割はありますが）。(それも一役買っているが）。デモ口座の主な目的は「TSプール」であり、良好な取引履歴を示すシステムの継続的な存在 である。

2.実機での稼働時間はテストの20%」ということですが、これは諸刃の剣で、2年間のテスト稼働でTSの稼働時間は最大5ヶ月、2年間のテストで6ヶ月のデモテストがあれば、すでにTSの稼働時間は7ヶ月となり、かなり長くなってしまうからです。

3.本当にデモ口座を持って - 何も変わらない、よく、デモ口座を持っていないでしょう、私はすぐに本物に置くだろう - と質問は同じまま、何百ものトップディビジョンTSの置くべき？

1.なるほど、 全部積んでいて、総資金が 赤字になっているのですね。

2.そんなことはない、最適化の時間は2年。CUの実行時間は最大5ヶ月。その後、半年デモテスト、その後 - すでに取引され、すべてのテストが終了していません。

"そして、デモの半年ごとのテストがあります - その後、我々はすでに7ヶ月までTSの動作の時間を持っている - これは顕著に長いです。"- いや、マーケットに合わせるためにパラメータを再調整する必要があります。 APRの値からというように、アダプティブにしたほうが......。

Р.パルドは一人でグルになっているわけではありませんが、他の情報源や、mcl4フォーラムでの議論からも、このようなアプローチが検討されているようです。

遺伝的アルゴリズムを用いてパラメータを最適化する場合、最適なモデルパラメータの値を決定する必要があります。

ここでは、パラメータ値の完全な列挙ということで、最適なモデルを取り上げました。

例えば、Optimization - 4年 Forward test 0.5年。4の0.5年は12.5％です。

その後、特定のALGORITHMは最高の "モデル "のパラメータを選択すると、最適化の数のフォワード分析の終わりは、次の（極端な）最適化の後、例えば、あなたが持っているとして、2年間、四半期にフォワードテストではありませんが、すでに取引、リアルまたはデモのいずれか、あなたが取引するアカウントに少しを持っているようなシステムの違いがある場合。

3.いかんともしがたい:-)(ちょっと考えてみてください。私のIMHOは、もう少し後で書きます．)

[削除済み]

Roman Shiredchenko:

1.なるほど、 そこですべてをチャージして、最終的に資金が赤字 になるということですね。

2.そんなことはない、最適化の時間は2年、TSの運用時間は5ヶ月まで。その後、半年デモテスト、その後 - すでに取引され、すべてのテストが終了していません。

"そして、デモの半年ごとのテストがあります - その後、我々はすでに7ヶ月までTSの動作の時間を持っている - これは顕著に長いです。"- いや、マーケットに合わせるためにパラメータを再調整する必要があります。 APRの値からというように、アダプティブにしたほうがいいのですが......。

Р.パルドは一人でグルになっているわけではありませんが、他の情報源や、mcl4フォーラムでの議論からも、このようなアプローチが検討されているようです。

遺伝的アルゴリズムを用いてパラメータを最適化する場合、最適なモデルパラメータの値を決定する必要があります。

ここでは、パラメータ値の完全な列挙ということで、最適なモデルを取り上げました。

例えば、最適化-4年 フォワードテスト0.5年。4の0.5年は12.5％です。

その後、特定のALGORITHMは最高の "モデル "のパラメータを選択すると、最適化の数のフォワード分析の終わりは、次の（極端な）最適化の後、例えば、あなたが持っているとして、2年間、それは四半期にフォワードテストではありませんが、すでに取引、リアルやデモで、あなたが取引するアカウントに少しを持っているようなシステムの違いなら、どちらか。

3.いかんともしがたい:-)(感想があります。私のIMHOは、もう少し後で書きます...)

私はGeorgeのアイデアを気に入っていますが、一つ難点があります。