http://canadian-pharmacy-center.com

NineDayFever

Home  /  NineDayFever

On 4月 29, 2016, Posted by , With NineDayFever はコメントを受け付けていません。
金澤 裕治 NineDayFever
ひきつづき局面評価の極北を目指しています。といいつつ、改善ネタが切れ気味になっており、局面評価はこれまでの延長で地道に改善を図っています。以下の項目1. の学習は、学習済みの部分が動かないようにこれまでの学習に使ったデータ+新規に追加した局面で学習する必要があって、それが原因で時間が増加していたのですが、学習済みのところは今の評価値から動かさないようにするだけにするとか、いろいろやって高速化しています。

1. 対戦中や探索中に現れた局面を調べ、機械学習結果の欠陥を探して修正しています。
2. 未知の局面への対応力を増加させるため、3駒関係を共通するパラメータに分解し、2次の正則化項を使っています。
3. 評価値の計算で手番を考慮しています。
4. 従来の3駒関係では考慮しにくかった飛角香の働きを考慮するパラメータを導入しています。
5. 自己対戦結果に基づいて bonanza の book.bin から一部の手を削っています。

プログラムに関しては、以下の点でオリジナルのボナンザに手が入っています。今年追加したのは 8の変更にmove count based pruning が入った程度です。

6. kpp(pc_on_sq) を 3次元配列にしています。さらに、持ち駒数0に対応するインデックスを削ることでちょっと高速化しています。
7. 上で述べた手番考慮eval処理、飛角香の働き考慮eval処理などを実装しています。
8. stockfish を参考にして探索部分を一部アップデートしています。
9. スレッド数が多いときの並列処理効率低下を防ぐため、探索ツリーのスケジューリング機能を入れました。

あとは効果が大きい処理としてはクラスタ並列があるわけですが、今から手をつけてデバッグが間に合いますか。やるとしたら、1ノードに2個の候補手を投げて上の9.の項目のスケジューリング機能を使ってCPUが遊ばないようにすることになると思います(というか、そういう効果まで考えて実装したものの、クラスタ並列までやるのは面倒だったので先延ばしになっている)。


・あまり目玉がないので move count based pruning についてのあれやこれやなど
 stockfish のコードを bonanzaに入れる中で特に苦労したのが move count based pruning で、なんか効果が出ないわけですよ。一定の数だけ候補を試したらあとは飛ばしちゃうので、良い手が前の方に並ぶようにしなければいけないんだけど、なかなかそうならない。stockfish の手法をざっくり解説すると、試す手の順番は評価値(history)順で、この評価値の決め方が、ベータカットを起こした手の評価を一定値(depthの2乗)増加させ、それまで試した手の評価を同じ値減少させるというもの。これがなかなか効果がでない。いろいろ試したあげく、最後に評価値を減らすのは最初の63手だけという謎の部分を真似っ子したら突然まともになったという。なんなんですかねこれは。もともと評価値が低い手の評価値は減らさないほうがいいということなんだろうけど、63番目と64番目で何が違うのかと。
 それで思ったわけですよ。これって要するに、沢山ある手を、良い結果をだす確率が高い順に並べたいわけです。で、その種の評価値って、我々が普段からよく目にしているレーティングそのものではないですか。じゃ、最も良い結果を出した手が他の手とそれぞれ対戦して「勝った」と考えて、レーティングの簡易計算法(勝った側のレーティングを (12+レーティング差/32) だけ増加、負けた方を同じだけ減少させる)でもって評価値をアップデートしてやれば、ひょっとしたらうまく整列してくれるのではないかと。もともとレーティングが低い手にレーティングが高い手が勝った場合は評価値はほとんど変わらないので、後ろの方で試した手は評価値を減らさないという意味も理解できる。
 で実験してみたら、一応効果があるっぽい。ほとんど誤差なのであまり役には立たないのだが。とりあえず最初の63手だけ評価値を減らすと効果がある理由がわかっただけでも良しとするか。
Comments are closed.