【オセロ,将棋】ボードゲーム【囲碁,War】

**名前は開発中のものです。** · 03/07/10 00:10

比較的地味なボードゲーム専用のスレが欲しくて立ててみました。

私はc言語で作ったデータベースを使って人間と対戦できる将棋かチェス
みたいなソフトを作りたいと思ってますが、グラフィックインターフェースの
作り方がわからなくてつっかえているレベルです。

**535** · 2017/06/28(水) 22:15:10.75

だめだ、５手目で間違える。
やっぱ自己対局じゃ完全解析までたどり着かないかなぁ。

**535** · 2017/06/29(木) 23:11:55.06

Connect4,対人だとなかなか強いんですが、
それでも全然勝てないってわけでもないですねぇ。
自分でプレーして一回勝ってしまった。
まだまだですね。

**535** · 2017/07/01(土) 00:13:06.32

http://web.mit.edu/sp.268/www/2010/connectFourSlides.pdf
前半は読みやすくてわかりやすいけど後半一気に難しくなって結局理解できてない。

**310** · 2017/07/01(土) 02:11:20.40

終盤探索とりあえずのところまで完成。

盤面の持ち方をちょっと変えて__mm128iにしてみた。
パスの処理を変えてみた。
これで、FFO#40で時間計測。

YBWCで1200msくらい
置換表までで、1800msくらい
negascoutまでで、2200msくらい

nodeカウントを入れると15%くらいスピードダウンする（汗
そこから逆算して、200万nps以上出てる。
まあ結構な速度になりました。

偶数理論も作ってみましたが、空白マスを連続する単位で分離するオーバーヘッド
が大きく、採用すると70万nps程度に落ちてしまう。この処理の良い方法が見つから
ないため、いまだに偶数理論は使っていません。むむむ。

現在、素のMCTSに着手してます。
これができたら、対局集めて、EigenでMLPのライブラリ作って、評価関数（仮）作成。
評価関数をもとにPUCTにアップグレードして強化学習という予定です。

まだ先は長い（汗

**310** · 2017/07/01(土) 02:18:02.59

>>877
自己対局だと局所解にはまっちゃう時ありますよね。

DBの内容がわからないので、以下頓珍漢かもしれませんが。

解消法としては、開始後数手については、ランダム着手にする。
途中でε-greedyみたいに、ランダムな着手を挟む。

こういった方法で、局所解から外れたところも学習対象に入れる工夫があります。

気持悪いやり方だけど、５手目だけif分で強制的に直して修正済み自己対戦データ
を蓄えて学習するという方法もあります。

**535** · 2017/07/01(土) 18:28:17.34

ランダム着手をまぜるのはいいかもしれませんね。
ありがとうございます。
アルファ碁もやってる手法なんでしたっけ？

**535** · 2017/07/01(土) 23:24:59.13

局所解を避けつつ有望な局面を多く調べるというのはまさにMCTSでやってることなんじゃ？
一回駄目出し食らった案ですが、モンテカルロ木をDBに保存して無限に成長させるという案がどうしても忘れられない。
局面数が大きくなるゲームだと木が大きくなりすぎて駄目ですがConnect4なら…

**535** · 2017/07/02(日) 00:25:04.48

完全ソルバで遊んでるんですが、Connect4って思ったよりゲームバランス良いゲームなのかも。
先手が圧倒的優位かとおもってたけど、後手が完璧に打ってくるとき、
先手も正解が一手しかないという局面が結構あるんですね。
意外と奥が深い。

**310** · 2017/07/03(月) 20:45:11.36

MCTS自己対戦させながらデバッグ。そろそろバグはなくなりましたが…

勝っていると緩んで、負けているとギャンブルする癖と、お互いに緩みあっている間に
引き分けに収束してしまう事から、そのままでは記譜に使えない事を自覚中。

とはいえ、記譜を真面目にZebraで並べて見てしまうと、疑問手だらけで、そこを直したく
なって、強化学習にならなくなってしまいますね。

序盤はMCTSで探索し、残り２０手で終盤探索して後半中心の評価関数をまず作る事かな。

もともと、前半の何手かはランダム着手して、オープニングの種類が偏らないようにしよう
かと思っていましたが、この調子だと、最初の４０手はランダム着手にして、残り２０手を
読み切りにした方が、記譜数が稼げる気がしてきました（汗

**535** · 2017/07/03(月) 22:52:12.07

40手もランダムに打たせるんですか？うーん。
にわかには信じられないですが偏らないようにするためには有効なんですかね～

**310** · 2017/07/06(木) 23:41:11.66

終盤２０手の盤面集めなので、ばらけた方がよいし、ランダム着手の方が速いかなと。

とはいえ、今はMCTS５秒読み＋残り２０マス完全読みで記譜集めしてます。
１譜３分弱で、今のところ重複記譜なしで、７００譜くらい集まったところです。

さっきまで藤井四段のabemaTVにCPUを15%くらい持っていかれていました（汗

改良したいところはあちこちありますが、とりあえずニューラルネットのライブラリに専念。
optimizerをどうやって作ったか、まったく思い出せない（汗

**310** · 2017/07/08(土) 20:32:28.67

ニューラルネットの計算でけました。たぶん。
頭が行列に切り替わるまでが憂鬱なんだよなぁ。

