Spearがfv.binを同梱している件
floodgateのSpear(→ http://www.teu.ac.jp/gamelab/SHOGI/SPEAR/spearmain.html )の評価値がBonanzaと酷似していることが、一部の人の間で話題になっていた。私も以前から気になっていたのだが、最近ちょうど某巨大掲示板のほうで話題になっていたのでこれを機に詳しく調べることにした。
要するにこの時点でBonanzaと同じような評価関数を使っていることは明白であり、Bonanzaと同一(あるいは同等)の評価関数テーブルを用いてある可能性が高い。
Spearの公式サイトから以下のファイルをdownloadして調べる。これはCSAトーナメント(世界コンピュータ将棋選手権?)に出場したときのバージョンだろう。
May 29th 2009: New version release (SpearCSA2009v1.5)
Download: The Spear engine for Shogidokoro (CSA Tournament 2009 version 1.5, 51MB)
このアーカイブのなかには、186,268,248 bytesの"eval_features.bin"というファイルが同梱されている。
これは、Bonanzaに同梱されている"fv.bin"と全く同一のファイルサイズである。
ファイルサイズが同じでもidentical(バイナリ的に同一)であるかどうかは別だ。とりあえず結論だけ書くとこのバイナリ自体は、"fv.bin"とidenticalではない。しかしファイルサイズが同じで非常に怪しい。
詳しい検証の前に、公式サイトによると、次の記述がある。
Changes in the CSA Tournament 2009 version 1.0:
Engine: A completely new evaluation function was implemented which was tuned automatically using the Bonanza learning method.
Bonanza学習メソッドを使って自動的にチューンされた評価関数と書いてあるが、その評価関数の値をどこから持ってきたかについては書かれていない。
また、「世界コンピュータ将棋選手権」の場合、ライブラリを使用する場合は、ライブラリ申請をする必要がある。fv.binだけの使用であっても、ライブラリ申請は必要なはずである。しかし、Spearは、その申請は行なっていない。(→ http://www.computer-shogi.org/wcsc19/team.html )
そこで、このSpearの"eval_features.bin"が、"fv.bin"と同等のものであった場合、
1) 第19回「世界コンピュータ将棋選手権」にライブラリ申請をせずに出場していたことになる。
2) "fv.bin"を改変しての無断公開をしていることになる。
Bonanzaのライセンスは私はよくわからないのだが、改変 and/or 転載は認めているようで、これは許される範囲なのだとは思うが、せめてBonanzaのfv.binであることを明記する必要はあると思う。これを明記せずに改変したものを自分が開発したもののようにして公開するのはまずいのではないかと思う。保木さんの許可の元に改変しての公開が行なわれているなら、この限りではないけども。
そんなわけで、"eval_features.bin"と"fv.bin"とが何らかの変形によって同一になるか詳しく調べてみる。まず手始めにfv.binは、s16(符号付き16ビット型)のデータで構成されているので(Spearのほうは何らかの変形をしている可能性はあるが、それについてはいまは考えない)、それぞれのデータの数をカウントしてみる。fv.binはBonanza4.1.2のものから。
検証には以下のC#のプログラムを用いた。
int[] count1 = new int[65536]; // ushortすべて
using (var sr = File.OpenRead("fv.bin"))
{
byte[] buffer = new byte[1024];
int offset = 0;
for (;;)
{
int size = sr.Read(buffer, offset, 1024);
if (size == 0)
break;
for(int i=0;i<size;i+=2)
{
ushort u = (ushort)(buffer[i] + buffer[i + 1]*256);
count1[u]++;
}
}
}
int[] count2 = new int[65536]; // ushortすべて
using (var sr = File.OpenRead("eval_features.bin"))
{
byte[] buffer = new byte[1024];
int offset = 0;
for (;;)
{
int size = sr.Read(buffer, offset, 1024);
if (size == 0)
break;
for (int i = 0; i < size; i += 2)
{
ushort u = (ushort)(buffer[i] + buffer[i + 1] * 256);
count2[u]++;
}
}
}
for(int i=-20;i<=20;++i)
{
Console.WriteLine(i + " : " + count1[i & 0xffff] +","+ count2[i & 0xffff]);
}u16の値がXであるデータの個数をBonanzaとSpearとで比較してみると次のようになる。Xは0付近がもっともデータが多いので、-20から+20の範囲のみ。
−20 : 17638,2435
−19 : 18580,2630
−18 : 19276,2700
−17 : 19950,2872
−16 : 21471,2882
−15 : 22087,2818
−14 : 23887,2864
−13 : 25338,3007
−12 : 27997,2948
−11 : 30945,3043
−10 : 34759,3282
−9 : 39524,3135
−8 : 46263,3302
−7 : 55437,3382
−6 : 65568,3518
−5 : 77606,3852
−4 : 92886,4346
−3 : 111701,5238
−2 : 3014050,561777
−1 : 16869743,12661413
0 : 33023795,34652766
1 : 27247679,33537783
2 : 8196402,10998687
3 : 110137,5047
4 : 93092,4403
5 : 78115,3883
6 : 65111,3688
7 : 54636,3522
8 : 46499,3400
9 : 39771,3205
10 : 35105,3064
11 : 31594,2933
12 : 28056,3153
13 : 26187,3039
14 : 24305,3035
15 : 22495,3023
16 : 21292,3002
17 : 20443,3000
18 : 19766,2757
19 : 18782,2628
20 : 18645,2469
Spearのほうが0に集まっていることがわかる。単純に割り算してあるわけではなさそう。念のため、データのなかから最小・最大の値を調べておく。
max : Bonanza = 8856 , Spear = 8064
min : Bonanza = -11779 , Spear = -12654
次に、Bonanzaのfv.binとeval_features.binを差し替えて、動作テストしてみる。Bonanzaに同梱されているcsa.exeを実行して対戦してみた。ノーマルのBonanzaとどちらが強いのかまでは検証していないが、ともかく普通にBonanzaと対戦できた。それほど弱くなっているわけでもないようだ。
なんと結論していいのかよくわからないけども、とりあえずはidenticalではないし同等のものではないが、評価関数の形やデータ構造はそっくり同じだと言えそうだ。おそらくは学習用の棋譜を別で用意して、ボナンザメソッドで学習させたのだと思うが、学習棋譜や学習条件等が異なるので、異なる値に収束しているのだと思う。Spearのほうが0付近に多くの値が収束しているのはペナルティが強すぎるのか、学習時の静止探索の深さがDEPTH = 1で学習させてデータが不足しているからなのかも知れない。
それで、ここまで書いて気がついたが、これは旧Bonanzaのfv.binである可能性も考えられる。しかし4.0.3 / 4.1.1のfv.binと比較してみたが、どうもそれらともidenticalではないようだ。それら以外の保木さんが公開されていたfv.binが存在するのかは私は知らないので、それら以外は私には調べられない。
また、評価関数の形というのはアルゴリズムに属する部分で、著作権等は発生しないものと考えられる。よって「第19回「世界コンピュータ将棋選手権」にライブラリ申請をせずに出場していたこと」にはならないと思う…のだが、データ構造、並び順まで同じとなると、Bonanzaのshogi.hで定義されている評価関数テーブルを見るときの駒ごとのindex値(f_hand_pawn〜)もすべて同一ということであって、アルゴリズムの域を超えている気は少しする。
なんだか腑に落ちない結論になってしまって申し訳ないが、誰かが書き留めておく必要があると思ったのでとりあえず私が記事を起こした。
