ボーナスの付加を実装完了
色々細かいトラブルがあったのでメモ＆解説。
まず、「パラメータごとのボーナス」から「評価関数全体のボーナス」を計算します。
パラメータごとのボーナスは「sqrt(2.0*log(パラメータの使用回数)/評価関数全体の学習回数) * abs(特徴量)」としました。
sqrt(...)の部分はUCB1の式そのもので、それに特徴量*1の絶対値をかけています。
絶対値にしているのは、「あえて自玉の下に相手の金を打たせて*2、その位置の金の評価を学習する」という事をさせたいからです。
「評価関数全体のボーナス」は、単純に「パラメータごとのボーナス」を加算したものです。
で、評価値計算の際は、評価値に「パラメータごとのボーナス×ボーナス付加割合」を加算したものを評価関数の返り値としました。
（ボーナス付加割合はボーナスの量を加減する為の正の係数です。）
んで、私の評価関数は、先手にとっての評価値を計算するか、後手にとっての評価値を計算するかを、引数で指定可能にしていしています。
ボーナスは引数で指定した手番に対して加算するので、「ある局面の先手にとっての評価値 == -1 * 同じ局面の後手にとっての評価値」にはなりません。
という訳で、αβの方もちょっと修正して、まずルートノードの手番にとっての評価値を計算し*3、ルートノードとリーフノードの手番が異なれば評価値を符号反転したものを使用する事にしました。
こうしないと、「ルートノードの*4手番でリーフノードになれば良い、ルートノードと異なる手番でリーフノードになると悪い」と判断してしまい、PVの末端ノードが使用頻度の低いパラメータの出現する局面になる様にする、という目的に沿わないと考えたからです。
という訳で色々ありましたがとりあえず完成。今から学習させてみます。
ざっと動かした結果だと、ボーナス付加割合は0.001より大きいと評価値が明らかに変になるので、0.01〜0.00001位で試してみます。
