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

[Andrey Dik]

Alexander Laur:
私の意見としては、アルゴリズムのテスト時間も考慮したルールにすべきだと思います。二人であれば、アルゴリズムの試運転は数時間、数日で計測できます。さらに参加希望者が増えたら？競技審判の時間を無駄にしないようにお願いします。

FFの実行回数には制限があります。競技者の中には、試験時間の制限を設けないでほしいという声もあります。

[Andrey Dik]

Alexander Laur:
1. Еще один момент: Как Вы собираетесь проверять ПРАВДИВОСТЬ полученного результата 

2.結局のところ、最も重要な結果は、本当のグローバルな極限を見つけることなのです。また、それをどのように確認するのか？

1.結果の妥当性は、パラメータの値をFFに代入し、出題者の結果をFFの結果と比較するだけで確認できる。

2.本当の意味でのグローバルな結果は、3つの方法で得ることができます。

a) 厳密値：解析的に問題を解く (当社では受け入れ不可)

(b) 正確な値：総当たり（当社では実現不可能です。）

c) 近似値：最適化アルゴリズムを使用する - これが、最も高い結果を得ることになるのです。本当の最大値は私たちにはわからないまま（見つけることができない）、参加者の中で最も高い値がベストとなる。

[Реter Konow]

Andrey Dik:

1.最小限の制約を求めたが、これは可能な限り最小限のステップである。

2.問題が発生する可能性があるとすれば、それはFFではなく、出題者のアルゴリズムにあります。つまり、アルゴリズムに起因する重大な エラーが発生した場合は、競技者として失格となる。

1.最低限を求めたわけではありません。

私は、主催者が一方的に問題条件のパラメータを決めることに反対でした。なぜなら、その条件を既存のアルゴリズムに適合させる機会が（意図的であるかどうかにかかわらず）あると考えたからです。参加者の多くは最適化問題の解決経験がないため、このような意図は不当である。

私は、アルゴリズムが確立していない新参者と、長い間アルゴリズムを持っている参加者の可能性を少しでも均等にするために、範囲とステップを変更するようお願いしたのです。

2.数百のパラメータをランダムに代入した未知の関数における致命的なエラーは、参加者のアルゴリズムに関係なく、偶然に発生する可能性があります。

このようなエントリーが関数内部にあり、(2/(0.000000254345 - x1)); アルゴリズムが呼び出しの1つで誤ってパラメータx1に値0.000000254345を渡してしまったとします。

この場合、括弧の中には2で割り切れるゼロが含まれることになる。

この場合、重大なエラーが発生します。しかし、参加者の誰も、配列内の他の数字とともにFFに送られたランダムに生成された数字が、ある定数と等しくなく、そこから引かれたり、何かで割られたりしていないことを知ることはできない......。

[Andrey Dik]

Реter Konow:

1.最低限を求めたわけではありません。

私は、問題条件のパラメータを主催者が一方的に決定することに反対でした。なぜなら、（意図的であろうとなかろうと）この条件をすでに存在するアルゴリズムに合わせる機会があると考えたからです。参加者の多くは最適化問題の解決経験がないため、このような意図は不当である。

私は、少なくとも、既成のアルゴリズムを持っていない新規参入者と、長く持っている参加者の可能性を少しでも平準化するために、レンジとピッチを変えるようお願いしたのです。

2.数百のパラメータをランダムに代入した未知の関数における致命的なエラーは、参加者のアルゴリズムに関係なく、偶然に発生する可能性があります。

このようなエントリーが関数内部にあり、(2/(0.000000254345 - x1)); アルゴリズムが呼び出しの1つで誤ってパラメータx1に値0.000000254345を渡してしまったとします。

この場合、括弧の中には0が含まれ、この0によってdoubleは割り切れることになる。

この場合、重大なエラーが発生します。しかし、配列内の他の数字とともにFFに渡されたランダムに生成された数字が、ある定数と等しくなく、そこから引かれたり、何かで割られたりしていないことは、参加者の誰も知ることができない......。

1.率直に言って、0.000000000001ステップを使う覚悟はないのですか？難易度は高いですか？準備が整えば、質問は削除されます。

2.先ほど、FF内部の数学的な演算は気にしなくていいと言いましたが、そこでは頑張ってもエラーは起きないかもしれません。端末のログを見れば、どこでエラーが起きているかが一目瞭然なので、アルゴリズムにエラーがないように気をつけた方がよいでしょう。

また、FFに含めるためのf(x1, x2)の形のサンプル関数の提供を拒否しているため、あなたからのFFの特性に関するいかなる要求も正当なものではありません。他の人がすでに解決し、あなたのために用意したものに満足することです。数時間後には、FFの内部を最後に見ることができますが、FFの内部を考えても、コンテストでのチャンスが増えるわけではないことだけは理解しておいてください。ブラックボックス、それだけを考えて、あとは非現実的で、そもそも実現不可能なことです。

