ちょっとびっくり :)私は、共有し、NOT修辞的な質問をすることを考えました。 - ページ 14

新しいコメント
 
Renat:

オプティマイザーは正確には「線形スケールのテスター」ではなく、大規模な繰り返し計算で有効に機能する独自の最適化手法を持っています。

今はちょうど、質量計算のスピードアップに追われているところです。過去の結果への リンクはこちらです。計算を高速化した新バージョンも準備中です。

そうですね、「リニアスケールのテスター」というわけではありませんね。明示的な最適化を行うのは、非常に良いことです。しかし、一変量の場合、どのように最適化するのか想像がつきません......非常に頻繁に起こる状況です。

最適化は2つのパラメータに対して行われ、1つのパラメータ（100の値の範囲）はインジケータのコールに触れませんが、2つ目のパラメータ（5つの値の範囲）は触れます。

この場合、500個のバリアントを検索しながら、500回指標値を計算することになります。この場合、実際には膨大な数の再計算を行うことになります。これは、2番目の変数の範囲が500ではなく5しかないためです。

これはあくまで一番簡単な例です。もしかしたら、このテスターのオプティマイザーに対する線形スケーラビリティを回避する方法を、すでに思いついているかもしれませんね。

追伸：こういう例があるから、自分の計算機ではパーセントではなく桁違いのスピードアドバンテージが得られるんですね。しかし、これらの電卓は万能ではないので、比較すること自体が最初から間違っているのです。

 
Academic:

クラウドコンピューティングを使わずに、マルチスレッドで、C++とMT4（とそのすべてのサブシステム）をサポートして、それより100倍速く、純粋にMT5のコードで6倍速いオプティマイザがあるとしましょう、はい...。で、ブルートフォースやGAだけでなく、さらに約50種類のバリエーションで「解決」します。いくらで買いますか？1000円なら買いますか？なぜこんなに高いかというと、購入者はあなたと他の10人だけだからです。:)

オプティマイザーが普遍的なもので、そのような特徴があれば、購入したいと思います。
 
hrenfx:

しかし、一変量の場合、どのように最適化するのか想像がつきません......非常に頻繁に起こる状況です。

もう何となく想像がつく（でも完全ではない）。オプティマイザーを実行する前に、最適化する入力パラメータの依存性分析を行う必要があります（上記の例では、2つの変数が完全に独立しています）。次に、まず独立変数の最小範囲から最大範囲まで最適化を実行します（同じ指標の資源強度にも依存するため、必ずしも正しいとは限りません）。重いインジケーターを5回数えるより、軽いインジケーターを100回数える方が良い場合もある）、結果をキャッシュする。

このような最適化の実装が非常に複雑であることは明らかです（特にクラウドの場合）。しかし、もし実装されれば、少なくともMQL5 Wizardで作成されたExpert Advisorはすべて、桁違いに高速に最適化されることになります。なぜなら、MQL5 Wizardは多数の指標を互いに組み合わせている（つまり、互いに独立した膨大な数の入力パラメータがある）ためです。もうひとつは、そのような活動は利益を生む取引には意味をなさないということです...。

 

数百万から数千万という膨大なサンプルに対して、キャッシュした後にサンプリングした結果は、直接計算するよりもコストがかかる。

 
Renat:

膨大な（数百万、数千万）サンプルに対して、その後の結果のサンプリングを伴うキャッシュは、直接計算よりもコストがかかる。

完璧な万能オプティマイザーを実装して、上に書いたような「賢さ」を実現するのは、ほとんど非現実的なことだと思います。もちろん、改善の余地はありますが、どんな場合でも完璧というわけにはいきません。

膨大なサンプル（数千万件）、もちろん相当誇張していますよね。そんなものをキャッシュする必要はまったくない。

皆さんは、私の言いたいことをよく理解していると思います。そして、多くの人がそうしています。誰も批判すらしない、そうでなければプログラマーの無知な批評家になってしまう。なぜなら、それなりの人は、そういうことを実行することの難しさをよく理解しているからです。

同じ例を使って、キャッシュの考え方を説明しましょう。