optimizerは計算式なぞるだけで楽勝でした。が、理解しないまま行列計算
に置き換えているので、何が何だかわからなくて、忘れちゃうんでしょうね。

続いて、tiny_dnnのstl的なインターフェースに憧れて、ミニバッチの処理
とかのインターフェースに凝りだしてしまった。

本当はレイヤー階層定義のところも凝りたかったのだけど、今のところ
MLPレベル（２層）までしかやらないと自分に言い聞かせて自粛中。

学習データは１２００局くらい集まりましたが、全滅の時の完全読み切り
の手順取得処理にバグがあって、無限ループ入り。せっかくの全滅に
至る記譜が採れませんでした。無念。

**535** · 2017/07/09(日) 21:54:20.93

>モンテカルロ木をDBに保存して無限に成長させる
これやってます。
５手目は正解できるようになったようですが、まだまだ完全ソルバには勝てません。
メモリはそんな簡単に爆発しないみたいだけど、木が大きくなるにつれ速度がかなり遅くなる。
UCBの計算が遅いのだろうか？

**310** · 2017/07/10(月) 00:58:02.21

自分のはロールアウト関数がボトルネックなので、木が深くなると速度が上がっていき
ます。MCTSの設定も、どんどん深く行く方向で調整してます。UCBの計算は普通に
cmathのlogとかsqrtとか使ってます。

結局、今日は一日、ニューラルネットのライブラリのインターフェースをしこしこと
作って直して、してました。template使いまくりです。
まだやりたい事があるのですが、今の状況では不要だし、泥沼に入りそうなので、
いったんこの辺で。

記譜は1500超えたので、明日から終盤の評価関数作ってみる予定。
できたようなら、MCTSの探索方法を変えて、更に良い記譜を集めるか、それとも
置換表付き完全読み切りのバグを探すか。

**535** · 2017/07/10(月) 22:57:52.54

きたああああああぁぁぁぁあああああ！！
完全ソルバに勝利！！！！

http://connect4.gamesolver.org/?pos=44444222242555777711776655625636363333111

この勝利を引くために数十回リトライしましたｗ

**535** · 2017/07/10(月) 23:09:01.53

ちなみにDBは初期曲面のプレイアウト回数が約36万回になりました。
少なそうに見えるかもだけどDBつくるのに結構時間かかってる。

囲連星にも応用したいな～

**535** · 2017/07/10(月) 23:24:06.47

DBの木の深さは一番深いところで37。
結構、深いところまで読んでるんじゃないでしょうか。
もちろん、途中で読んでない局面に分岐されると困ってしまうんですが…

**535** · 2017/07/10(月) 23:38:14.93

UCBの係数をいじれば木を浅く広くにもできそう？
完全ソルバに勝つにはそっちのほうがいいかもしれないですね。

**535** · 2017/07/11(火) 00:01:35.20

>>890
プロファイル取ってみました。
logとかsqrtとかはインライン展開されて？計算時間がよくわからなかったですけど多分ボトルネックじゃなさそう。
ちなみに局面と勝率を保持するクラスのコピーコンストラクタに全体の60%の時間がかかってるという
完全に意味不明のプロファイル結果が出ました。
どう解釈すればいいんですかね？

**535** · 2017/07/11(火) 20:08:54.72

んーもしかしてツリーを丸っとコピーしちゃってる？
問題の個所はどこだろう？

**535** · 2017/07/11(火) 21:20:27.73

え、めっちゃ早くなった？ｗｗ
我ながらこれはヒドスｗｗｗｗ

**535** · 2017/07/11(火) 21:50:40.06

うおっ一瞬でメモリパンクしたｗｗｗｗ
310さんの言ったとおりだったｗｗｗｗｗ

**535** · 2017/07/11(火) 22:02:05.79

局面の合流を検知しないでベタに木を展開してんのがまずいのかなぁ。
まあモンテカルロ木DB化はこの辺が限界かなぁ。

**535** · 2017/07/11(火) 22:31:32.07

本線じゃない分岐の間違いを修正するには指数的な試行回数が必要になるなこれは。
まあしょうがないか。

**310** · 2017/07/12(水) 20:10:09.86