[Реter Konow]

Andrey Dik:

1.率直に言って、0.000000000001ステップを使う覚悟はないのでしょうか？複雑すぎるのでは？準備ができているならば、この質問は外れています。

2.先ほど、FF内部の数学的な演算は気にしなくていいと言いましたが、そこでは頑張ってもエラーは起きないかもしれません。端末のログを見れば、どこでエラーが起きているかが一目瞭然なので、アルゴリズムにエラーがないように気をつけた方がよいでしょう。

また、FFに含めるためのf(x1, x2)の形のサンプル関数の提供を拒否しているため、あなたからのFFの特性に関するいかなる要求も正当なものではありません。他の人がすでに解決し、あなたのために用意したものに満足することです。数時間後には、FFの内部を最後に見ることができますが、FFの内部を考えても、コンテストでのチャンスが増えるわけではないことだけは理解しておいてください。ブラックボックス、それだけを考えて、あとは非現実的で、そもそも実現不可能なことです。

熱くなってはいけない。私たちは、あなたがここに書いたポイント2に従って議論し、同意しているだけです： https://www.mql5.com/ru/forum/87536/page92#comment_2652859

1.私は、あなたが使うであろう条件を使う用意もありますが、あなたが提案する条件が、出題者のアルゴリズムとは無関係にエラーを引き起こすかどうかを検討することをお勧めします。

2.解析関数のブロックの一部（すなわち定数やパラメータを用いた数学的作用）を知っていると、参加者に悪用される可能性があります。

例：関数 (2 / (2 - x1)) をコンパイルして渡しましたが......。FFに収録したんですね。

するとレフェリーは、あなたの提案で、関数ブロックを単純にシャッフルし、そのブロックに定数や演算を残したまま......」と。

さらに、アルゴリズムをコンパイルする際、x1パラメータに数値2を渡すと、ゼロによる重大な除算エラーになることがわかる。しかし、他の参加者はこのことを知らないので、このパラメータに2の値を渡すことができる。

その結果、彼のアルゴリズムは失格となる。

このようなニュアンスで捉えてみてはいかがでしょうか。

定数が範囲 [2 , -2] の外にある場合、関数内部ではどのような演算もゼロにならない。

追伸：もちろん、この場合もゼロになる可能性はありますが、確率的には低いです。FFから除算演算を除外することもできますが、やりすぎでしょう...))

[Реter Konow]

Alexander Laur:

悪気はないんです、あくまで私の意見です。:)

そしてご意見は、ご回答の「c」の点が当て字になっているということです。確実な結果が分からないので、推測の域を出ないのです。結果が不明な場合、アルゴリズムのOPTIMALITYはどのように判断するのでしょうか？

検索アルゴリズムのOPTIMALITYを評価するのであれば、網羅的検索によって得られたKnown Resultsに対して行うべきでしょう。しかし、選手権の課題では、この既知の結果を100分の1のステップ数で得なければならないと指定する。それは、真の結果を得るために、より少ない手順で、既知の結果を得る競争である。この方法であれば、誰も勝敗に迷うことはないだろう。

私も同感です。

関数の最大値は、レフェリーが確実に知っているべきものだと思うのです。

そうでなければ、コンテストは茶番劇になってしまいます。

また、出場者のアルゴリズムの有効性を評価する基準として、FFコールの回数と並んで重要なのが精度で、これは信頼できるマスク関数の値がないと判断できない。

[Andrey Dik]

Реter Konow:

熱くなってはいけない。私たちは、あなたがここで綴ったポイント2に従って議論し、同意しているだけです。https://www.mql5.com/ru/forum/87536/page92#comment_2652859。

1.私は、あなたが使うであろうどんな条件でも使う用意がありますが、あなたが提案する条件が、出題者のアルゴリズムとは無関係にエラーを引き起こすかどうかを考えてみてはどうでしょうか。

2.解析関数のブロックの一部（すなわち定数やパラメータを用いた数学的作用）を知っていると、参加者に悪用される可能性があります。

例：関数 (2 / (2 - x1)) をコンパイルして渡しましたが......。FFに収録したんですね。

するとレフェリーは、あなたの提案で、関数ブロックを単純にシャッフルし、そのブロックに定数や演算を残したまま......」と。

さらに、アルゴリズムをコンパイルする際、x1パラメータに数値2を渡すと、ゼロによる重大な除算エラーになることがわかる。しかし、他の参加者はこのことを知らないので、このパラメータに値2を渡すことができる。

