pass 0 returned result 100000.000000in0:00:35.296
pass 1 returned result 100000.000000in0:00:29.361
pass 2 returned result 100000.000000in0:00:24.549
pass 3 returned result 100000.000000in0:00:25.067
pass 4 returned result 100000.000000in0:00:24.578
pass 5 returned result 100000.000000in0:00:24.634
pass 6 returned result 100000.000000in0:00:25.079
optimization finished, total passes 7
optimization done in3 minutes 09 seconds
shortest pass 0:00:24.549, longest pass 0:00:35.296, average pass 0:00:26.937
正規化しない場合。
pass 0 returned result 100000.000000in0:00:33.035
pass 1 returned result 100000.000000in0:00:26.020
pass 2 returned result 100000.000000in0:00:20.137
pass 3 returned result 100000.000000in0:00:20.859
pass 4 returned result 100000.000000in0:00:21.130
pass 5 returned result 100000.000000in0:00:20.664
pass 6 returned result 100000.000000in0:00:21.001
optimization finished, total passes 7
optimization done in2 minutes 50 seconds
shortest pass 0:00:20.137, longest pass 0:00:33.035, average pass 0:00:23.263
間隔を長くすればいいのでは？テストは30秒以上。
正規化で。
正規化しない場合。
同じ20％です。
このように、あるAgentは一貫して同じものをカウントしているのです。ランダム性をすべて取り除けば、正味の性能は最短に近くなる。
ネットは現実には実現できないので、おもしろくない。
テストありがとうございました。
正規化で。
正規化せず。
同じく20％。
何もしないダミーEAに20％って・・・。実際のコードでは、この数値は何倍にもなるはずです。 このようなつまらないことに時間を費やす価値があるのでしょうか。
また、計算の最適 化といえば、すべての未決済注文のレベルを常に監視する必要がないことから始めるべきでしょう。一番近いものだけをチェックすればいいのです。到達すれば、次のレベルというように。
何もしないダミーEAに20％って・・・。実際のコードでは、この数字は何倍にもなるはずです。 このようなトリビアに時間を費やす価値があるのでしょうか。
観察眼は公正である。私の通常のロボットでは、Testerのラグが大きすぎます。その理由はさまざまです。そして、これもその一つです。1パスが1億ティック。10Kパスの標準的なジェネレーターを例に挙げてみましょう。最低でも1兆チックですからね。テスターは1目盛りごとに、少なくとも1回の正規化を行います。全くできないのに。そのような最適化で節約できることはありますか？しかも、わざわざ比較するのは、今のようにいちいち正規化することになる。実際には、流入する価格だけを正規化する方が簡単で効率的です。
また、計算の最適 化といえば、すべての未決済注文のレベルを常に監視する必要がないことから始めなければなりません。一番近いものだけをチェックすればいいのです。到達していれば、次のレベルを確認する、といった具合です。
注文 数が増えると内蔵テスターの遅れが大きく なる。グリッドTSはその「殺し屋」である。そんなアルゴリズムの最適化を提案 しました。引き受けることはないと思います。
ここでは、テスターの1刻みに伴う大量の内部計算を論じているのではない。