コンピューター将棋が強くなりすぎた結果、相手が人間(アマチュア)の場合は、手加減しないと勝負にならなくなってきました。
従来、探索深さを浅くしたり(depth limit)、探索ノード数を制限したり(nodes limit)、思考時間を制限したり(time limit)することによって弱さを実現してきましたが、それだと自然な弱さにはなりませんでした。(序盤がすごく弱いのに終盤だけが相対的に強いというような…)
コンピューター将棋が強くなりすぎた結果、相手が人間(アマチュア)の場合は、手加減しないと勝負にならなくなってきました。
従来、探索深さを浅くしたり(depth limit)、探索ノード数を制限したり(nodes limit)、思考時間を制限したり(time limit)することによって弱さを実現してきましたが、それだと自然な弱さにはなりませんでした。(序盤がすごく弱いのに終盤だけが相対的に強いというような…)
「ブラウザ版やねうら王について」に書いた通り、ブラウザ版のやねうら王を作ることに決まったのですが、このやねうら王公式サイトにぶら下げるとアクセスを捌き切れない可能性があるので専用のサイトを作ろうと思います。 しかし、私がサイト名を考えると『裏王倶楽部24』とか『裏王ウォーズ』とかになって、どこかの会社から怒られかねないので、サイト名を今日のコメント欄もしくはツイッターにて募集します。
今回は思考時間制御部(time manager)です。現局面での次の1手に使うべき時間を計算します。
maximum search time = 今回の指し手で使える最大思考時間。fail high/fail lowした場合など、この最大時間までは使うものとします。(残りの手数に応じて時間をある程度残しておかないといけないので、この値は残り持ち時間のすべてではありません。)
optimum search time = 今回の指し手で使える平常時の目安時間。
unstable PV Extra Time = 反復深化のiterationを深くしていくときにPV(最善応手列)が変化したときは評価値が不安定な局面だということで与えられる追加の思考時間。
電王戦リベンジマッチ、「森下9段 vs ツツカナ」は、私の発言が引き金となって、この企画が実現したという経緯もあって、ハラハラしながら見ています。現在、深夜の3時15分。森下先生が大優勢ながら、ツツカナの入玉がありそうで終局までにはまだ時間がかかりそうです。本局は、ヒューマンエラーさえなければ人間はコンピューター将棋とまだまだ戦えるということを知らしめたことに大きな意義があったと思います。年越しにこんな素晴らしい対局を見れたことで、今年一年はいい年になりそうです。
お返しというわけではありませんが、私のほうから皆さんにお年玉があります。
ブラウザ版やねうら王の公開についてです。
応援していただける方は、下のツイートをRTしてください。
このツイートが1000RTされたらブラウザ版やねうら王を作ります。強さは10級〜10段から選択可。ブラウザでログインせず無料で遊べる将棋ソフトとして世界最強!公開日は2015年3月下旬。 応援していただける方は、このツイートをRT! http://t.co/KNcKkSskvP
— やねうらお (@yaneuraoh) December 31, 2014
【追記】
・夜中の3時17分なのにツイートしてわずか5分で100RT突破!!これは、本当に1000RT行きそう!?
・ツイートして16分経過で200RT。48分経過で300RT。
・ツイートして9時間足らずで1000RT達成しました!!たくさんの方に応援していただけて本当に嬉しいです!!
今回はStockfishのbitcount.hです。これは、2進数的に見て1になっているbitの数を数えるというものです。いわゆるpopcountですね。SSE4.1以降であればx86/x64ではpopcnt命令が使えますので簡単なのですが、そうではない環境ではビット演算のテクニックを用いて求めることになります。
Stockfishのbitboardは、チェスなので盤面が8×8 = 64升であり、64bit変数に収まります。(将棋の場合、81升なので128bit変数もしくは、64bit変数が2つ必要になります。)
あと、magic bitboardと言う仕組みが使われています。これは斜めに利く駒の利きのbitboardに対して掛け算を使って連続するビットに移動させるテクニックです。→ Magic Bitboard – Chess Programming Wiki
Haswell以降であればBMIを使うべきでしょう。→ BMI使ってますか?
定跡の生成のため探索をして評価値が一定以上悪くなる指し手は定跡DBには登録しないだとか、探索して棋譜の指し手の評価値を定跡DBに記録しておき、ベストの評価値とかけ離れた評価値の指し手は採用しないだとかして定跡DBを作っていたのですが、少し興味深い現象があったので書いておきます。