yuricat / fujigokorouecda Goto Github PK

全ヘッダが教育上よろしくない

java版サーバーはルールその他の仕様が色々と違うので、対処しないと落ちる

READMEに

ただし、大会出場以外での利用は要相談でお願い致します。

とありますがGPL-3と矛盾した内容に思えますがどういう意図でしょうか？

少なくとも方策単体では弱くなっているみたい
生成される着手が減った影響か、他の原因か

色々書き換え前
--------- total point
296832 (2.968) 0.piccoloGlcn
295596 (2.956) 1.piccoloGlcn
308827 (3.088) 2.kleinBlauw
299736 (2.997) 3.piccoloGlcn
299009 (2.990) 4.piccoloGlcn
kleinBlauw Change Time : 4385101 micsec / Play Time : 190436069 micsec
average of card strength: 5.706775
average of shibari: 0.158476
average of fukusuu(done/chance): 0.330933
average of kaidan(done/chance): 0.058891
average of joker turn: 40
average of 8giri turn: 47
average of spe3: 1774
average of kakumei: 3496

書き換え後
--------- total point
300367 (3.004) 0.piccoloGlcn
299681 (2.997) 1.piccoloGlcn
300311 (3.003) 2.kleinBlauw
299982 (3.000) 3.piccoloGlcn
299659 (2.997) 4.piccoloGlcn
kleinBlauw Change Time : 3029925 micsec / Play Time : 151011407 micsec
average of card strength: 5.557445
average of shibari: 0.164093
average of fukusuu(done/chance): 0.326414
average of kaidan(done/chance): 0.059387
average of joker turn: 41
average of 8giri turn: 47
average of spe3: 1787
average of kakumei: 3191

一度大富豪になってから落ちるまでが長いので、
毎回順位を入れ替えて少ない試合で強さを測れるようにした方が良い。
席順とかどう入れ替えるかは問題

現状態の局面表現と棋譜を分けて持っていたが、
デバッグやテストのため棋譜ベースで思考開始できるようにしたい

ただしサーバーの試合進行等バグにはまらないように
いちおう現状態も別に進行させておく必要があるか

パラメータ数が増えたので、学習前の特徴量解析+ パラメータ更新を並列化しないと遅い

あと棋譜数が増えたので、データ全体を見るのを1エポックとして制御する必要はないのでそこも柔軟に変更する

最大人数を決めておくか、可変長データ構造にするか

今の世界生成が全く確率に従っていないので、
尤度計算ベースにしたい

あと終盤や流した後の世界作成において前の結果を再利用したい

ルートで考慮すれば強さに影響するか?

特に自分のPolicyは何度も同じ状態で呼んでいるかも？

引数とかログ読みとかの共通の処理を毎回書くのは地味に面倒なので、
諸々の実行ファイルをまとめてもいいのでは？
gitベースならビルドできない状態が残ることはあまりなさそうだし、
引数によるパラメータ設定も現状の方式だと全部のファイルに書く必要が出て無駄

1500万試合弱で16GBを超えて動かせなくなったので、

• 棋譜の省メモリ化
  または
• 棋譜を使用時に読み込むようにする

前者は、moveとtimeを16ビットにするなどして構造体を半分くらいにできる、
あとは試合棋譜を連続試合ごとではなく全体で1つの配列に収めればもっと効率は上がる

棋譜のファイルからの読み込みは現状高速にはしていないし、
1試合ごとに細切れで無いので色々無駄が多いので使用時読み込みはすぐにはできない

学習用に一回新しいバイナリに落とすか?

ランクの幅が16弱なので線形方策のパターンマッチ部分は高速化できるはず