記事「母集団最適化アルゴリズム：焼きなまし(SA)アルゴリズム（第１部）」についてのディスカッション - ページ 2

[Andrey Dik]

Aleksey Nikolayev #:
その通りだ。

コーディングする上でも、実際に使用する上でも、非常に不便な技術だ。このことは、例えば社内オプティマイザーがこれを使用していないことからも確認できる。

このアプローチは、複数の最適化（不定回数、場合によっては各回のパラメータセットも不定）を実行しなければならない場合には、ほとんど適用できない。例えば、アンサンブルMOモデルなどである。

ここで言えることはOpenCLはそれほどひどいものでも便利なものでもなく、その上のコードは構文的にはMQL5と変わらない（MQL5特有の関数を使わない限り）。別個の論理コードセクションだけでなく、例えばエキスパートアドバイザーのロジック全体をOpenCLで並列化し、エージェント上の標準的なオプティマイザーのように履歴を通して実行を整理することができます。このように、Expert Advisorのオンラインモードで最適化/トレーニングを行うことが可能です。

MetaQuotesは並列化機能を提供していますが、ネイティブ言語の機能が利用できるようになれば素晴らしいことです。開発者にとっては、コード部分の自動並列化よりも、関数の三重化（ユーザーを待つ方が早い）の方が実装しやすいと思います。開発者の願いとして、ぜひ聞いてほしい。

[Aleksey Nikolayev]

Andrey Dik #:
ここで言えることは...OpenCLはそれほどひどいものでも便利なものでもなく、そのコードは構文的にはMQL5と変わりません（MQL5特有の関数を使わない限り）。別々の論理的なコードセクションだけでなく、例えばエキスパートアドバイザーのロジック全体をOpenCLで並列化し、エージェント上の標準的なオプティマイザーのように履歴を整理して実行することができます。これが、エキスパート・アドバイザーのオンライン・モードでの最適化/トレーニングの方法です。

問題はコーディングそのものにあるのではなく、マニュアルがないことにあるのだろう。私の知る限り、プログラムをデバッグしたGPU以外のGPUに移植する際に問題がある。MT5がwyne経由でlinuxで動くようになったとき、これが流行るかどうかはまたわからない。
。予期せぬMTのアップデートなどにより、発見された問題の解決策が常に破られる可能性がある。

Andrey Dik#:
MetaQuotesは並列化機能を提供しているが、ネイティブ言語機能があれば最高だ。開発者にとっては、コード断片の自動並列化よりも、関数の三重化（ユーザーを待つ方が早い）を実装する方が簡単だと思います。開発者の願いとして、ぜひ聞いてほしい。

可能性が乏しすぎる。

[Aleksey Nikolayev]

Andrey Dik #:

集団アニーリングについて疑問が生じた。母集団の各解が（合理的な範囲内でランダムに）アニーリングパラメータを選択することは意味があるのだろうか？これは、a)収束性を向上させ、b)最適なメタパラメータを選択することに類似しているのでしょうか？

[Andrey Dik]

Aleksey Nikolayev #:
おそらくマニュアルがないためにそうなるのだろうが、問題はコーディングそのものにはあまりない。私の知る限り、プログラムをデバッグしたGPU以外に移植する際には問題がある。MT5がwyneを経由してlinuxで動くようになったとき、これが流行るかどうかはまたわからない。発見された問題の解決策は、予期せぬMTのアップデートなどにより、常に壊れる可能性がある。

OpenCLは、マルチコアデバイス（GPUかCPUかは関係ない）上で並列計算を整理する普遍的な方法として正確に開発された。異なるデバイス上でOpenCLプログラムが問題を起こす確率は、異なるハードウェアを持つコンピュータ上で通常のWindowsアプリケーションが問題を起こす確率よりも高くはありません（むしろ低いかもしれません）。

Windows環境の仮想化の仕様と品質によります。

[Andrey Dik]

Aleksey Nikolayev #:

集団アニーリングについて疑問が生じた。母集団の各解が（合理的な範囲内でランダムに）アニーリングパラメータを選択することは意味があるのだろうか？これは、a)収束性を向上させ、b)最適なメタパラメータを選択することに類似しているのでしょうか？

いい質問だ。アルゴリズムをテストし、アルゴリズムの外部パラメータを選択するとき、私はテスト関数の集合に対する全体的な集約的パフォーマンスから進めます。さらに、異なる外部パラメータは、異なる問題の次元に対して最適である可能性もあります。したがって

a) は、異なるタイプの問題に対する収束精度を向上させ、スタックする確率を減少させます。

b) はい

ただ一つ言えることは、このテクニックは収束速度を少し（あるいはかなり）低下させる可能性があるということです（収束精度は向上しますが）。

[Aleksey Nikolayev]

Andrey Dik #:

いい質問だ。アルゴリズムをテストし、アルゴリズムの外部パラメータを選択するとき、私はテスト関数の集合に対する全体的な総合パフォーマンスから進めますが、最適なパラメータは個々の関数ごとに異なるかもしれません（そして、通常は異なります）。さらに、異なる外部パラメータは、異なる問題の次元に対して最適である可能性もあります。ですから、そうです：

(a)は、異なるタイプの問題に対する収束精度を向上させ、スタックする確率を減少させます。

b) はい

ただ一つ言えることは、このテクニックは（収束精度を上げながら）収束速度を少し（あるいはかなり、見る必要がある）下げる可能性があるということだ。

有益な回答をありがとう。実用的な実験になり、興味深い結果が出たら、ここに書きます。今のところ、私は興味本位であなたの最適化に関する一連の記事を知っているだけです。