前回の続きです。

前回の超絶テクニック(ただし全体的な速度は0.5%すら速くならない)には平岡さんも感心されているご様子。

なるほどなぁ、二歩判定そんな方法があったのかぁ。

— 平岡 拓也@Ponanza倒したい (@HiraokaTakuya) October 15, 2015

縦型ビットボードは、成れる手だけを生成するときにも両方の64bit変数見ないといけないのが損ではある。 でも最近成れる手だけ生成するのやめたから良いかって感じ。

— 平岡 拓也@Ponanza倒したい (@HiraokaTakuya) October 15, 2015

あと、次のような意見(質問？)があります。

二歩対応って、歩を打てる場所のBitboard（歩を打ったとき・成ったとき・取ったときに更新する）を持っておくというのはメジャーじゃないんですか？

— merom686 (@merom686) October 15, 2015

do_move(指し手で盤面を進める)/undo_move(盤面を戻す)のときに更新するということですね。

面白いアイデアですが、反復深化においては、4割ぐらいは置換表の指し手がベストとなって、killer movesやcaptures(捕獲する指し手)も含めればおそらく6,7割ぐらいがそれらの指し手となって、それらの局面ではそれ以上指し手の生成をしないまま探索が進んでいくことが多いので、do_move/undo_moveに二歩のための処理のコストが乗ってくるのは少し嫌ですね。

その処理(歩が打てる升を示すBitboardを生成する)が必要になるのは歩を持っていて、かつ、駒打ちの指し手まで生成するときのみなので、node数の2割ぐらいの回数しかないのではないかと…。

縦型Bitboardの弱点その2

縦型Bitboardの弱点としてもうひとつ書いておくことがあるのを忘れていたのでここに書いておきます。

縦型Bitobardにしたとき、fe_end(Bonanzaのevaluateで用いる、KPPのPのとりうる値の最大値 – 1)の値が変わってきます。要するにKPPテーブルが少し大きくなります。

これは、BonanzaではこのPのとりうる値として、歩・香の存在できない段(先手なら1段目、後手なら9段目)、桂の存在できない段は、値を詰めてあるのですが、縦型Bitboardですとここを詰めるのはちょっと難しく、値を詰めないのが普通です。

つまり、Bonanzaだとfe_endは1476だったと思いますが、Aperyだと1548になります。(たぶん)

「テーブルが少しぐらい大きくなっても関係ないのでは？」という声が聞こえてきそうですが、今後、メモリが高速になってくると評価関数はKPPではなくKPPPなどに移り変わっていくかも知れません。このKPPPですが、必要メモリは、

Bonanzaのfe_endのときのKPPP
= 45×1476×1476×1476 / 3! × 2bytes = 48.23GB
※　45というのは、ミラーを考慮して盤面の片側。1～5筋×9段 = 45升の意味。

Aperyのfe_endのときのKPPP
= 45×1548×1548×1548 /3!  × 2bytes = 55.64GB

となり、Aperyのほうは、64GB搭載のPCだと少し苦しい感じがしなくもありません。

まあ、メモリが速くなって、KPPP型がKPP型より優位性があるようになるころには、PCのメモリは1TB以上が標準となっているかも知れませんが…。

評価関数の話が少し出てきたところで、次回からは評価関数のあれこれを語っていきます。お楽しみに！