df-pn ムズい…

あれから解けない問題のログを見ながら、原因推測⇒ソース変更⇒検証で解けない問題が少なくなってきたんだけど、ちょっと手を入れると解けていた問題も解けなくなったりする。
山下さんのところの No.2 の詰将棋も解けていたのに、いつの間にか解けなくなっているし。

せめて15手以内は時間をかければ解けるという状態にしないとなぁ～。

あと、最大深さを 1535 にして走らせたら、深さ 500 超えたあたりで Stack Overflow が発生した。orz
最近の OS だったら、自動的にスタックサイズを拡張してくれるんじゃなかったのか?!
自前でスタックを実装しないといかんかな…。

まぁ、実戦ではそこまで読まないし、今後のマルチスレッド化でスレッド生成時にスタックサイズを十分大きく指定してやれば問題ないかな。

Phenom

Phenom に対応したチップセットというと現時点で AMD 7シリーズということになるが、これだとビデオカードは別途買わないといかんね。
持ち運びに便利なように MicroATX のスリムケース、となるとロープロファイルのビデオカードが必要になるし電源的にもかなり厳しいか。

Phenom を AMD 7シリーズで動かしたときと、AMD690G で動かしたときのベンチがあればいいんだけど。
どうせ必要なのは演算速度とメモリ容量とメモリ帯域で、描画関係は普通に映ればいいし。

df-pn がなんとなく動いてきた

今まで動かなかったのは、探索途中で証明数/反証数が無限になったときの閾値の更新がうまくなかったのと、優越関係のハッシュサーチがれさぴょんのままで、ハッシュが一致しても結果が詰みでないときは NULL を返す実装になっていたからのようだ。

とりあえず、優越関係は実装せず、厳密に一致で判断するようにしてみた。
以前の日記で書いた詰め12は19175nodes読んで0.25秒、詰め15は687nodes読んで0.01秒で解いた！！
とはいうものの、合駒が関係するものは解けない(or すごい時間がかかる)みたい。

優越関係を正しく実装すれば、他のプログラムに「ルートでの詰み探索」は追いつくかっ？！

うーん、微妙？

なんとか進歩本２の共謀数の詰めルーチンが動くようになったか？
というわけで、11月13日の詰め問題をやらせてみた。

詰め12は2671091nodes読んで14.75秒、詰め15は2465nodes読んで0.01秒で解いた！！
反復深化で解けるのに共謀数では解けなかったり、遅かったりするけど、ハマると速い！！

ちょっとこの遅さはどこかにバグがありそうだけど・・・。

あと2ヶ月！

コンピュータ将棋選手権の参加申し込みが1月末で2月になったらすぐにオープン戦・・・。

うーん。
思ったように開発が進まず、共謀数の詰将棋ルーチンがうまく動かない。
局面によってはすぐに答が返ってくるんだけど、局面によっては解けなかったり間違った答が返ってきたり。
来月はαβと評価関数をやるつもりだったんだけど、詰将棋ルーチンを少し延長するか・・・。