もし、インジケータが再描画されなければ、テスターでの1回の実行の終わりまでに、インジケータのすべての値の完全なバッファを持つことになります。すでに持っているんですね。また、次のパスで同じ指標値を使う（2番目の変数が変わっていない）場合は、再度読み込む必要はない。すでに計算済みのバッファ（すでに持っている、キャッシュする必要はない、前回実行時のメモリが完全に空いているわけではない）から値を取ることができます。

 
hrenfx:

インジケータが再描画されない場合

これは、これ以上の検索を無効にする「もし」です。
 
そう、まさにそんな高速なユニバーサル・オプティマイザを書くことは不可能なので、非ユニバーサルな数値計算グラインダが常に速度面で勝っているのです。それに、良いも悪いもない。
 
hrenfx:

完璧な万能オプティマイザーを実装して、上に書いたような「賢さ」を実現するのは、ほとんど非現実的なことだと思います。もちろん、改善の余地はたくさんありますが、とにかく完璧にはできないのです。

巨大なサンプル（数千万単位）、もちろん相当誇張していますよね。そんなものをキャッシュする必要はまったくない。

例えば、過去11年間のEURUSDのテストでは、5,000万回以上のティックを与えています。

つまり、MAのような単純な1バッファのインジケータでは、5000万個の状態（5000万×8バイト（double）＝400 mbバッファ）を保存しなければならず、これは多すぎるということです。もっと複雑なものや数が多いものを使うと、マルチコアエージェントはともかく、実際にはキャッシュがメモリに収まらなくなるのです。

インジケータ・キャッシュのアイデアを練っていたところ、キャッシュを構築するよりも、次のインジケータ値を計算する方が（しかも経済的な方法で）はるかに速く、リソース消費も少ないことが判明したのです。

 
hrenfx:
そう、まさにそんな高速なユニバーサルオプティマイザーを書くことは不可能なので、非ユニバーサルな数値計算グラインダーが常に速度面で勝っているのです。それに、良いも悪いもない。

彼らは何も勝ち取らない。

市場環境も、インフラも、指標も、分析もないのです。そして、これは一過性のサイクルよりも重要なことなのです（と、表してもいない）。

 
Renat:

例えば、過去11年間のEURUSDのテストでは、5,000万回以上のティックを与えています。

私たちはオプティマイザーの話をしているのであって、シングルテスターを何度も走らせているわけではありません。オプティマイザーのコンセプトは全く異なる。そこでは、結果のわずかな誤差を犠牲にして、大幅な速度向上が達成される。オプティマイザには、刻みに基づくモデルは全く必要ないのです。せいぜい開店価格が基準です。オプティマイザーはテスターではなく、全くの別物です。あなたのアプローチは違いますし、非常に論理的でもあります。

レナット：

彼らは何も勝ち得ていないのです。

市場環境も、インフラも、指標も、分析もないのです。そしてそれは、一過性のサイクルよりも重要なことなのです（と、表してもいない）。

スピードでは勝っている。フォアサイクルだけでは、何も速くならないからだ。時にはスピードがまさに必要で、電卓はスピードではどんな万能テスターにも勝ります（ただし他のパラメーターでは勝てません）。MetaQuotesからだけでなく。

次の理由から、私の主張を証明することはできません。

私の計算機は、私のEAをC++で実装しただけのもので、すべての演算を特別に整数化し（価格は整数）、不要なパスなどを完全にゼロにしたものである。そこには、何のインターフェースもありません。出力は、最適化結果の ファイルのみです。例えば、私はC++でアルゴリズムの最適化を行ったEAを書くことができますが、私のテスターは取引のチェック（例えば、十分なマージンがあるかどうかのチェックなど）を行いません。歴史をエミュレートしないし、指標をカウントしない。MT5テスターの汎用性という点では、普遍的なものはありません。電卓の仕事はただ一つ、できるだけ早く計算することである。そして、MT4テスターの100倍の速さでカウントし、1％未満の誤差を発生させる。ここで何を見せたいのかがわからない。

チェックを行わず、整数だけを扱うforループは、ユニバーサルテスターよりも常に高速にカウントされることは明らかです。

1...789101112131415161718192021...25
新しいコメント