Bonanza6たおしたのじぇ！
twitterで書くのははばかられる内容なのでここにかくのじぇ
どうしたのまりちゃ？
Squirrel君がついにBonaza6を倒したのじぇ！（1thread 1s）
おめでとうだよ！
いろいろな出来事が走馬灯のように思い出されるのじぇ...
開発をするためにクラスとポインタで挫折していたC++を勉強し直したあの頃...
池さんの「HTML版コンピュータ将棋のアルゴリズム」を読んで将棋プログラムの作り方を勉強したあの頃...
れさ改に勝てずに、もがき苦しんだあの頃..
Bonanza完全解析ブログで３駒関係について勉強したあの頃...
フラッドゲートで稲庭将棋に2回引き分けを繰り返してようやく勝ち星をつけレーティング表に乗ったあの頃...
徹夜でrotated bitboardを作成したあの頃...
学習の実装を失敗し続けて全然評価関数が強くならなかったあの頃...
なのはミニに勝ったあの頃...
bonanzaに追いついたあの頃...
そしてbonanzaに勝った今...
感無量だねっ...
■
ううっ...!中規模棋譜学習に手を出してみたけれどなかなかうまくいかないじぇ...
深い探索の評価値と浅い探索の評価値の差の2乗は学習でどんどん小さくなっているので実装は間違っていないはずだし、差し手生成祭りの局面でもすぐにこの局面が悪いということに気が付いているのだけれど...
中規模棋譜学習ってあれでしょ？
自分の深い探索の結果を教師として学習を行うやつでしょ？
Squirrel君の強さじゃちゃんとした教師を作れてないんじゃないの？
う～～ん一応bonanza6よりちょっと弱い位の強さになってきたので頃合いじゃないかと思ったのだけれど...
ありしゅが言ったこと以外にも初期局面データ集が悪かったとか教師データをちゃんと作れてなかったとかハフマン符号化、復号化に失敗してたとか探索時に置換表を使ってなかったこととか、いろいろ考えられるねっ...
あと初期局面データを作るときに気づいたけど探索深さ８では評価値の絶対値が100以下だったのに、探索深さが9になると1000近くになったり評価値が不安定だったことも原因に考えられそうなのじぇ...
技巧や習甦みたいにボナメゾに浅い探索結果と深い探索結果との誤差の損失項を入れたほうがよかったのかもしれないのじぇ..
まあ一旦別のところに手を付けようじぇ。
次元下げについてなのじぇ
次元下げについてみてみようじぇ
昔理解しようとして途中で理解するのあきらめたやつね
次元下げとは例えば二つの変数（ここではx,yとする）で値が決まる関数f(x,y)があった時にf(x,y)をただ単に(x,y)の二つの変数の組だけで決定するのではなく(x-y)のようなものも使ってきめるということらしいのじぇ。
f(x,y)=g(x,y)+h(x-y)ということなのじぇ。
例として相対位置のことを考えてみようじぇ。
駒１(駒種pt1)が盤上の(x1,y1)にいて駒２(駒種pt2)が盤上の(x2,y2)にいる場合を考えるのじぇ。ここでは二駒関係PPの場合を考えるのじぇ。
この場合絶対PPの要素を指定するためには
absolute_PP[pt1][x1][y1][pt2][x2][y2]
となるのじぇ。
（実際はptとxとyをまとめたf_pawnなどという定数が使われる）
相対PPを指定するには
relative_PP[pt1][pt2][x1-x2][y1-y2]
となるのじぇ。
このabsolute_PP,relative_PPをPPに織り込むなりして局面評価に利用するのが次元下げを用いた評価方法だということだと思うのじぇ。
■
ううっ...進行度付き２駒関係全然強くならなかったのじぇ...
学習にかなり時間がかかった上に一致率も低かったのじぇ....
えーじゃあどうするのよ
PR文章には進行度をつけたいって書いちゃったでしょ？？
そうですよ～～頑張って進行度付きでも強くなるようにしましょうよ～～
う～～ん 進行度の学習方法は単純な確率的勾配降下法だったので進行度を正しく学習できてないかもしれないとか、
棋譜はソフトの棋譜を用いているので水平線効果の学習を防ぐために進行度が80%を超えたらそこから先は学習させなかったことがあだとなったとか
進行度の取り入れ方、学習のさせ方もまずかったとかいろいろ考えられるけれど、学習にかかる時間的にもう一回予備実験してPPより強くなるような条件を見つけてそこから本学習させて大会に間に合わせるだけの時間的余裕はないのじぇ。
まあGPSとか大槻将棋とか技巧とか進行度を見ている強豪ソフトも存在するので進行度を入れるという方針は間違ってはいないとは思うのだけれどっ！
まあ今回は仕方ないのじぇ。
ネタが一個減ってしまったのは残念なのじぇ（笑）
バグ修正なのじぇ
すごいバグを見つけたのじぇ。
今までずっとValue形は16bitだったのだけれどそれを32bitに変更するだけで初期局面の反復進化が2深くなったのじぇ。
int16_tをintにしただけｗｗｗ修正にして4文字なのじぇｗｗ
なんで16bitから32bitに変えるだけでそんなに変わるの？？
ビットオーバーフローが原因だと考えているのじぇ。
bitオーバーフローが起こって探索に用いるstatsが壊れていたり、詰みに近い評価値の時にmin(a+b,c)がおかしな値になってしまったりしていたようなのじぇ。
いやー置換表に格納する評価値は16bitなのでValueも16bitで用意しようと思ったのだけれど意外なところに盲点があったものなのじぇ～～
置換表ってなんなの？
置換表は一度訪れた局面をもう一度探索するのを防ぐために用意するテーブルのようなものだよっ！反復進化やアスピレーションサーチ（探索の範囲を前回の探索の値を中心にだんだん広げながら探索する方法）にとって必須の要素だねっ！
キャッシュに置換表要素を整列させる（置換表がキャッシュラインにまたがってしまうと遅くなるらしいので置換表のサイズはキャッシュラインのサイズで割ることのできるサイズでなければならない）ための関係で、置換表に格納する評価値を16bitにするつもりだったのでValueを16bitにしたみたいだねっ！
その通りなのじぇ。いやー神は細部に宿るとはよく言ったものなのじぇ....