その結果、彼のアルゴリズムは失格となる。

このニュアンスで考えてみてはいかがでしょうか。

定数が範囲 [2 , -2] の外にある場合、関数内部ではどのような演算もゼロにならない。

中でも、ソースのFFは何のために表示されると思いますか？FFに数学的演算などの誤差が生じないようにすること。FFにエラーが発生した場合、理論的には起こりうることですが、FFのソースコードを見ることで、その脆弱性を利用して、FFに重大なエラーを発生させることができます。もしそうなったら、それはFFの制作者の責任であり、私は唯一の制作者ですから、責任はすべて私にあり、私が敗者であなたが勝者ということになるのです。この方法で勝者になるチャンスはある、というか--この方法で勝者になるチャンスはないのだ。

[Реter Konow]

Andrey Dik:
中でも、初代FFは何のために上映されるのだと思いますか？数学的演算などのミスでFFにエラーが発生することがあり得ないことを確認すること。FFにエラーが発生した場合、理論的には起こりうることですが、FFのソースコードを見ることで、その脆弱性を利用して、FFに重大なエラーを発生させることができます。もしそうなったら、それはFFの制作者の責任であり、私は唯一の制作者ですから、責任はすべて私にあり、私が敗者であなたが勝者ということになるのです。この方法で勝者になるチャンスはある、というか--ない。

オリジナルのFFを見たら、今よりもっといろいろなことが明確になると思うのですが......。

FFのドラフトのミスの可能性を利用するのは、偽りの勝利を目指すという私の参加動機の根拠を無効にするものであり、全くもっていただけないのです。

勝利は、曖昧さのない、信頼できる、公正なものでなければなりません。他は必要ない。

[Andrey Dik]

Alexander Laur:

悪気はないんです、あくまで私の意見です。:)

そしてご意見は、ご回答の「c」の点が当て字になっているということです。確実な結果が分からないので、推測の域を出ないのです。結果が不明な場合、アルゴリズムのOPTIMALITYはどのように判断するのでしょうか？

検索アルゴリズムのOPTIMALITYを評価するのであれば、網羅的検索によって得られたKnown Resultsに対して行うべきでしょう。しかし、選手権の課題では、この既知の結果を100分の1のステップ数で得なければならないと指定する。それは、真の結果を得るために、より少ない手順で、既知の結果を得る競争である。このやり方なら、誰も勝敗に迷うことはないでしょう。

レグ・コノウ

私も同感です。

関数の最大値は、レフェリーが確実に知っている必要があると思うのです。

そうでなければ、コンテストは茶番劇になってしまいます。

また、出場者のアルゴリズムの効率性を評価する基準として、FFコールの回数と並んで重要なのが精度で、これは信頼できるマスク関数の値がないと判断できない。

二人とも面白いなぁ...。) 悪気はないのですが ))))

もし、地球規模の最大値が例外なくすべての人に知られるようになったら、もう一度、よく考えてみてください、どうなるでしょうか。このような場合、最適化アルゴリズム選手権は全く開催されないのでしょうか？もちろん、そんなことはできません。どんな競技者でも、許容される最大値の60〜70パーセントでFFをぼんやり呼び出し、100パーセントの精度で結果を出すことができるからですUNLIMITED FFでしか勝負できない!競合他社の1社の最大値が最良の 結果となる。

本当に笑わせてくれる...。)))

しかし、もしあなたが真剣で、アルゴリズムが最大値を見つけるのにどれほど正確か本当に知りたいのなら、競技会の外で、既知の最大値をアルゴリズムに与えることができます。アルゴリズムが公開された後に与えるために、誰もそれをすることを禁止していません。参加者のアルゴリズムは数日間自由に利用でき、誰もが好きなだけアルゴリズムをチェックしテストすることができます。その時までに、少なくともいくつかの既知の最大値を持つ関数をすでに持っていて、参加者の誰かのアルゴリズムの特性を自分で確認し、見つけてほしいと思います。

[Andrey Dik]

Реter Konow:

オリジナルのFFを見たら、今よりもっといろいろなことが明確になると思うのですが......。

FFのドラフトのミスの可能性を利用するのは、偽りの勝利を目指すという私の参加動機の根拠を無効にするものであり、全くもっていただけないのですが、いかがでしょうか。

勝つためには、曖昧さがなく、信頼性が高く、誠実でなければならない。他は必要ない。

アルゴリズムがまだできていないということでしょうか。既知のFFを理解し、アルゴリズムを準備するために、どれくらいの時間が必要でしょうか？FFの中身にどんな違いがあるのでしょうか？アルゴリズムは未知のFFに対応できるものでなければ、でたらめであり、アルゴリズムとは言えません。