MQL5とMQL5 Cloud Networkのユニバーサル数学計算の追加サポートのために追加すべきものは何ですか? - ページ 2

 
komposter:

ちょっと違うんです。私がやりたかったのは、最適化のコースをコントロールすることです。

大雑把に言うと、自分の遺伝子が欲しいということでしょうか。
 
TheXpert:
大雑把に言うと......遺伝子が欲しい?

元々、そうですね、ジェネレーションを求められていたんです。

そして、自動最適化(過去の結果をもとにしたパラメータ領域の選択)のために使うだけです。

 
komposter:

そして、自動最適化(過去の結果を元にしたパラメータ領域の選択)に使うだけです。

優れた自動最適 化のためには、テスターは連鎖から切り離されるべきなのです。
 
TheXpert:
大雑把に言うと、遺伝子が欲しいのですか?

この方向ですが、一概にそうとは言えません。

まず、標準的なGAがすべて(〜10Kフルパラメータ、マルチパラメータ最適化)を満足するのであれば、不満のほとんどは黙殺されるでしょう。

ただ、もうひとつ難点があって、ある種の本能で最適化をやめて、もっと先に進みたくなることがあるんです。自動FFを手動で補正するもの。

それも、ごく一部の要求の高いユーザーが、最終的にGAで問題を解決してくれれば。

そして、少数の不満なユーザーによって開発者が恥をかかないように、彼らは通常、最も先進的なユーザーであり、人は彼らこそ尊敬すべきなのです。

ZZY でも、実際はおっしゃるとおりで、遺伝子がボディに近いので、クルーデスの中で走らせたらカッコイイと思いますね。ちなみに、そうすれば、valk-forwardのテストは、MQからこのモードを請う必要がなく、自力で問題を解決することが可能になります。

 
Urain:

そして、不満を持っている人が少ないからと言って、開発者が恥ずかしくないように、大抵は上級者向けです。

実は、この要素がリジェクトのプロセスで最も重要なのです。

要するに、狭い範囲の先進的な人たちが使うようなタスクに気を取られることになるのです。

 
sergeev:

実は、これが断られる一番の要因なのです。

要するに、狭い範囲の上級ユーザが使うようなタスクに気を取られることになる。

それが、上級者は初心者よりも多くのことを見ています。時間が経つにつれて、その問題意識が他の人にも広がり、上級者がすでに使いたいと思っている機能を、他の人も使いたいと思うようになるのです。

メインストリームに 焦点を当てると、プラットフォームは常に過去のものとなってしまうのです。

コダックが石鹸箱を作り、現像機のネットワークを構築する以前は、観光客は自分で写真を撮ろうとはせず、上級者や写真のプロ(どの観光地にもたくさんいる)の特権であった。

しかし、あるイノベーターが現れ、新しいサービスを生み出すことで、業界をひっくり返し、大衆に普及させることができたのです。

 
Urain:

それが面白いところで、上級者は初心者よりも多くのことを見ています。時間が経つにつれて、彼らの問題意識が他の人にも広がり、上級者がすでに使いたいと思っている機能を彼らも使いたいと思うようになるのです。

メインストリームに焦点を当てると、プラットフォームは常に過去のものとなってしまうのです。

コダックが石鹸箱を作り、現像機のネットワークを構築する以前は、観光客は自分で写真を撮りたいとは思っていなかった。それは上級ユーザーや写真のプロ(どの観光地にもたくさんいる)の特権であった。

しかし、あるイノベーターが現れ、新しいサービスを生み出すことで、業界をひっくり返し、大衆に普及させることができたのです。

私もそう思います。両方と。:)))

インターフェースを考えなければならない。 カスタムジェネレータとは何か? SetPopullationForCalc(); GetPopulationFitnessFuncs(); 」というレベルで行うクロードとのインターフェースでは、柔軟で強力なスキームが機能しなくなる。クラウドとの交換は、母集団の大きさを固定せず、パラメータ配列と一緒にパラメータとして渡すランダムボリュームタスクパッケージのレベルで実装するのが良いだろう。 さらに、完全に切り離す必要がある(ついに!最適化」と「テスト」、(並行して任意の!)パラメータセットのアレイの(1)大量の軽量群衆計算(最適化のアナログ)と(2)詳細な単一実行(「テスト」のアナログ)の要求を交互に組み合わせて与える可能性。 その後、バルクフォワードは問題なく構築され、残りのすべては今でも頭に浮かんでいないお茶でカッカしています。

そんな思いが込められています。

結論としては、テスターと端末のプログラムの間に柔軟なAPIレイヤーを考えることで、「取引中に遺伝的最適化を開始し、その場でロボットパラメータを修正する」という古くからある問題を、他の問題とともに淡々と解決していくことになるのです。特にクラウドは、単一型の大量計算で任意の課題を解決できる、超普遍的な大衆向けメガコンピューターとなる。

 
TheXpert:
優れた自動最適化のためには、テスターは連鎖から切り離されるべきなのです。

EAの 実行時の自動最適化ではなく、例えば、自分でウルフフォワードをするような話です。

将来の実行のためにパラメータ範囲を選択すれば、この問題は100%解決します(同じパラメータを使用してプログラム的に日付を制限することができます)。

しかし、これは、クルードの使い方からして、一筋縄ではいかないのです。

 
komposter:

EAを 稼働させながら自動最適化するのではなく、例えば社内でウルフフォワードをするような話です。

あの、私から見ても同じなんですけど :)

ウラン です。

まず、標準的なGAが全て(~10Kフルパラメータ、マルチパラメータ最適化)を満足するのであれば、不満の多くは黙殺されるでしょう。

はい、5-10人のうちほとんどが不満を持っています :)
 
TheXpert:
はい、5-10人のうちほとんどが不満を持っています :)
不満を持っている人の方が圧倒的に多いと思います。 多くの人は、例えば遺伝子のことを考えるほどのスキルを持っていないだけです。 また、テスターAPIがないから大量のカスタム開発ができないのです。 APIが登場すれば、狼最適化などの異国の「聖杯生成装置」によるポピーマスソリューションが登場するでしょう。 クラウドの需要は確実に跳ね上がるはずです。