アルゴリズム最適化選手権。 - ページ 60

新しいコメント
 
Yuri Evseenkov:
すなわち、NULL配列を渡して、すべてのパラメータが0に等しい場合、FFの値を求めることが可能である。

0.0は範囲[-10.0;10.0] に入るのでしょうか？- はい、そうです。つまり、0.0という値で埋め尽くされた配列から、パラメータでFF値を求めることができるのです。

実際、FFにどんな数字を入れてもいいというわけではありませんが、[-10.0;10.0] の範囲でしか適切な答えは得られず、範囲を超えるとその限界まで数字が切り捨てられるのです。これを考慮しなければ、FFの値は常にFFの最小値 （任意の、しかし変化しない）を与えられるので、あなたのアルゴリズムは、彼が滑らかな緑の表面で得たと考えることができ、（彼のプロセスはチェッカーを停止しませんまで）実数の広大な広がりで無限にさまよう。

 
Andrey Dik:

0.0は範囲[-10.0;10.0] に入るのでしょうか？- はい、そうです。つまり、0.0という値で埋め尽くされた配列から、パラメータでFF値を求めることができるのです。

一般に、FFに任意の数値を入力することは禁じられていませんが、適切な答えが得られるのは[-10.0;10.0]の 範囲だけで、範囲を超えると数値はその境界で切り捨てられます。あなたはこれを考慮に入れていない場合は、FFの値は常にFFの最小 値（任意の、しかし変更しないでください）を与えられるので、あなたのアルゴリズムは、彼が滑らかなgrizontalnuyu表面上に得たと思うことができ、延々と実数の巨大な次元でさまよう（彼のプロセスは、チェッカーを停止しませんまで）。

了解です。ありがとうございます。最初の4回の呼び出しは、それぞれ-10.0、0.0、10.0、2.7で満たされた配列で行う予定です。ゴキブリのために2.718にしたいのですが、ステップ0.1です。まあ......無理でしょうけど。
 
Dmitry Fedoseev:

では、行ってきます！静かなドミの世界で、ドミを貫いてください。私をパネルから外してください。

もちろん、ここにいる皆さんにはアーマーボールで説明しますよ。2番目のバージョンのスクリプトでは、FF()をインポートする必要はありません。なぜなら、参加者関数も そこにインポートされて いるので、FF()は参加者関数では表示されないからです。FF()関数は、メンバーライブラリにインポートする必要があります。そんなくだらないデタラメの例さえ、間違って紹介されている。わかってる、わかってる、クリアーって言うんでしょ。しかし、そんなにはっきりしているのなら、なぜ正しい例が示されていないのでしょうか？と、まるで私がバカであるかのような顔で。

バイバイ。

ディム、少なくとも輸出機能の動作確認は、表彰台から出場する前にしておくべきだったと思います。例えば私は、試作品を公開する前に、当然ながら動作確認をして います。そしてもちろん、それは機能します。つまり、カスタムライブラリは関数のそれ自身のインスタンスをロードしません。

MTの実行環境は、一般的に皆さんが思っているのとは違う動きをします。チェックスクリプトのアドレス空間には、1つのライブラリインスタンスと 1つの変数のみがロードされ、つまり、誰もが特定のパラメータを持つ1つの特定のffを使用することになります。もし信じないのなら、私の例をダウンロードして確認してください。

 
Vasiliy Sokolov:

Dimitriは、メンバーにも2つのアルゴリズムライブラリの選択肢があることに気づかなかっただけなのです。そして2つ目は、 FF機能インポート（本人談）。そして、1枚目はそうではない。

 
Vasiliy Sokolov:

ディム、せめて輸出機能の働きを確認してから、壇上で大見得を切るべきだったね。そうでなければ、「見ていないけど判断する」という 一連の流れから、例えば私は、試作品を発表する前に、もちろんその性能を チェックしました。そしてもちろん、それは機能します。つまり、カスタムライブラリは関数のそれ自身のインスタンスをロードしません。

