うらお電王トーナメントの開催日も迫る中、やねうら王のMovePickerにバグが発見されました。18以上でないと関係して来ません。18以上の対局でこのわずかな変更で有意差が出るぐらい対局を回すのはいまからでは間に合いません。Stockfishを信じて修正しておくしかないです。うら王の修正前のコードでは、v(bonus)が-324以下のときもbonusを加点(減点?)していたことになります。そもそも、vの絶対値が324以上なら何故bonusを加点しなくて良いのでしょうか?depthが深いときのオーダリングがdepthが浅いときのオーダリングにいい影響がないからなのだと思いますが、このへん、本来なら将棋に合わせてチューニングすべきです。このif文自体、無いほうが強くなる可能性があります。値が大きくなりすぎると悪影響があるということなら、絶対値が324を超えていれば絶対値が324になるように足切りすればいいわけで...。本当に絶対値が324以上なら加点しないという処理なら、この呼び出し元(forループで回しているところがある)で、そのチェックをすれば、諸々の処理を端折れます。して見るとこのStockfishのコードは、ちょっとおかしいのではないかと思うのですが。:本文を読む限りにおいては必要性を感じないですね。勝負に影響が最も出る中盤でもdepth18↑は2秒。探索に負担がかかってくる終盤でもdepth18↑は5秒。強くなるかどうかは検証が必要でしょうが、このコード関係が無いほうが到達depthは圧倒的に早くなりそうです。:このバグ(?)を修正するとdepth(残り探索深さ)が18以上のときの挙動に違いが出るので、例えば、中盤で2秒でdepth18まで到達するとしたら、2秒目以降の思考に影響が出ます。́ω`)そのへんの検証は電王トーナメント終わってからですなー。具体的には終盤付近で、バグ有り=depth24=1億ノードバグ修正=depth24=3億ノードとかになります。発生頻度は極めて少なく、四間飛車VS居飛車穴熊が千日手くさい状況で飛車角がチョロチョロ動き出すときとかに影響があるくらいです。他には指し手が飽和して29飛車と引いておくとかの場合は、普通に良い手なのでバグのままでも問題なかったりします。評価関数が限界付近に到達してきている昨今、指し手探索結果が同じようなソフト同士だと変な話、バグったままで到達depthが早いほうが全体勝率が良かったりします。うら王さんクラスの一流プログラマーだと、バグは絶対に許せない気質かもしれませんが、こんなこともあるということで。:本文の内容が正しく伝わっていないのだと思うのですが、それを説明するにはこのコメント欄は狭すぎる。将棋所の表示上の「深さ」)のことなのですが、この説明を詳しく書く時間がなさげです。余計な追加コメントをしたみたいで。本文のバグと追加コメントのバグが全然違うのは理解しています。同じバグという括りで違う例を書いただけでした。本文中のコードが今までの場合、浅い探索で影響が出るので、評価関数の学習が上手くいってなかった可能性等があったぽい感じですよね?その他、余計な仕事をしているので探索が遅くなっていたりしていたかもしれない、みたいな感じかなと捉えています。本文中のコードが今までの場合、浅い探索で影響が出るので逆です。18以上のとき(将棋所で見て探索深さが19以上ぐらいから)影響が出ます。0で学習していますので、影響はないです。いうか、この本文のバグ修正してもR2変わるかどうかレベルだとは思います。そもそも修正したほうが強くなるかどうかすら悩ましいレベルで...。́ω`)まあ、そういうR1とか2を積み重ねていくのが現代の将棋ソフトなわけですね。うら王の修正前のコードでは、v(bonus)が-324以下のときもbonusを加点(減点?)していたことになります。depth18以下のときかと思いました。したら思い当たる挙動としては、やねうら王とSMを見比べると、スレッド1とかゆっくりとした探索で対局している設定で、終盤探索がきつくなってくる所で毎手depth16~20とかの設定秒数なのに、これが絶対手だと言わんばかりに突然depth23とか行くときがあります。設定秒数なのに、これが絶対手だと言わんばかりに突然depth23とか行くときがあります。それはLazySMPの影響ですね。本文の処理部分は、そのnode(局面)で良かった/悪かった指し手に対してhistoryにbonusを加点/減点する部分なのでオーダリング(指し手の並び替え)に影響があるのですが、将棋所上で見えてくる部分ではないと思います。指し手/読み筋にもほとんど影響ないと思いますし。本文の処理部分は理解できました。上記はスレッド1対局でして、LazySMPの影響では無いと思いますので、変な挙動が確認されればまた報告したいと思います。:簡単のためStatsのupdate()のコードが下記だけだったとして仮に同じbonusが続いた場合のstatsの値を計算してみました。・bonus=648(=324*2)が続く場合0→20736→0→20736→0→...・bonus=1000が続く場合0→32000→-34765→104535→-186104→...→発散bonusが324以下の場合は単調増加で、しばらくすると10368(=324*32)に収束するのですが、bonusが324を超えると単調増加ではなくなり、bonusが1000などになると、激しく振動して発散してしまいました。bonusの絶対値が324を超えると、加点しているつもりが減点されてしまったりするのでif文でreturnしたり絶対値324で足切りしたりしているのかと思います。(あと、statsの値を-10368~10368の範囲に収めたいという意図もあるのかもしれません。)CounterMoveStatsの場合は324のところが936になるので収束する値が29952(=936*32)になり、bonusの絶対値が936を超えると増減がおかしくなる場合が出てくるようです。:はい、そこはEMA(指数移動平均)みたいなことしてあるので、returnしないなら324で足切りするべきでしょうね。おっしゃる通り、最悪の場合、発散します。コメントをキャンセルメールアドレスが公開されることはありません。*サイト次回のコメントで使用するためブラウザーに自分の名前、メールアドレス、サイトを保存する。