定跡処理の変更

まだ、大元に入れ込んでいないけど、ハッシュだと衝突があるのでハフマン符号化で実装してみました。
局面情報をハフマン符号化で256bitに変換して、それをキーにSTLのmapで実装してみたけど、1手当たり1msもかからず引けるようです。

4万局の棋譜かられさぴょん形式で定跡を作ると約20MBになりますが、1レコードキー32バイト＋データ32バイトにしたので、250MB程度になりました。

棋譜の60手以降をデータから除外すると100MB弱。

これくらいなら512MBの XP マシンで動くかな…。

つーか、こんな外堀ばかり埋めていないで本丸を攻めねばっ。
あと2週間切ってるし…。

かなりピンチッ

連続対局ができるようになったので、ちょっと10連戦してみましたが、
・対 LesserKai 7勝3敗
・対 ssp 10連敗  
とかわいそうな強さです。。。

指し手のソート(れさぴょんでいうとKyokumenKomagumi::EvaluateTe()とその子関数)で70%以上の時間を使っているみたいで、指し手の逐次生成に変更してソートしないようにしたほうがいいのかなぁ～。
あるいは仮評価用に軽い評価関数を作るか。
いずれにしてもいまさら大幅変更はできないし、残り時間も限られているので、手っ取り早くできてそこそこ効果のあることをどんどん投入していかないと。

詰みがある局面で投了

図は▲５四飛から詰むみたいですが、なんと、ここで投了？！
ハッシュに詰みが入っているのに手が入っていないようです。
実はこの2手前から詰んでいるので、詰み探索の途中で手を登録していないのかな??

れさぴょんの定跡ルーチン処理時間

処理時間はデータ量に比例するO(n)となっていることを実測で確認。
測定マシンは Phenom II X4(3.0GHz)でソフトはシングルスレッド。
4000～40000局登録した定跡データについての測定です。
収録データ数の増大および手数が進むごとに定跡ルーチンの処理に時間がかかることがわかります。

40000局登録データで120手目に定跡ルーチンを呼ぶと958msかかっています。
まぁ、れさぴょんみたいに常に定跡ルーチンをコールすると問題だけど、定跡から外れた後は定跡ルーチンを呼ばないようにすれば問題ないですね。

KI2⇒csaコンバータ

KI2形式の棋譜を読み込むときに、局面をいちいち更新していかないと「右」とか「左」とかついたときの移動元がわからないよなぁ～、ということで移動元が明示的に入っているcsa形式に変換するコンバータを作ってみた。
しかし、csa形式は指手の駒を「移動後の駒名」であらわすので、その手で成ったのか、以前から成っていたのかがやはり局面をいちいち更新していかないとわからない、ということに先ほど気づいた。orz

それなら csa 形式である必然性はないなぁ…。

コンバータの処理で一度KI2形式のファイルを読み込むので、コンバートせずにKI2のまま使えばよかった。
まぁ、読み込み処理は使えるけど。