MTの実行環境は、一般的に皆さんが思っているのとは違う動きをします。チェックスクリプトのアドレス空間には、1つのライブラリインスタンスと 1つの変数のみがロードされ、つまり、誰もが特定のパラメータを持つ1つの特定のffを使用することになります。もし信じないのなら、私の例をダウンロードして確認してください。

私はすでに二重インポートについて 1つの例を述べています（私の投稿が見つかりませんでした、ここにはたくさんの投稿があります）。そう、だからメンバーアルゴリズムでFFコールを制御することが可能なのです。もし、スクリプトとアルゴリズムがFFのすべてのインスタンスを呼び出すのであれば、チャンピオンシップは起こりません。

...

アルゴリズムで1回だけインポートすれば何とかなるかもしれませんが、*.ex5を実行してアンロードし、再度実行してカウンターをリセットする（賢い出題者プラン）ことはできないと思いますが、そうすると出題者が自分で全スタットを呼び出す必要があり、出題者が結果を出力するには他の可能性も考えなければならず、出題者にとってさらなる複雑さが生じます。FFを使用しているかどうか、必要な情報をすべて要求したほうが、スクリプト側は楽です。

しかし、それでも、いずれにせよ、私たちの場合の二重輸入は間違いとは言えません。

 

Andrey Dik:

これは知らなくてもいい。10.0;10.0]の範囲内であれば、問題はありません。


0.0は範囲[-10.0;10.0] に入るのでしょうか？- はい、そうです。つまり、0.0の値で埋め尽くされた配列から、パラメータでFFの値を求めることができるわけです。

実際、FFにどんな数字を入れてもいいというわけではありませんが、[-10.0;10.0] の範囲でしか適切な答えは得られませんし、範囲を超えると数字はその限界まで切り捨てられます。これを考慮しなければ、FFの値は常にFFの最小値 （任意の、しかし変化しない）を与えられるので、アルゴリズムは、彼が滑らかな緑の表面で得たと考えることができ、延々と実数の広大な広がりでさまよう（彼のプロセスはチェッカーを停止しないまで）。

境界のクリッピングに煩わされず、アルゴリズムを限定しないために、FFに1行追加することができます。

if(array[ArrayMaximum(array)]>10.0 || array[ArrayMinimum(array)]<-10.0) return(0.0);
 
Sergey Chalyshev:

クリッピングバウンドに悩まされず、アルゴリズムを限定しないために、FFに1行を追加することができます。

なぜreturn(0.0);?

というか、なぜ0.0なのか？

 
Andrey Dik:

なぜreturn(0.0);?

というか、なぜ0.0なのか？

もし、最大値だけを求めるのであれば、正解は

return(-DBL_MAX);
 
Sergey Chalyshev:

もし、最大値だけを求めるのであれば、正しい

ポイントは、設計段階では、不連続性を持つ「サーフェス」を得ることが可能で、ピークは無限大（下または上）になりますが、FFは出力時に正しい値を返すはずで、すべての境界条件はすでにFFに考慮されており、FFの障害によってクラッシュすることはないはずです。

ですから、あるパラメータが正しくないとわかっていて-DBL_MAXを出力するよりも、パラメータを許容範囲にカットして、そのパラメータでFFを計算し、得られたものを出力する方が良いと思います。

参加者はパラメータの制限を知り、それを守らなければなりません。そうでなければ、アルゴリズムの特定のケースで答えることが難しい多くの質問があります。そのままでは、すべてのアルゴリズムを同じ土俵に乗せてしまいます。

うーん......「設計の段階でどうなんだ！ 誰もFFのことを知らないって言ったじゃないか！」と突っ込まれそうですが......。このような質問をしようとする人は、まずこのスレッドを読んでください。

 
なぜ、レンジの数値は分数なのか？0.1刻みで-10.0から10にするのではなく、1刻みで-100から100にすることができます。
1...535455565758596061626364656667...132
新しいコメント