1手詰判定関数の拡張

閃いたので、1手詰判定関数から手を進めて戻す処理をなくしました！
これで、テストケース100万回ループの平均が196msから140msに高速化されました！！
(テストケースは1手・3手・5手詰なので偏っていますが)
テストケースの中でのワーストは680msなので、毎秒147万局面ですね。
2005年の金子さんらの資料だと「2GHzのCPUならば毎秒200万局面近く」とあり、今回の計測は2.6GHzのCPU使っているのでやや遅い？

で、調子に乗ってピンも考慮するようにしてみたところ、1.5倍ほど遅くなった上に次の局面で「４一龍で３一馬がピンされているので３二龍で詰み」と誤判断してしまいました。
うーん、これは難しそう。
オリンピアード用には1手詰判定関数からピンの考慮を除くか…。



※宣伝：
職場や事務所などでコピー機、複合機、レーザープリンタ等を使われていて、そろそろリース更新や買い替えを検討されている方がいらっしゃいましたら一報をお願いします。私が製品開発にかかわった複合機などの紹介をさせてください(営業担当が伺います)。
よろしくお願いします。

コンピュータオリンピアードまであと1ヶ月？！

ヤバイ！
実質的な改良はまだ何もしていなくて、今、1手詰め判定関数のデバッグ中です。

とりあえずいろいろな問題でルーチンを動かしたところ、テーブルの設定ミスや移動可能の判断、相手から王手している駒を取られて詰まないなどのバグが見つかり、見つけたバグは全部対策したはず！
まぁ、まだまだ残っていると思いますが…。

あと、王手がかかっているときはコールしないというのが普通みたいですが、一応対応しました。
王手をかけている駒が1つの場合は、その駒を取って王手になり詰むか確認し、両王手の場合は詰まないと返します。

100万回のループで、候補手がないときは90～150ms、駒を打って詰むときは100ms～150ms、駒を動かして詰むときは400～1500ms程度かかるようです。

これで3手詰めにすると数秒～十数秒になってくるので、静止探索から呼ぶにはちょっと重すぎと思われます。

Bonanzaの1手詰めや3手詰めはどのくらいの時間で実行できているんでしょうね？

※宣伝：
職場や事務所などでコピー機、複合機、レーザープリンタ等を使われていて、そろそろリース更新や買い替えを検討されている方がいらっしゃいましたら一報をお願いします。私が製品開発にかかわった複合機などの紹介をさせてください(営業担当が伺います)。
よろしくお願いします。

1手詰め判定関数ができた？

だいたい出来ました！

割り切ったのは、
・王手は玉の近傍に限定し、離れた位置からの王手はチェックしない。
・ピンは考慮しない(本当は詰むのに詰まないと判断する)。
かな。

局面を更新しないで玉の近傍への駒打ちによる詰み判定はできました。
玉の近傍への移動による詰み判定は、難しかったので局面を更新して詰むかどうか判断しています。

これでも、100万回のループで1秒切っている(たいてい250ms以下)ので、それなりのスピードは達成できているんじゃないかと思います。
ループでコールしているので、キャッシュのヒット率が異様に上がっているだけかもしれませんが。

あとはこれを
・3手詰めに拡張
・静止探索に組み込む
・証明数/反証数の予測を追加して、詰ルーチンに組み込む
としていきたいですね。

※宣伝：
職場や事務所などでコピー機、複合機、レーザープリンタ等を使われていて、そろそろリース更新や買い替えを検討されている方がいらっしゃいましたら一報をお願いします。私が製品開発にかかわった複合機などの紹介をさせてください(営業担当が伺います)。
よろしくお願いします。

1手詰判定関数の作成中

静止探索の中から詰ルーチンを呼んでいなかったので、最近は局面を更新しない1手詰ルーチンの実装をしています。
まずは、駒打ちによる1手詰に取り組んでいますが、テーブルの設定ミスとかで打っても詰まない所に打ったりしていました。
まだ、ピンにより詰むケースや進歩本2にある自分の利きを遮って詰まないケース対応できていません。
なかなか難しくてちょっと途方に暮れています。

ついでに自作のテスト問題集を乗せておきます。

駒打による1手詰の判定テスト集(TestMate1ply.zip; 21KB)

※宣伝：
職場や事務所などでコピー機、複合機、レーザープリンタ等を使われていて、そろそろリース更新や買い替えを検討されている方がいらっしゃいましたら一報をお願いします。私が製品開発にかかわった複合機などの紹介をさせてください(営業担当が伺います)。
よろしくお願いします。

シャンチーのルール確認

コンピュータオリンピアードに向けてシャンチーの見込みを考えています。
まずはWikipediaでルールを確認していて、盤のサイズの理解でもうつまずいたｗ

縦横9本と書いてあるのに、盤はどう見てもそうは見えないので河は太い一本なんだろうか、と思ったら縦方向には10段あるというのが正解のように思える。
こんな基本的なところで違っているWikipediaを信用していいのか、ちょっと不安が残りますが…。

炮・砲の利きがトリッキーなので利きの更新でちょっと苦労しそうかな。
利きは常に持っていないで必要なときに計算するようにしたほうがいいかもしれない。

成る駒はなく、河を渡ったときに兵・卒が少し強くなる。くらい。
盤のサイズは9×10なのと兵・卒の動きから、64bit×2 の bitboard にして、河の上と下で分けようか…。

といった感じで、どういうデータ構造にしたらいいかという感じで考慮中。

ところでボナメソ適用のための良質な大量の棋譜って入手可能なのかな??

※宣伝：
職場や事務所などでコピー機、複合機、レーザープリンタ等を使われていて、そろそろリース更新や買い替えを検討されている方がいらっしゃいましたら一報をお願いします。私が製品開発にかかわった複合機などの紹介をさせてください(営業担当が伺います)。
よろしくお願いします。