先日からアナウンスしておりました１ファイルマッチ体験会が先週末無事終わりました。
報告が遅れましたが簡単にまとめておきます。
１０チームで総当たり、９回裏表の計１８回戦となりました。
上位は全勝の地ビール、15勝3敗のshogi686_sdt5、13勝4敗1分の真れさ改1ファイル、13勝5敗のsample4-5aと手前味噌ですがうちの子らが上位を占めてしまいました。
真れさ改もノーマルれさ改に比べ相当強かったですね。作者の池さんもバグがあるのは分かっているのでそのうち修正したいと仰っていたので修正されたのかもしれません。
うちの子らの順位はもう少し分散すると思っていたのですが、ノーマルれさ改の位置から考えても皆さんもう少し頑張りましょうといったところでしょうか。
floodgateレートで地ビールは2500くらい、sample4-5aが1500くらいですので目標にして頂ければと思います。LesserKaiは700くらいでしたっけ？
sample4-5aの方は過去のサンプル含めて公開しておきます。
shogi-eval/sample4-5a.py at master · bleu48/shogi-eval · GitHub
ただ、これはプログラム簡便のため探索深さ固定となっており、持ち時間が少なくなっても慌てて指すことはなく時間切れをします。
真面目に大会に出るなら対応しましょう。
本体験会でもsample4-5aの時間切れ負けは２度あり、特に９回表の時間切れの対応が遅れたために９回裏の開始に間に合わず異常負けとなったところです。
対戦エンジン的には９回裏の負け後に９回表の最後の指し手を返しておりました。酷いですね。
簡単にsample4-5aの改善点を説明しておきます。
探索部は体験会前に公開したネガアルファ法です。
アルファベータ法で結構探索時間に効いて来るのが候補手のオーダリングです。
今回簡単に実装してみました。（雑すぎると言われそう）
以前探索前に手を選ぶので駒を取る手や成る手を上位にする話がありましたが、同じ考え方を使ったオーダリングです。Pythonでリストの並べ替えはラムダ式を使えば簡単に一行で書けます。
次の肝は評価関数です。
以前からサンプルを出していますがNNUE型のファイルを直接読んでいます。
今回は多方面で愛用されておりますKristallweizenを用いました。
デフォルトのモデル型なら以下のままで読めるはずです。
そして盤面評価ですね。
特徴ベクトルは他の関数で作っています。k0、k1は自玉敵玉の位置、fv38は玉以外の駒の位置、fc38qはそれを相手から見たものです。
これらが入力となり、あとはnumpyを使った簡単なニューラルネットワーク構成です。
つまり、差分更新やSIMD演算などのNNUEの特徴は生かしていません。
但し入力ベクトルが81×1548の長大なサイズに対して38個所に1が立つだけのものですので，これを38巡のループにする程度の処理をしています。
一応お断りをしておきますと、PythonとC++では負の整数除算が異なりますので正確にはNNUEと同じ値になるわけではないです。オーダリングの雑さ加減から比べたら可愛いものです。気にしないでいいと思います。
次のイベントまでに切れ負けしないような処置と探索部の工夫を加えようかとは考えています。
あ、それから重要な反省点ですが、新参者歓迎です。
気楽にプログラム作ってみてください。
---
追記：
sample4-5a等のファイル名については適当に更新しているので細かく気にしないで下さい。一般的なソフトウェア開発と異なり、新旧バージョンの比較対戦などを頻繁に行うためにgit管理などが適さないためどんどんファイル名を付けていっているだけです。
4も探索深さ4固定の意味でもありますが、また変わるかもしれません。
---
追記２：
numpyの処理はnumpyのバージョンやCPUアーキテクチャによって結構処理速度が代わることが確認されています。もちろんnumpyのバージョンは新しい方が良く，CPUは廉価化したZen3や最新のZen4などAMDが何故かコストパフォーマンスが良い感じです。
手元計測ではRyzen 5 5625Uで12knps程度，Ryzen 9 7950Xで20knps程度は出るようです。インテルは最新世代のものでこれらの間の値です。
CPUもPythonもnumpyも年々高速化されていますので来年にはもっともっと速くなっているかもしれません。
もちろん，地ビールはGo言語実装ですのでこれより一桁以上高速で，やねうら王やshogi686_sdt5などの高度なC++実装は更に数倍速いです。