直ったようで何より(^^/

自分は合流させてません。
合流させるメリットよりデメリットの方が大きそうだったので考える事をやめました。

モンテカルロ木DB化って、よくよく考えたらQ学習みたいなものではないかと思います。
Q学習だと全部のノードにQ値を持つので、結局全局面保持することになります。
現在Deep Q学習が主流になってるのは、Q値をディープラーニングで近似計算する
事で、全局面のQ値を保持しなくても良くするためという側面もあるかと思います。

で、Q学習だと考えるなら、時々変な手を混ぜて木をきちんと分岐させるってのが、
強化学習の肝ではないかと思います。

当方、完全読み切りのバグとり完了。
ニューラルネットのライブラリも大体できて、1900譜で４０手目以後を学習してみました。
やっぱ、疎行列対応の行列パッケージでの計算は、tiny_dnnと比較して圧倒的に早い
です。

データが少ないのと、同一の記譜内からテストデータ取っているのもあるのですが、
テスト誤差は十分小さな値になるのですが、FFOの盤面を評価させると、いまいち
合っていない感じで、あまり汎化できていない感じす。もっと記譜増やします。

やっつけで作ったmcts部分をきちっとさせるのと、とりあえず持っている評価関数
で、puct化できるか、ロールアウトの後半の精度を上げられるか、検討開始です。
強化学習までまだ遠いなぁ。でも、少し背中が見えてきたかな。

**310** · 2017/07/12(水) 20:27:07.87

記譜集めですが、８手までランダム着手していたら、
９手目で白全滅という記譜が取れました（汗

**535** · 2017/07/14(金) 21:11:11.02

Connect4もひと段落ついたし囲連星もアイディア湧かないし
気分転換にライフゲーム囲碁のAIやろうかな。

**310** · 2017/07/15(土) 02:17:52.56

再帰呼出は関数オブジェクトを使うと速いというのを見つけて、あちこち試してみました。
static constな再帰関数は速くなるみたい。
クラス内でthisを参照するような類は効果が無いようです。

が…、なんか数か所おかしいような。

やっぱり、どこかでバグを仕込んでしまった模様。むむむ。
続きは明日だなぁ。

**535** · 2017/07/15(土) 02:40:13.20

関数オブジェクトを使うと速いってのはどんな理屈なんですかね？
ちょっと想像つかない。

**310** · 2017/07/16(日) 00:06:25.07

なんかもともと関数呼び出しの方が速いという事で数字で実証するサイトがありました。
まあ、コンパイルの最適化のかかり具合なのかなぁ。わからないです。
コンパイラのバージョンで違うのかも。

バグの原因はわかりました。関数呼び出しにするときに、同時にパスの扱いを変えた
のが原因だと思います。が、確かめる際にもとに戻したら、普通の関数の方が速かった
という結果に。バグってるときの実行時間なので、あてになりませんが。

というわけで、全部もとに戻して、少しだけ確認しましたが、あまり差はない模様orz

記譜の中に間違った読み切り手順が混じってしまったので、全部再計算。
こちらもパスの扱いを変えたのが原因で、別のバグが出ました（汗
二次災害大です。

再計算は２４００記譜で１時間半くらいで、着手は最善手の中でのランダムなので、
１回実行してアペンドすると倍、２回で３倍というように、記譜の増殖が可能と思い
当たりました。これを使えば学習データを簡単に増やすことができます。

**310** · 2017/07/17(月) 22:52:41.07

評価関数まわりを作ってデバッグ。
その中で致命的がバグが発覚しました。

学習用に溜めた記譜データにおかしなデータがいくつかあるというもの。
学習やり直しです。

記譜データ消した後で気が付きましたが、復旧できないわけではなかった。
後の祭りですorz

**535** · 2017/07/19(水) 21:46:51.76

うヴぉあー
プログラム組むのすっごいだるい。
心ときめくアイディアが欲しいところ。

**535** · 2017/07/20(木) 20:57:58.92

ライフゲーム囲碁、DB使ったほうが弱くなる？
どういうことだこれは…

**535** · 2017/07/20(木) 21:13:01.54

弱くなってるわけではなく互角のよう？
DBの情報量が少なすぎるだけだろうか？
よくわからん。

**535** · 2017/07/20(木) 21:56:32.91

攻め合いが全然めちゃくちゃだなぁ
5x5のパターンマッチ入れるか。

**310** · 2017/07/22(土) 02:06:09.72

結局４０手までランダム＋残り２０手完全読みな記譜集めて、残り２０手の評価関数と
Policyを作ってます。ランダム１０００件に対して３０件のMCTS自己対戦混ぜたもので
学習してます。ランダムだけで十分学習になるようで、悩むより数を集める方が大事な
感じです。４０手以後の評価関数ですが、３０手過ぎくらいから、そこそこ使えるみたい
です。

で、これを使ってPUCTな形にしてます。

完全読みが使えないので、２０～４０手あたりで最善手（に近い手順）をどうやって
作ろうかという感じです。

まずは、後ろから探索で、何手までまともな手だったか遡るプログラムを作って、
残り２５手くらいまで遡れたら良いかなぁと。

つか、強化学習に行っちゃおうかなぁ。

**310** · 2017/07/22(土) 20:32:19.70

逆順チェックのプログラムして、学習時に、正解手順で遡れる盤面も含むようにして
みました。仕組みとしては、最終盤面からヌルウィンドウサーチして、もっと良い評価に
なる手が無いことをチェックして、OKなら１手遡ります。置換表にてPVの評価は即求まる
のと、ヌルウィンドウサーチを使っているので、２５手までなら楽勝です。

MCTSで対戦したデータには２７手より前まで遡れるものもあるようですが、丸１日
チェックしても終わりそうにないので、２５手で打ち切り処理を入れました。

記譜に正解手順で遡れる手数を持たせて、学習時には、その手番以後の盤面を使用
する事で、３０手過ぎの評価の精度を上げられたら良いなぁと思います。

**535** · 2017/07/23(日) 00:28:11.37

5x5のパターン入れたらむしろ弱くなってるような…
え～なんで～？
絶対効果あると思ったのに。

**535** · 2017/07/23(日) 20:45:11.86

ライフゲーム囲碁も囲連星も完全に手詰まり。
それはそれとしてスレッドリッパーが欲しすぎる。

**310** · 2017/07/23(日) 23:50:20.93

遡りチェックしていたのですが、普通のUCT時代の方が精度が高い。
そこで気合入れてPUCTのチェックをしてみたら、案の定符号がひっくり返って
いる箇所があったり、パスの処理が抜けてたり。

たぶん、これで大丈夫だと思います…。

これでしばらくは、高速化しながら、記譜集めですね。

**535** · 2017/07/24(月) 21:00:27.54

もうずっと諦めてたディープラーニングに再トライするか…

**310** · 2017/07/29(土) 22:16:52.30

遡りチェックの高速化で迷走中。

２８手までなら問題なさそうなので、現在チェック中。
２８手まで３５分で遡れる記譜で２９手目が１日経っても最善手か否かがわからない。
あまりに極端な差なので、何か条件があるのか、たまたまそういう記譜なのかを調べる
ために、いったん２８手まで遡れる記譜を探すという段取りです。

その間、PPLのキャンセル処理について、厳密に考えていたら、今のやり方ではベータ
カットでのキャンセルが効いていないのではないかという疑念が。ループの中で再帰し
ているので、そこにcancellation_token_sourceオブジェクトを渡してやって、ポーリングを
して、下ノードでもキャンセル処理をしないといけないが、していなかったので結局中断
せずに、普通に終了待ちしてしまっているという事。
で、キャンセル処理を直したのだけど、時間変わらず。メッセージ出すようにしてデバッグ
したところ、ベータカットが１件も起きていないという謎な事態が確認されました。出てくる
答えは合っているので、しばらく考えることになります。

**535** · 2017/08/06(日) 01:16:09.87

ここのところさぼりっぱなし
スレッドリッパーも１５万以上らしいし
テンション下がる

**310** · 2017/08/06(日) 10:08:36.68

キャンセル処理については確認完了。たぶん大丈夫。
ただ、キャンセルが多発するはずの、最善手じゃなかったときに、通常より時間がかかる
傾向に見えるのが気になる。mctsが間違えるくらい枝分かれが多いからかもしれないけど。

遡りチェックはやはり遡り２９手目から日単位で時間がかかるものが出てくる。
２８手まで遡ると、最大数時間くらいな感じなので全部チェックするなら２８手が限界かも。

当分の間、記譜集めという事になりそうですが、１日動かして数十記譜では終わる目途が立たない。
精度落とせばスピードアップできるけど。

あと、mctsで末端ノード１００万単位まで探索して引き分けの時に、完全読みかけるとそう
じゃないときが結構ある。どこかで枝の探索漏れが生じてるっぽい。Policyの方はかなり
小さくても探索はかかってるようなので、Valueの方じゃないかと思う。

**310** · 2017/08/06(日) 21:21:02.06

最善手じゃなかったときの時間問題、原因判明。オーダリングでした。

オーダリングでは置換表にあるものを優先していたのですが、遡りチェックの時には
ベータカットを起こすには置換表に無い方から探索しなければいけないわけで。
遡りOKの時は、どういう順番から探索しても、全て探索するしαは更新されないので
かかる時間がほぼ一緒ですから、順番変えてOKです。

でも、これ通常探索時には逆になります。条件的には、ヌルウィンドウサーチの時と
そうじゃないときで区別できそうですが、ちょっと考えてみます。

探索の方の問題は、やはりValueの評価値とRolloutの勝率がともに悪いと、本当は勝ち
手順でも簡単にはチェックがかからなくなってしまうという問題かなと思います。この辺は
精度アップで対応するしかなさそうです。

**310** · 2017/08/07(月) 20:08:24.65

オーダリングを詰めて、さらにヌルサーチ専用の処理を追加。
ベータカットが早めに起きるようにしたのもありますが、それ以外の部分でも
倍速近くなっていると思います。が、まあ、それでも２８手目以前まで遡りチェック
するのに時間がかかるという点では焼け石に水。

記譜集めからの逃避はこの辺にして、記譜集めに戻らないと…。

ここまで来ると準確定石によるアルファカットも再度実装してみたい。
準確定石を求める処理も、ソースごと消失しています。
以前は盤面与えると都度再計算していましたが、石を置くごとに更新していく
ような方法にできないか考えています。とはいえ、なかなか良い方法が思い
浮かばないので、あくまで記譜集めしながら考えてみる程度ですが。

**535** · 2017/08/07(月) 22:11:24.15

うあああああ、だめだああああ
俺の才能は枯れ果てた
全然何もできない
一歩も進まない

**310** · 2017/08/07(月) 22:15:17.79

がんがれー。

自分も実をいうとかなり行き詰ってるけど、やれることを少しづつやってる感じ。
まあ、一回ソース全滅したの書き直すイベントのおかげで、リセットできたってのもあるけど。

**535** · 2017/08/11(金) 00:46:45.11

スレッドリッパー遂に発売ですね。
ベンチによれば1950Xに乗り換えればCPU性能は現状の３倍以上になりそうです。
うーん欲しい。

**310** · 2017/08/11(金) 17:12:37.06

自分の場合、何倍になるんだろ。単純に考えて１０倍くらいになるのかなｗ
まあ、アムダールの法則あるから、そこまではいかないだろうけど。
メモリーも、8Gだと遡り３０手あたりでスワップ始まるので、もう少しほしいなぁ。

最近、PC通販サイトを時々覗いています。
スレッドリッパーほしいですねぇ。

相変わらず遡りチェックの高速化を地味に実行中。
min-Max探索の並列処理は粒度が大きいので、待ち合わせロスが多くなりますが、
その辺を何とかしました。遡りチェックはヌルサーチにおけるベータカット検出がメイン
であるという点に依存しますので、普通の探索では使えませんが。

平行して確定石の計算作ってますが、なかなかうまくSIMD演算に落とし込めない。
しばし悩み中です。ただ、３０手遡りとかまで行くと、確定石を使ったアルファカットが
かなり効きそうなので、早くなんとかしたいです。

**535** · 2017/08/12(土) 22:58:25.64

確定石という言葉で思い出しましたが
ライフゲーム囲碁にも確定石という概念がありますね
やれる事が一個見つかりました

**310** · 2017/08/13(日) 23:11:58.30

確定石とりあえずできました。
自分の実装で３ステップあるうちの２ステップでSIMD化できましたが、
最後の１つはまだシフトとループの組み合わせです。

で、さっそく敵確定石数からアルファ値アンダー検出のカットロジックを
入れてみましたが、遡りチェックに入れると、途中でバグるという状態。
しばし長考が必要です。

というわけで、記譜集めに戻りましたが、こちらもランダム着手付
の探索で、稀に間違った着手をするというバグが出てます。こちら
も、しばし長考が必要かもしれません。

むむむ。

**310** · 2017/08/14(月) 23:05:49.41

記譜側のバグ取りしてました。
というか、ランダム着手部分を全面的に作り替えました。かなり簡単になりました。
が、テスト中に突然のあり得ないレベルの速度低下。
原因は、ふと並列探索にできる箇所を追加した事にありましたorz
丸一日大損です。

ついでに速度を調べていたら、ただの探索より置換表の方が遅いという恐るべき事態。
オーダリングもおかしくなっていましたので、ここも修正。

それでも、まだybwc探索と置換表探索の速度が変わらないという問題あり。

あちこちいじりすぎてわけわからなくなってます。むむむ。

**535** · 2017/08/17(木) 18:25:09.94

zenおめ

**310** · 2017/08/19(土) 00:06:36.46

なんか優勝したみたいだね。

強いAI同士で戦うと、ぎりぎりの攻防の結果、人間には穴があるように見えて
しまうのかも知れん、と、ふと思ったりして。

**535** · 2017/08/20(日) 19:27:44.87

盆休みはまるまるさぼってしまいました。
心機一転なにか始めたいなぁ。

**310** · 2017/08/21(月) 01:03:27.39

せっかくまともに動いていた記譜集めですが、つい直したくなって直していたら
バグ出る、速度落ちるで、さんざんでした。ようやく落ち着いたかな。
キャンセルメッセージ、再帰処理だと結構混乱してしまう。

最上階層でのβカットの際、キャンセル待ちでかかっていた時間を、ほぼゼロに
短縮しました。たぶん、タイムアップのキャンセル待ちも。ただし、まだ未検証。

とはいえ、まだ記譜数が足りないのか、評価値が安定しない…

**535** · 2017/08/22(火) 22:49:19.92

ライフゲーム囲碁と畳み込みニューラルネットは相性良さそうなイメージが湧いてきた
ちょっと調べてみるか

**310** · 2017/08/25(金) 00:10:43.60

スレッドリッパーいきなり値下げですね。秋冬ごろ狙おうかなぁ。

記譜集め開始したら、耐久テスト状態になってバグがちらほら。

ここ１週間くらいで直したところに原因がありました。またか。
困った事に、たまたまエラートラップに引っかからない事があるため、記譜が
全て正しいという保証が微妙な事。仕方ないので、記譜のチェックをしなきゃ
ならん…。

また、やけにおかしいと思っていた評価関数でも、問題が発覚でした。

**535** · 2017/08/30(水) 23:19:27.29

スレッドリッパー欲しいが40万円はおいそれと出せないなあ
冷静に考えると予算20万が限界だなあぶっちゃけ
畳み込みニューラルネットって何十枚もフィルター用意するんです？
計算時間メッチャかかりそうな？

**310** · 2017/08/31(木) 22:05:50.41

スレッドリッパー単体で１２万円くらいですからね。
CPUクーラーと電源頑張らないといけないから、それなりの価格にはなっちゃいますね。

畳みこみは３×３を基本にしても、アルファ碁で１９２フィルターの１２段構成とかです。
自分は今のパソコンでオセロの８×８に対して３×３の４８フィルタの２段構成で試して
みましたが、学習終わる気配がないので、ペンディング中です。

普通にMNISTの手書き数字認識は、しょせんオートエンコーダの３段とかなので、大した
時間もかからずにできちゃうんですけどねぇ。例題と実践のギャップがでかすぎ。

ただ、畳み込み演算自体は昔からあるもので、たぶんFFTとかでも同じような計算して
いるはずなので、しっかり勉強すれば、何か、計算速度アップの技がありそうな気は
しています。

デバッグ考えると、ハードで頑張った方が精神的に楽ですが。

**310** · 2017/09/03(日) 08:52:20.52

相変わらず記譜集め中。

オセロの読み切り処理の並列化は、粒度がでかくて、待ち合わせロスが大きいので、
CPUがアイドルしている時間が長く気になります。そこで、スレッド数をチェックしてコア
数を下回っている時は、リーフに近いところでも並列探索に戻るようにしてみました。
PPL機能ではスレッド数は取得不可能で、結局自分で増減カウントしました。

リソースモニター上ではCPU使用率が１００％近くに貼りついているいるので、待ち合わ
せロスはほぼゼロになりましたが、早くなったかどうかは未確認です（汗

**535** · 2017/09/04(月) 20:17:25.15

畳み込みニューラルネットの勉強なかなか進みません。
とりあえず、棋譜がなければなにもできないので棋譜取始めました。
質より量優先で１局４秒くらいで生成中。
明日の夕方まで回す予定。

**535** · 2017/09/05(火) 20:03:48.94

１６万局分くらい棋譜集まりました。質は期待できませんが…
そろそろCNNの勉強を本格的に進めなければ。

**310** · 2017/09/06(水) 00:21:57.37

乙です。

こちとら、またまた終盤探索にバグが見つかりまして。
２日ほど根つめてデバッグ。その間記譜収集停止orz

いつも出てくれればよいのに、同じ記譜でも３０回に１回とかのレベルで発現する
奴で往生しました。最終的にnull window search専用処理の置換表のどこかが
おかしいだろうというところまで追い詰めましたが、諦めました。時々異常に探索
時間がかかるのも、この処理が原因っぽかったので、やけになって削除。
すっきりしたかもｗ

なかなか強化学習までたどり着けない…

**535** · 2017/09/07(木) 21:19:23.25

集めた棋譜を統計取ってみましたが、初手天元が妙に少ない？
という謎の現象がおきたのですが、盤面の対称性を考慮してDBを作ったせいのようです。
天元は対称局面がないが、ほかの局面は対称局面があり、対称局面は合算されるため。

ていうか１６万局じゃ全然データ足りないかもｗ

**535** · 2017/09/07(木) 22:01:51.18

初期曲面から３手目まで位しか十分な数のデータがないっぽいｗ
１００万局にしても無駄だろうなぁ

**310** · 2017/09/08(金) 00:27:19.31

強化学習の準備始めました。
評価関数のファイル名決め打ちしてたり、staticだったりで、あちこち変えなきゃならん。

と、裏で記譜集めをしていたら、またまた問題が。
探索結果は合っているけど、逆順探索などで失敗。
用途の違う置換表を使いまわしちゃいかんという事の模様で、置換表クリアで対応。
mtd(f)で下から寄ったあと、置換表残したままもう一度上から寄せると、探索間違える
現象も確認。良く考えれば何が問題なのかわかりそうだけど、もう飽きた（汗
何回目の「これできっと大丈夫」なのかorz

>>943
局面数的には、全宇宙の原子数でも足りないかと…
特徴抽出と近似による汎化に頼らないと・・・

**535** · 2017/09/08(金) 23:05:42.67

>>944
特徴抽出ですか…
まあCNNぼちぼち頑張ってみますが、果たして成果出るかどうかかなり怪しいですね…

**310** · 2017/09/08(金) 23:49:16.12

昨夜いろいろ考えながら寝ていたら、あっとなりまして。

今までmin-maxな部分ばかりデバッグしてましたが、最初にバグに気付いた時に
並列探索かつ置換表な時に問題が起きると気づいていたのに、見るところ間違え
てました。置換表の更新のところで、２重更新の対策してなかった（汗

null window searchとか、冤罪だったんじゃないかと。
まあ、徐々に耐久テストしてみます。

**310** · 2017/09/11(月) 00:57:10.83

>>946は潜在的には問題になりえますが、関係なかったorz

都度都度置換表をクリアしながらなら問題が起きないようです。
でも、クリアしなければならない、そもそも今のトリッキーな高速化方法では
かえって低速になる事から、着手リスト作成箇所を全面的に書き直して
しまいました。

現在耐久テスト中。今のところ調子は良さそうです。

記譜集めちんたらやりすぎなので、ちょっと質を落として数を増やしてみます。

**310** · 2017/09/16(土) 22:09:05.96

このまま記譜集めしていても、必要分量まで集めるのにどんだけかかるかわからない
ので、悩んでいましたが、ふと思いつきました。置換表には、読み切り済の記譜が詰まっ
ていると。上限加減のタイプもあるので、全部ではありませんが、これを捨てるのは勿体
ないかなと。で、抜いてみました。２５手読み事に大体３０００局面の盤面と終局スコアが
得られます。

どういう局面が残るのかは、なんとも言い難いのですが、記譜の足しにはなるというか
結構な分量がたまるなぁという事で、これもとっておいて、再利用できるようにしてみま
した。置換表適用深さ分しかないので、限られてはしまいますが、分量的には結構に
なるので、利用を前提にしてみます。

**535** · 2017/09/20(水) 22:11:12.05

tensorflowやってます。

import numpy as nm
winrate=nm.loadtxt("WINRATE.TXT")　
boards=nm.loadtxt("BOARD.TXT")

WINRATE.TXTは読み込めるのにBOARD.TXTは読み込めない。
データがでかすぎるってことだろうか
さてどうするか…

**535** · 2017/09/20(水) 22:23:57.53

データ半分にしたら通った
まあしょうがないか

**310** · 2017/09/21(木) 20:15:32.64

tensorflowですか！
環境整備大変そうだと逃げてます。乙です。
速度感とか教えてください。

こちらは、ようやく強化学習の良い方法を考え付きまして。
とりあえずダミーとの対戦と学習部分までコーディングしてみたところ。
今夜デバッグして、強化部分のコーディングする予定。

rollout部で使用するのはあきらめました。
色々やっていたら、勝率も大事だけど、それよりツリー展開のドライバー
としての速度の方が大事だと言う結論に（汗

**535** · 2017/09/23(土) 19:53:23.58

なんか、3x3のフィルターは学習動くのに5x5のフィルターで学習させようとすると落ちる？
とりあえず、3x3のフィルターで進めてみます。

**535** · 2017/09/23(土) 19:55:53.86

tensorflow固有の問題じゃないかもですがとにかくメモリが足らんですね。
今のマシンは16GBなんですが、可能なら128GBくらい積みたい気分。
やはりスレッドリッパー欲しい。金がないけど。

**535** · 2017/09/23(土) 22:35:13.25

tensorflowに計算機占有されちゃうの意外と痛いですねorz
やはりスレッドリッパーしか…
でも金が…

**535** · 2017/09/23(土) 22:53:28.32

局面の勝率計算させてるけど今正解との誤差が平均0.14くらいっぽい
勝率で平均0.14違ったら使い物にならんじゃないのか？
うーん。

**310** · 2017/09/24(日) 01:20:18.11

並列処理すると、何使っても計算機資源占有されちゃいますよｗ
だからGPUに逃がしてCPUを空けようとしたりするんですよね。

最近扇風機で冷やすようにしてますが、扇風機無しだとクロック数が８０％以下まで
下がってしまって、そういう時に限って、読み切り処理でバグがあるような結果が出て
います。理屈ではありえないんだけど。

スレッドリッパーでもi-7900Xでも、CPUの温度対策は大事になると思います。

**310** · 2017/09/24(日) 01:47:25.30

強化学習は、適当にコーディングして結果からデバッグしているので時々不安になり
ますが、それなりに学習してくれているみたい。学習内容は同じく勝率で、これをアル
ファ碁で言うところのポリシーに使用してます。

強化学習のポリシーを導入した事で、遡りチェックも調子よく遡るようになり、最善手を
指している率が上がったように感じています。しょせん強化学習だし、まだ学習しはじめ
なので、精度は高くありませんが、使い方次第ではいける感じです。

強化学習続けたら、定石DBの代わりになるんじゃないかと期待。

しばらく学習フェーズになりますが、次はロールポリシーを改良したいかな。

**535** · 2017/09/24(日) 18:11:33.99

損失がこれ以上下がらなそうなところまで来たので、
AIに組み込んでみようと思ったのですが、
tensorflowでの学習結果をどうやってC++にもってくればいいのかよくわからないというｗ
とりあえずググってみますが、見つかるかなぁ？

**535** · 2017/09/24(日) 20:00:11.56

C++にもってくるの現状そんな簡単じゃないっぽいorz.

**535** · 2017/09/24(日) 23:27:13.26

windows上でtensorflowをコードからビルドとかマジすか？

**310** · 2017/09/24(日) 23:40:11.06

ウェイトデータをバイナリで持ってきて、フォワード計算を自分で書くってのじゃダメ？
パッケージに任せたい面倒くさいところって、バックワード部分だから。

自分の場合、mctsで並列処理していて、使用している行列パッケージのEigenも並列
計算していて、両方で並列化しちゃうとスレッド取り合って劇遅になっちゃうし、Eigenを
シングルスレッドで動かす時のオーバーヘッドが気になったので、AIで使用する時の
フォワード計算は自分で書きました。

**535** · 2017/09/24(日) 23:49:44.98

うーんそれが一番妥当ですかね～
ありがとうございます。
でもバグなく書けるか若干心配ｗ

**310** · 2017/09/26(火) 00:08:03.06

強化学習、ずっと学習続けていると、途中で弱くなっていく。
アルファ碁のやり方をまねていたけど、一旦超シンプルな方法に変えてみて、
とにかく施行回数を増やしてみます。

強化学習を使って、序盤の評価関数が作れないか検討開始。

あと、時々出ていた終盤探索のバグ。
今度はたぶん大丈夫だと思う。
何度目の大丈夫だって状態だけど（汗

**535** · 2017/09/26(火) 00:31:24.69

学習率って何気に大事なパラメータですね。
速度がかなり違う。
もっと大胆に攻めた値にすべきかな？

**310** · 2017/09/27(水) 10:06:01.04

学習率は大事だけど、今時はRMSPropとかADAMとかで
自動計算にしちゃうんじゃないの？

**535** · 2017/09/27(水) 21:24:40.34

詳しいことはよくわかりませんが、最適化の関数名はAdamOptimizerとなっているのでそうなのかもしれませんね。
学習率のパラメータ渡すところも引数省略可能っぽいですね～
自動計算のほうがいいんだろか？。
参考にした本には学習率設定してありましたのでマネしました。

**310** · 2017/09/29(金) 10:10:45.06

それならAdamですね。Tensor Flowなら当たり前ですね。
学習率ってだけだったので、Optimizer無しの学習率だと思いました（汗

省略時引数はたぶんモデル発表者の提示した推奨値です。
まあ、パラメータをいじるかどうかは、個々人の好みとい事で。

**535** · 2017/09/30(土) 19:50:26.02

フィルターの数も多けりゃ多いほど誤差が減るって単純なものでもないみたいですね。
多すぎると最適化が収束しなくなるっぽい。

**535** · 2017/09/30(土) 20:37:24.31

パラメータいじりの沼にはまりそうorz

**535** · 2017/09/30(土) 20:50:21.36

メモリ！メモリが足らん！

**310** · 2017/09/30(土) 23:21:48.52

フィルタ数は大きければ大きいほど良いのですが、学習に必要な時間が恐ろしく
長くなります。十分に多いフィルタ数で収束できる事を確認したうえで、だんだんと
減らして行くなんて作業になります。段数についても一緒。

ロースペックマシンだと１回試すのに下手すると数週間とかあり得るのです。
かといって、精度が出せないレベルの簡素なモデルで試しても、いつまでたって
も収束せずに、まだかなみたいな。モデルの複雑さが足りているかいないかが
わからない点が、困ったちゃんなのです。

さて、強化学習ですが、なんとなく学習しているようにも見えるし、最適解の周囲を
振動しているようにも見えます。ふと思い付いたのですが、最適化（SMORMS3って
奴を使用）をやめて、ただの学習率（もしくは、学習率の漸減）にした方が、動きが
素直になって良いのかも。

今のスピードは１時間に１００万対戦。１億対戦するのに４日強かかるわけで。まだ
試行回数が足りていないかもしれないし、そもそもただの線形ではモデルが簡単すぎ
るのかもしれません。

というわけで、CNN使わずに線形でやっても同じ問題が起きまするorz

**310** · 2017/09/30(土) 23:46:13.87

フィルタ数は大きければ大きいほど良いのですが、１回の学習に必要な時間が
フィルタ数に比例して長くなります。十分に多いフィルタ数で収束できる事を確認
したうえで、だんだんと減らして行くなんて作業になります。段数についても一緒。
これ、１サイクルの計算時間の話なので、収束しやすさについては、複雑さが
増すとさらに時間がかかる可能性あります。

ロースペックマシンだと収束できるか確認するのに下手すると１か月とかあり得ます。
かといって、精度が出せないレベルの簡素なモデルで試しても、いつまでたって
も収束せずに、まだかなみたいな。モデルの複雑さが足りているかいないかが
わからない点が、困ったちゃんなのです。

さて、強化学習ですが、なんとなく学習しているようにも見えるし、最適解の周囲を
振動しているようにも見えます。ふと思い付いたのですが、強化学習に限っては、
最適化（SMORMS3を使用）をやめて、ただの学習率（もしくは、学習率の漸減）に
した方が、動きが素直になって良いのかも。

今のスピードは１時間に１００万対戦。１億対戦するのに４日強かかるわけで。まだ
試行回数が足りていないかもしれないし、そもそもただの線形ではモデルが簡単すぎ
るのかもしれません。

というわけで、CNN使わずに線形でやっても同じ問題が起きまするorz

**310** · 2017/09/30(土) 23:46:51.18

あれ、２度書きになってしまった。
しかも内容が微妙に違うｗ

**310** · 2017/10/02(月) 22:13:03.03

いやぁ、またやっちまった。
バリューの評価値計算が間違っているの気が付いて、リセットしようとしたら、
間違えてポリシーの強化学習の方をリセットしてしまった。またやり直しです。

ちなみに、ただの学習率ってのSGDですね。ようやく思い出した。

ついでなので、若干パラメータ変えて強化学習再開。
時間あたり試行回数は減るけど、トータルで少しは学習が速くなるはず。

**535** · 2017/10/04(水) 21:07:28.40

CNNのフォーワード計算自前で書くの結構面倒くさいなぁ。
バグなく書けるかも心配だし。
うーん。
ここで足踏みしてます。

**310** · 2017/10/04(水) 22:00:17.02

オライリー本のゼロから作るDeep Learningって本ではPythonでのコードが載ってた
けど、畳み込みのところをim2colとかいう関数で展開して、行列計算に落としこんでた。
im2colのソースを探したけど、見つからなくて放置してますが、あれが常道だと思います。

**310** · 2017/10/05(木) 22:33:23.90

ポリシーの強化学習、遅々として進んでいます（汗
時々、テストでMCTS動かしてポリシーの学習値を見ているのですが、
学習対象の全４８手のうち、後ろ１２手分くらい、それっぽく濃淡がついてきてます。
このまま続けたら、もっと前の方まで学習してくれると期待しているのですが、ここ
からが分岐が多い箇所なので、どれくらい時間がかかるか想像がつかない。

で、ポリシーの強化学習の結果を使って、バリューの方も学習させていたのですが、
やはり無理がある事に思い至りました。バリューはバリューで別途強化学習をさせ
ないといけない模様。どちらかというとバリューの方が大事なので、このままポリシー
の学習を続けるか、一旦棚上げしてバリューの方に乗り換えるか、悩み中。

学習中のポリシーをMCTSに組み込んだところ、速度低下が著しい。メモリーのランダム
アクセスが原因だと思う。速度アップネタをいくつか模索してみたいと思いますが、
変更が重いので、いつやるかこちらも悩み中。