ストラテジーテスターにおける最適化 - ページ 10 1...34567891011121314151617...19 新しいコメント Renat Fatkhullin 2010.12.28 17:13 #91 最新のビルドでは、タスク実行時のシステムオーバーヘッドを完全に排除し、約2000ミリ秒からゼロに削減しました。jooさんからご提案いただいた、計算タスクの実行結果です。input double x1=0.0; input double x2=0.0; double OnTester() { return ( pow(cos((double)(2*x1*x1))-0.11 e1,0.2 e1)+ pow(sin(0.5 e0 *(double) x1)-0.12 e1,0.2 e1) - pow(cos((double)(2*x2*x2))-0.11 e1,0.2 e1)+ pow(sin(0.5 e0 *(double) x2)-0.12 e1,0.2 e1) ); } 設定（チャート履歴を使用しないため、あえて日付が設定されています）。実行するパラメータ。使用代理店（現地代理店4社）。最適化結果。最適化にはわずか25秒、18,432回のパスが行われた。総合結果：MetaTrader 5とそのエージェントのネットワークは、膨大な数学的計算に使用することができます。 Andrey Dik 2010.12.29 13:13 #92 Renat:最新のビルドでは、タスク実行時のシステムオーバーヘッドを完全に排除し、約2000ミリ秒からゼロに削減しました。jooさんからご提案いただいた、計算タスクの実行結果です。設定（チャート履歴を使用しないため、あえて日付が設定されています）。実行するパラメータ。使用中のエージェント（ローカルエージェント4名）。最適化結果。最適化にはわずか25秒しかかからず、18,432回のパスが行われた。全体的な結果：MetaTrader 5とそのエージェントのネットワークは、大規模な数学的計算に使用することができます。これは非常に良い結果だと思います。これでオプティマイザーは、多かれ少なかれ、最適化タスク（トレーディング関連と非トレーディング関連の両方）に本当に適しています。デフォルトのオプティマイザーGA設定で、この特定のタスクのパス数を2-3千に減らすことができれば、結果はさらに良くなります。しかし、そのためには、ユーザーがアクセスできるようにGA設定を表示する必要があります（ユーザーが望むなら、パス数を500-900に減らすことが可能になります）。探索空間の制限という問題が残る。それに対応するオプティマイザーの提案がservicedkで行われています。 Mykola Demko 2010.12.29 14:32 #93 joo:これは非常に良い結果だと思います。これで、オプティマイザーは本当に多かれ少なかれ、最適化タスク（トレーディングと非トレーディングに直接関係するもの）に適していることになります。オプティマイザーのデフォルトのGA設定で、この特定のタスクのパス数を2～3千に減らすことができれば、さらに良い結果が得られますが、そのためには、ユーザーがGA設定を利用できるようにする必要があります（ユーザーが望むなら、パス数を500～900に減らすことは可能でしょう）。探索空間の制限に関する問題が残って いる。サービスデスクでは、それに対応したオプティマイザーの提案がなされています。 そして、この問題の解決は、主にこの問題に関連しています。もし、すでに4つのパラメータで最適化パスのオーバーフローが起こっているのであれば、現在許容されている（64）よりもパラメータ数を増やすという話はまだ適切ではありません。 Andrey Dik 2010.12.29 14:53 #94 Urain:そして、この問題の解決は、主にこの問題にリンクしています。4つのパラメータで既に最適化のオーバーフローが起きているのであれば、今以上にパラメータを増やすという話はまだ適切ではありません（64）。もちろんです。ここで、nは最適化するパラメータの数、stepはパラメータのステップ数であり、大まかな探索空間はP=n*stepである。同時に、PはPmax（染色体のバイナリコーディングの特徴によって制限される最大可能探索空間）より小さい必要があります。そこで、PがPmaxを超えないように、人為的に導入した制限（例えば、パラメータを10000個に制限することもできますが、そうすると、ほとんどの最適化問題を解くのに必要以上のステップになってしまいます）の1つとして、nに制限を導入しました。この点については、servicedkのオプティマイザーの提案で声が上がっています。 PS リモートエージェントネットワークの拡大により、ラン数が多いという問題は無くなります。ただし、もちろん、2値の染色体コーディングの制約を取り除いた場合（実数による染色体コーディングに切り替えた場合）に限ります。 Mykola Demko 2010.12.29 15:48 #95 joo:もちろんです。ここで、nは最適化されるパラメータの数、stepはパラメータのステップ数です。したがって、PはPmax（染色体のバイナリコーディングの特徴によって制限される最大可能探索空間）より小さい必要があります。そこで、PがPmaxを超えないように人為的に導入した制限（例えば、パラメータを10000個に制限することもできますが、そうすると、ほとんどの最適化問題を解くのに必要以上のステップになってしまいます）の一つとして、nに制限を設けました。これについては、Service Deskのオプティマイザーの提案に考えが示されています。 PS リモートエージェントのネットワークが大きくなると、大量のランが発生する問題はなくなります。ただし、もちろん、2値の染色体コーディングの制約を取り除いた場合（実数による染色体コーディングに切り替えた場合）に限ります。少し間違っています。正しい variant の数はP=step_0*step_1*...*step_n です。となり、ステップサイズが等しい場合は、P=step^n となります。 Andrey Dik 2010.12.29 16:04 #96 Urain:若干の間違い、正しい選択肢の数はP=step_0*step_1*...*step_nとなり、ステップサイズが等しい場合は、P=step^n となります。 そうですね、その通りです。私が言いたいのは、もっとはっきり、もっとはっきりさせるために、何が何に依存するのか、ということです。 Yedelkin 2010.12.29 16:13 #97 Renat: 最新のビルドでは、タスク起動時のシステムオーバーヘッドを完全に排除し、約2000ミリ秒からゼロに削減しました。 ファンタスティック!ああ、夏の間、最適化にどれだけ時間を費やしたことか...。 まずはじめに現在のビルドとビルド319（2010年9月2日）でjooさんのテストを実行しました。 2010 12/229 15:49:18 テスター合格時間 2分41秒 2010.12.29 15:49:18 テスターの最適化はパス15360で終了（100000020000001のうち）。 2010.12.29 15:49:18 テスター結果キャッシュ使用回数 7265回 2010.12.29 15:49:13 テスタージェネレーションズ終了 2010.12.29 17:10:59 テスター最適化通過時間：1時間17分34秒 2010.12.29 17:10:59 テスタージェネティクス最適化はパス18176で終了（100000020000001のうち）。 2010.12.29 17:10:59 テスター結果のキャッシュは10582回使用されました。 2010.12.29 17:10:52 テスタージェネレーションズ終了 祝福していいのか、感謝していいのか、わからないくらいです。ありがとうございました。 Optimisation in the Strategy Off-topic MT4/mql4 questions. MQLに関するオフトピックな質問 Renat Fatkhullin 2010.12.29 17:00 #98 Urain:そして、この問題の解決は、そもそもこの問題に関係しているのです。もし、すでに4つのパラメータで最適化パスのオーバーフローが発生しているのであれば、現在許容されているパラメータ数（64）よりも増やすという話はまだ適切ではありません。ロシア人が日本のチェーンソーを壊す」モードでツマミを最大まで回さないように、合理的な方法で検索してください。遺伝的最適化を実作業に適用し始めると、すぐに合理的な限界を選択するようになる。 Renat Fatkhullin 2010.12.29 20:35 #99 Yedelkin:ファンタスティック!え、夏の間、最適化にどれだけ時間を浪費したことか......。 順番に現在のビルドと319番目のビルド（2010年9月2日）でテストしています。 2010.12.29 15:49:18 Tester optimization passed in 2 minutes 41 seconds 2010.12.29 15:49:18 Tester genetic optimization finished on pass 15360 (of 100000020000001) 2010.12.29 15:49:18 Tester result cache was used 7265 times 2010.12.29 15:49:13 Tester genetics is over. 2010.12.29 17:10:59 Tester optimization passed in 1 hours 17 minutes 34 seconds 2010.12.29 17:10:59 Tester genetics finished on pass 18176 (of 100000020000001) 2010.12.29 17:10:59 Tester result cache was used 10582 times 2010.12.29 17:10:52 Tester genetics is over.祝福していいのか、感謝していいのかわからない。ありがとうございました。なお、「端末からエージェントへの初期データの同期・送信、エージェントからの結果受信」フェーズでは、システムのオーバーヘッドを削減し、1回あたり1.5〜2秒の短縮を実現しました。言語自体に計算の加速度が ないのだ。つまり、これが最も深刻な影響を及ぼすのは、計算時間がゼロに近い高速計算の場合である。大規模な計算のための節約は、それほど顕著ではありません。1万回につき2秒の短縮で、2万秒＝333分＝5.5時間となりますが。 marker 2011.01.09 22:36 #100 Renat: それはない。 効果があることに気づきました。平日にEAを動かして、今はスプレッドを広げて動かしていますが、結果はかなり違っていて、今のユーロバックのスプレッドは4pips（4桁）くらいです。mt5でも週末にスプレッドジャムが発生するので、最適化がうまくいかないので週末には動かさないようにしています。あるEAが月曜日から最適化され、週末から結果曲線が下がっているのをmt4で視覚的に見ることもできます。それは、スプレッドが最適化結果に 影響を与え、悪化していることを証明しています。 1...34567891011121314151617...19 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
最新のビルドでは、タスク実行時のシステムオーバーヘッドを完全に排除し、約2000ミリ秒からゼロに削減しました。
jooさんからご提案いただいた、計算タスクの実行結果です。
設定（チャート履歴を使用しないため、あえて日付が設定されています）。
実行するパラメータ。
使用代理店（現地代理店4社）。
最適化結果。
最適化にはわずか25秒、18,432回のパスが行われた。
総合結果：MetaTrader 5とそのエージェントのネットワークは、膨大な数学的計算に使用することができます。
最新のビルドでは、タスク実行時のシステムオーバーヘッドを完全に排除し、約2000ミリ秒からゼロに削減しました。
jooさんからご提案いただいた、計算タスクの実行結果です。
設定（チャート履歴を使用しないため、あえて日付が設定されています）。
実行するパラメータ。
使用中のエージェント（ローカルエージェント4名）。
最適化結果。
最適化にはわずか25秒しかかからず、18,432回のパスが行われた。
全体的な結果：MetaTrader 5とそのエージェントのネットワークは、大規模な数学的計算に使用することができます。
これは非常に良い結果だと思います。これでオプティマイザーは、多かれ少なかれ、最適化タスク（トレーディング関連と非トレーディング関連の両方）に本当に適しています。デフォルトのオプティマイザーGA設定で、この特定のタスクのパス数を2-3千に減らすことができれば、結果はさらに良くなります。しかし、そのためには、ユーザーがアクセスできるようにGA設定を表示する必要があります（ユーザーが望むなら、パス数を500-900に減らすことが可能になります）。
探索空間の制限という問題が残る。それに対応するオプティマイザーの提案がservicedkで行われています。
これは非常に良い結果だと思います。これで、オプティマイザーは本当に多かれ少なかれ、最適化タスク（トレーディングと非トレーディングに直接関係するもの）に適していることになります。オプティマイザーのデフォルトのGA設定で、この特定のタスクのパス数を2～3千に減らすことができれば、さらに良い結果が得られますが、そのためには、ユーザーがGA設定を利用できるようにする必要があります（ユーザーが望むなら、パス数を500～900に減らすことは可能でしょう）。
探索空間の制限に関する問題が残って いる。サービスデスクでは、それに対応したオプティマイザーの提案がなされています。
そして、この問題の解決は、主にこの問題に関連しています。
もし、すでに4つのパラメータで最適化パスのオーバーフローが起こっているのであれば、現在許容されている（64）よりもパラメータ数を増やすという話はまだ適切ではありません。
そして、この問題の解決は、主にこの問題にリンクしています。
4つのパラメータで既に最適化のオーバーフローが起きているのであれば、今以上にパラメータを増やすという話はまだ適切ではありません（64）。
もちろんです。ここで、nは最適化するパラメータの数、stepはパラメータのステップ数であり、大まかな探索空間はP=n*stepである。同時に、PはPmax（染色体のバイナリコーディングの特徴によって制限される最大可能探索空間）より小さい必要があります。そこで、PがPmaxを超えないように、人為的に導入した制限（例えば、パラメータを10000個に制限することもできますが、そうすると、ほとんどの最適化問題を解くのに必要以上のステップになってしまいます）の1つとして、nに制限を導入しました。
この点については、servicedkのオプティマイザーの提案で声が上がっています。
PS リモートエージェントネットワークの拡大により、ラン数が多いという問題は無くなります。ただし、もちろん、2値の染色体コーディングの制約を取り除いた場合（実数による染色体コーディングに切り替えた場合）に限ります。
もちろんです。ここで、nは最適化されるパラメータの数、stepはパラメータのステップ数です。したがって、PはPmax（染色体のバイナリコーディングの特徴によって制限される最大可能探索空間）より小さい必要があります。そこで、PがPmaxを超えないように人為的に導入した制限（例えば、パラメータを10000個に制限することもできますが、そうすると、ほとんどの最適化問題を解くのに必要以上のステップになってしまいます）の一つとして、nに制限を設けました。
これについては、Service Deskのオプティマイザーの提案に考えが示されています。
PS リモートエージェントのネットワークが大きくなると、大量のランが発生する問題はなくなります。ただし、もちろん、2値の染色体コーディングの制約を取り除いた場合（実数による染色体コーディングに切り替えた場合）に限ります。
少し間違っています。正しい variant の数はP=step_0*step_1*...*step_n です。
となり、ステップサイズが等しい場合は、P=step^n となります。
若干の間違い、正しい選択肢の数はP=step_0*step_1*...*step_n
となり、ステップサイズが等しい場合は、P=step^n となります。
最新のビルドでは、タスク起動時のシステムオーバーヘッドを完全に排除し、約2000ミリ秒からゼロに削減しました。
ファンタスティック!ああ、夏の間、最適化にどれだけ時間を費やしたことか...。
まずはじめに現在のビルドとビルド319（2010年9月2日）でjooさんのテストを実行しました。
2010.12.29 15:49:18 テスターの最適化はパス15360で終了（100000020000001のうち）。
2010.12.29 15:49:18 テスター結果キャッシュ使用回数 7265回
2010.12.29 15:49:13 テスタージェネレーションズ終了
2010.12.29 17:10:59 テスタージェネティクス最適化はパス18176で終了（100000020000001のうち）。
2010.12.29 17:10:59 テスター結果のキャッシュは10582回使用されました。
2010.12.29 17:10:52 テスタージェネレーションズ終了
祝福していいのか、感謝していいのか、わからないくらいです。ありがとうございました。
そして、この問題の解決は、そもそもこの問題に関係しているのです。
もし、すでに4つのパラメータで最適化パスのオーバーフローが発生しているのであれば、現在許容されているパラメータ数（64）よりも増やすという話はまだ適切ではありません。
ロシア人が日本のチェーンソーを壊す」モードでツマミを最大まで回さないように、合理的な方法で検索してください。
遺伝的最適化を実作業に適用し始めると、すぐに合理的な限界を選択するようになる。
ファンタスティック!え、夏の間、最適化にどれだけ時間を浪費したことか......。
順番に現在のビルドと319番目のビルド（2010年9月2日）でテストしています。
2010.12.29 15:49:18 Tester genetic optimization finished on pass 15360 (of 100000020000001)
2010.12.29 15:49:18 Tester result cache was used 7265 times
2010.12.29 15:49:13 Tester genetics is over.
2010.12.29 17:10:59 Tester genetics finished on pass 18176 (of 100000020000001)
2010.12.29 17:10:59 Tester result cache was used 10582 times
2010.12.29 17:10:52 Tester genetics is over.
祝福していいのか、感謝していいのかわからない。ありがとうございました。
なお、「端末からエージェントへの初期データの同期・送信、エージェントからの結果受信」フェーズでは、システムのオーバーヘッドを削減し、1回あたり1.5〜2秒の短縮を実現しました。言語自体に計算の加速度が ないのだ。
つまり、これが最も深刻な影響を及ぼすのは、計算時間がゼロに近い高速計算の場合である。大規模な計算のための節約は、それほど顕著ではありません。1万回につき2秒の短縮で、2万秒＝333分＝5.5時間となりますが。
それはない。
効果があることに気づきました。平日にEAを動かして、今はスプレッドを広げて動かしていますが、結果はかなり違っていて、今のユーロバックのスプレッドは4pips（4桁）くらいです。mt5でも週末にスプレッドジャムが発生するので、最適化がうまくいかないので週末には動かさないようにしています。あるEAが月曜日から最適化され、週末から結果曲線が下がっているのをmt4で視覚的に見ることもできます。それは、スプレッドが最適化結果に 影響を与え、悪化していることを証明しています。