前スレ
【オセロ,将棋】ボードゲーム【囲碁,War】
ttp://mevius.2ch.net/test/read.cgi/gamedev/1057763418/
とりあえず、スレたて乙です。
とりあえずvec_tというのが何者かわからないorz.
強化学習ですが、まだまだ時間がかかりそうで、業を煮やして学習率あげたら、
バリューが発散してやり直し（汗
ちょっと工夫を加えて、強化学習を数回したら、MCTSで自己対戦して記譜作成。
記譜を見て学習の進捗を計りながら、過去に採取した記譜で軽く教師付き学習
させて、学習の方向性を補正しつつう、後半部分の精度を少しづつ上げて、強化
学習がはかどるようにしようとしてます。
というわけで、純粋な強化学習ではなくなってしまった。
新スレだし310,535を名乗るのもなんですね…
日本語紹介記事
ttp://https://qiita.com/nyanp/items/11c6bb6fb539486c5069 作者の実装ノート
ttp://https://github.com/tiny-dnn/tiny-dnn/wiki/%E5%AE%9F%E8%A3%85%E3%83%8E%E3%83%BC%E3%83%88 英語
ttp://https://github.com/tiny-dnn/tiny-dnn/wiki ttp://http://tiny-dnn.readthedocs.io/en/latest/how_tos/How-Tos.html こんなの見てました。
vec_tについては、３番目のwikiのData-Format
＞
ttp://https://github.com/tiny-dnn/tiny-dnn/wiki/Data-Format に、vector<double>であると書かれています。
なんちゃらparserってのは、外部のデータをtiny_dnnの内部形式である、
vec_tやlabel_tに変換するユーザ関数で、用途に合わせて自分で書かなけ
ればならないものです。入力データが２次元であっても、左上から右下に
一列のベクトルとしてセットして、縦横の情報はレイヤー定義で与えます。
読んでみます。
先延ばし先延ばしにしてしまうorz.
自己対局の強化学習のみだそうな。
レート５０００越えだそうな。
囲碁AIやらなくてよかった・・・
宇宙やばいってレベルじゃねーぞ？
現在出張中なので、論文ダウンロードを躊躇しているけど、読みたいなぁ。
自分のオセロでは、スピードを稼ぐためにRolloutにヒューリスティックスな次の１手
を使用しているけど、自己対戦見ていると序盤良い感じで来ていると、Rolloutが間違
えて、負け手順に入る事が多い。それで、Rolloutせずに（したふり）Valueの遡りだけ
でQ値を計算したらどうかと思っていたんだけど、そういう事なのかなぁ。Rolloutを
省略しちゃうと、ものすごいスピードアップするので、探索が深くなるんだよなぁ。
先にやっちゃえばよかった（汗
どうせ2人しかいないからわかるっちゃわかるけどｗ
Rollout無し版を試してますが、何故か最近静まっていた終盤読み切りのエラーが（汗
撲滅していたはずなんですが・・・
修正かけていた評価値の誤りがダイレクトに出て、読み間違いは相変わらずです。
強化学習が進めば治るはずですが、SGDでは遅々として学習が進まないので、
optimizerをSMORMS3に戻して、一旦記譜学習を増やしてみました。やはり学習速度
が圧倒的に違います。そして、このやり方でも大丈夫っぽいです。
どうも遠回りしていたようです（汗
パッと見、すごくよさげに見えるのに全然前に進めない。
なんだろう…なんだろう…
局面の勝率を正解にしたい場合はどうすればいいんだろう？
ラベルと勝率じゃデータ構造違うよね多分？
それとも同じなんだろうか…
mnistは、分類器（他クラス分類）なので、活性化関数はsoftmaxになり、教師データ
はlabel_tで与えます。別にvec_tでも良いですが、例えば３という答えに対して、
label_tは{3}なのに対し、vec_tは{0,0,0,1,0,0,0,0,0,0}などとなって冗長なので、label_tが
用意されているわけです。他にも、誤差の計算方法が違うなんてのもあります。
一方、ゲームの勝敗予想は２値分類問題なので、活性化関数はsigmoidで、教師
データはvec_tとして、勝利を{1}、敗北を{0}として与えて学習させます。
オセロには引き分けがあるので、引き分けは{0.5}としてみましたが、勝率５０％と引き
分けでは意味がまったく違うのが悩みの種です。２人ゼロ和完全情報ゲームでは
勝率５０％というのは理論上存在しないのですが、強化学習の途中などでは生じます
からね。
なお、tiny_dnnでは２値分類や回帰の学習には入力データも教師データもともにvec_t
で与えてfitを用い学習します。mnistのような他クラス分類でlabel_tで教師データを与え、
学習をする時はtrainを使用します。
○ 多クラス分類
ですね。IMEのアホたれ（汗
trainの代わりfitってのがあるんですね。
ドキュメント読もうとしても英語ということを差し引いても
気が散っちゃって目が滑っちゃってどうにも駄目です。
試してみます。
説明がfit中心になりがちです。
つか、僕もかなり目が滑りました（汗
ネットワークの形が不整合起こしてるのかなぁ
入力の形がおかしかったみたい。
完全に意味不明
なんなのｗｗｗ
もう寝る
でも落ちた記憶はないかなあ。
ttp://http://tiny-dnn.readthedocs.io/en/latest/how_tos/How-Tos.html#handle-errors この辺の参考にしてcatchしてエラーの内容表示してみました？
ツリーの深さが５０手まで達してしまいまして、今度はスワップとの闘いに
なりつつあります。探索幅をケチればスワップは回避できるのですが、
そうすると読み漏れが・・・。
８ギガ程度じゃこの速度を活かせません（汗
お分かりの通り、今のところ名無しは310です。
bad allocation
だそうです。
いまはmain全体をtryでくくっているのでどこで例外が出ているのかよくわからないですね。
まずはそこの絞り込みですかね。
盤面のデータがでかすぎるってことみたいですね。どうやら
解決したみたいです。
ありがとうございました。
助かりました。
64bitでコンパイルしたら正常に動いたみたいです。
何を間違えてるんだろう？
も〜ムカつく。
マルチスレッドに出来るのかな…
もう今日は寝ます。
最初に十分に深くして学習させて、だんだん減らしながら適切な深さを
求めたいんだけど、この速度低下を考えると、本当に学習できるのか
わからないままだんだん深くしていくしか無いというのが萎える点です。
スレッドについては、リソースモニターで確認するとわかりますね。
ヘッダのどこかに並列化の設定があったはずです。
コンパイラがVSならOpenMPのオプションを設定します。
コンパイラのオプションの方もOpenMPの設定をお忘れなく。
あと、エポックが進んでも損失が変わらない原因がさっぱりわからないorz.
畳み込み層外したら損失減った。
ヘッダの話、Eigenとごっちゃになってるかも。
強化学習ですが、徐々に進んでいます。もっと早くSMORMS3にしとけば良かった。
終盤読み切りのソート順に評価値を使用しているのですが、目に見えて速度が
上がってきています。また自己対局の精度も上がってきたようで、遡りチェックで
３０手まで何度か行きました。逆に記譜収集の方は、スコアのばらつきが無くなって
きて、記譜的に良い事なのか不安。
というわけで、手ごたえを感じつつ、現状に合わせて若干設定変更。
まあ試しに全結合で進めてみるか。
そういえば、ライフゲーム囲碁はDBつかっても強くならないんだったｗｗ
囲連星に転進するか…
学習しないな俺ｗ
マジでスレッドリッパーに128GB積みたい気分
でも遅いな〜こりゃそう簡単には終わらんぞorz.
まあ今晩一晩流してみますが…
あ、元データはランダムに並び替えた方が良いですよ。
わかってると思いますが。
こちらは、しばらく強化学習していたら、それなりに学習が進んだ結果、
対戦相手側の手のばらつきが足りなくなって、局所解に陥ってた感じ。
急きょばらつきを広げて学習再開させたところです。
バリューの方は地道に損失が減っているんだけど、ポリシーの損失が
増えてきた。ポリシーはsigmoidがあるので、ウェイトが絶対値でとてつも
なく大きくなって、なかなか修正しきれない状況になってるかもしれない。
一旦リセットすべきか悩み中。
これはかなり厳しい
でも今のネットワークでも損失が減っていかないところを見るとそれも望み薄かなぁ
「特徴抽出しながら」誤差修正していってますから。
僕と同じ悩みですね。
ネットワークの大幅簡素化の結果、最終的に線形回帰まで戻ってしまいました（汗
もっとも、オセロはBuroさんの特徴抽出があったから線形回帰まで戻れたのですが。
スリッパとGPUが呼んでます（笑）
でも、もしかしたらAMDよりINTELの方が良いかもしれない。
高いけど。
１エポック６５０秒位。
損失はあんまり減っていかない。
うーん。
買うとしてもZen+まで待ちます。
くそ〜どうすりゃいいのさ
入力のサイズがでかいのは確かにあるけど。
これで一晩回してみるか
ここでもパラメータいじりの沼か。。。
学習が足りないだけなのか根本的に無理筋なのか。。。
次の一手予想のほうがいいんだろか？
うーん。
畳み込みに賭けるか…
後はどれだけ損失が減ってくれるかだな…
こちらは、MCTSで構築したツリーを使って、完全読み切りが速くならないか
試していますが、謎のバグのオンパレードでかなり戦線縮小。一応、それなり
に動作するレベルまで撤退してテストしていますが、なんとなく速度アップは
している模様。
ただ、バグの過程で置換表データに変なものが混じったらしく、学習させると
異常終了になります。記譜は１７００件くらい集まっているので、一旦全消去して
しまいました。
けど、カーっとなって即座に終了してしまったので、詳細判明せず。
なんとなく症状は見えたので、しばらく目視デバッグします。
というか、これにより直近に遡りチェックやった記譜の正確さに不安が生じてます。
やけに遡りチェックが簡単に通るなぁと思っていたけど、これが原因かもしれない。
というわけでタイムアウトまで行った記譜を５０件ほど再チェックしなきゃならん。
全部で５４時間くらいかかる予想。今週はまるまるパーになりそうです。
その分、良質な置換表データが補えるんだけど。
くそ〜ディープラーニングからは一時撤退するか…
バグって、記譜データがすべて上書きされて消えてしまったorz
ツリー利用探索のデバッグ用にput処理にエラートラップ仕掛けた時に
やっちゃいました。
学習済のデータが残っているのだけが救いだ・・・。
ここから記譜作ると、そこそこ精度が良い記譜になるはずなのが救いだ…。
一回コード全飛ばししてるでしょうに。
でも論文読んでもわかんねぇだろうなぁ
ていうかGoogleがライブラリとして公開してくんねかなぁｗ（他力本願）
おっしゃる通りですorz
評価関数の方は要所要所でコピー残していたのに、記譜はなめてました。
ライブラリ公開されても、実行できる環境構築の方がハードル高いかなと。
論文はいまだに読んでいませんが、rollout無し（バリューネットに１００％依存）
はうまく機能しています。圧倒的にツリー探索性能がアップしているため、評価関数
の精度の低さを、力技でカバーしている感じですが。
とはいえまだ３０手以前の評価値はでたらめに近い状態なので頻繁に間違えます。
強化学習でここまで治るのにどれくらいの時間がかかるのかは不明。後ろの方の
精度が上がらないと、前の方は間違った学習を繰り返すことになりますので。
後ろの方の評価関数がそこそこまともになったので、読み切り処理や遡りチェックの
時間はかなり早くなりました。タイムアウト１時間設定で時々空白３１マスまで遡れる
ようになってきています。
囲連星の序盤のDBは非常にうまく動いてるので、
終盤もDBを生かせないか検討中です。
それと同時にLV3 vs LV3の棋譜取も再開しました。
データは多いほどいいので。
あと310さんの遡りチェックというワードが気になってます。
例えば囲連星の終盤DB作るときにどこから勝負ありの状態になったか
チェック出来たらどうだろう。とか考えています。
９段に５子置きで勝てましたが４子で勝つのは相当厳しそう。
天頂６より「あ〜そこ大きそうだよね」ってところを的確に打ってくるみたいです。
データが終局までの手数しかないのがまずいのかも。
ポナンザは優勝ならずみたいですね。
終盤DBといえばチェスですかね。
遡りチェックは詰みを回避できるかチェックになるのかなぁ。
オセロだと何にも考えずに終局の石差でやっちゃうので。
言われてみて気付いたけど、ゲームの種類によって結構違う考えが必要なんですね。
最近、藤井四段に触発された友人の影響で将棋を始めました。
負けたくないので、３手詰め問題解いていると、どうやってプログラムしようか
とか雑念が沸いてきてしまいます（汗
が、なんか別のところで意味不明の動作をして、速度が出せませんorz
また、テストの際に半日経っても終了しなかった盤面を使ってしまい、
何度もやり直しをしていたために、強化学習が滞ってしまいました。
これ曲者過ぎるので、今夜一晩解かせてパスしたい。
朝までにとけなかったらどうしよう。
思ったよりってだけで弱いことは弱いけど。
やっぱ弱いわｗ
勝負が十数秒でつくのは面白いけど。
MCTSの速度が出ない問題は、解消というか、原因不明のまま別の方法で回避。
parallel_forの問題かと思っていたけど、shared_ptrの方の問題だったっぽい。
遡りチェックの時、PVは探索せずに、その他の手をチェックしていくので、他の手
にも探索を振り向けたかったのですが、単純に１手先の局面からUCTを実行すると
１０万プレイアウトくらいで突然数十秒宇固まったようになって、それを何度も繰り
返す結果、まったくツリー探索が進まないという症状です。UCT探索の方に１回目
だけランダムに着手する関数を作って、そちらを呼び出したところ、固まらなくなり
ました。
ようやくまともにツリーをオーダリングに再利用できるようになったのですが、要所
要所で極端に探索が遅くなって、逆に時間がかかります。
今しばらく調査が必要な模様。
70局目
黒(airandom.dll)の勝利回数: 29
白(ai-lv2.dll)の勝利回数: 41
61局目
黒(ai-lv2.dll)の勝利回数: 53
白(airandom.dll)の勝利回数: 8
58局目
黒(airandom.dll)の勝利回数: 18
白(ai-lv1.dll)の勝利回数: 40
46局目
黒(ai-lv1.dll)の勝利回数: 26
白(airandom.dll)の勝利回数: 20
311局目
黒(airandom.dll)の勝利回数: 97
白(ai-lv2.dll)の勝利回数: 214
275局目
黒(ai-lv2.dll)の勝利回数: 237
白(airandom.dll)の勝利回数: 38
259局目
黒(airandom.dll)の勝利回数: 114
白(ai-lv1.dll)の勝利回数: 145
213局目
黒(ai-lv1.dll)の勝利回数: 144
白(airandom.dll)の勝利回数: 69
アルファ碁Zeroでは、強化学習に軽い探索を取り入れたというのを見かけたので、
想像で真似してみる事にしました。
序盤はランダム着手。そこから５手読みの中盤探索を入れて、残り１０手完全読み。
評価関数はValueを使用。たぶん、学習はマシになると思います。
もっと精度が上がったら、３手読みにしてスピードアップしたいです。
今はまだ結構ボロボロなので、これで我慢。
1000局くらい軽くいくだろうと思ってたけど意外と時間かかってますね。
これはこの辺にしておきます。
533局目
黒(airandom.dll)の勝利回数: 175
白(ai-lv2.dll)の勝利回数: 358
475局目
黒(ai-lv2.dll)の勝利回数: 407
白(airandom.dll)の勝利回数: 68
450局目
黒(airandom.dll)の勝利回数: 198
白(ai-lv1.dll)の勝利回数: 252
365局目
黒(ai-lv1.dll)の勝利回数: 252
白(airandom.dll)の勝利回数: 113
学習の速度が明らかに上がったし、精度も良くなっているようで、テスト盤面の
誤差が結構減りました。ただ、そろそろ飽和したか、局所解に入ったような印象。
で、色々考えたあげく、線形回帰ではこの辺が限界かもしれないという事で、
評価関数をmlpにしてみました。valueの方がうまく学習しなかったので、回帰型
ではなくsigmoid出力にして０〜１の数字を石差に変換かけてます。
強化学習は、回帰版の評価関数の結果をそのまま利用してます。
そろそろそこそこ使えそうな誤差になってきたようだし、強化学習は自分に対して
行った方が良いはずなので、全面的にmlpに移行しちゃおうか悩み中。
モンテカルロは確かにある程度強さ出せるけど
遅いのどうやって克服していいかわからんし。
悩ましい。
モンテカルロですが、評価関数ができたら、アルファ碁Zero方式で（汗
緩やかに読み筋を絞り込みながら、有望な手を深読みする形になります。
mlp版を試していますが、中間層を６４にしたら、学習は良いのですが、
モンテカルロが劇遅になりました…。今、中間層８で強化学習していますが、
なんか早々と線形回帰と同様に飽和状態になってしまった模様。
速度的には８が限界な気がする。
途中まで線形回帰の強化学習記譜で学習させていて、同じような癖がついて
しまったのかもしれないので、今晩一晩まっさらから学習させてみようかな。
学習がいまいち変に感じていたのは、これは恥ずかしくて言えないレベルの
仕様ミスでした。あれ？と思って、良く考えずに念のため追加したコードが
数か所。ことごとく悪さしていました。
数日損をしたなぁ。
評価関数に入れるデータの変換テーブルに間違い見つけた。
評価関数がいまいち収束しなかったのはこれが原因かも。
もともとの線形回帰版の時代から隠れていたものなので、
線形回帰版も計算し直しです。
というわけで、数日パーどころか１か月単位でパーですorz
幸い、記譜が６０件＋遡り時の訂正前分１００件ほどの合計１６０件と、
置換表から拾ったものが１０万件単位でありますので、最近得ていた
感触だと、これをベースに強化学習で補えそうだというのが、
唯一の救いです。
全てが理想的すぎる。
まあ必要計算資源があれですが。。
かといってネイチャー買うのも金もかかるし読んでも多分理解できないからなぁ。
でも終盤DBとかやってても全然成果あがらなさそうだし生きてて辛い。
何か参考になるだろうか？
自分はDeep Learningのところは「しかと」しているので、MCTSの進化形として
とらえてみると、まあ想像ですうが、当たり前の事を当たり前にやっただけかなぁ
と思っています。
それより大問題が…
また、評価関数の入力データ作るための変換に間違いを見つけてしまいました。
前回どころではない大きな間違いで、良くこの評価関数でそこそこ収束していたなぁ
というレベルの間違いでした。ソース喪失して書き直していたところから仕込まれて
いたんだと言う事で。
なんか入力いい加減でもそこそこな評価関数ができちゃう事にびっくり。
今度こそ大丈夫と信じて・・・
アルファ碁zeroの強さを再現するのに1700年トレーニングしなきゃならんとかｗ
は〜絶望するわ。
まあ、まったくの無駄になるとは思わないけど。
ソース喪失後焦って数日でパーッと書いて、そのまま学習させて、そこそこ
収束していたから放置していたのを思い出してきた。今度は全部チェックした。
しかし、いい加減な評価関数でも、結構収束していたってのが凄いな。
そこはかとなく表現力不足を感じていたのはその辺が原因かなぁ。
記譜と置換表データで１から学習させるのに、一気に５００回学習させたら、
思いっきり過学習になってしまった。現在、強化学習で解きほぐし中。
回帰の方はほぼほぐれたけど、MLPの方はまだ時間がかかりそう。
某スレをウォッチしていたら、前から気になっていた事を指摘していた人がいた。
スレッドリッパーはAVX2命令の中に遅いものがあって、一つ下のインテルの奴の
方が、この手の計算は速いらしい。
あと、GPUをどう使うかだね。
けど学習だけならTensor Flowにやらせちゃえばよいのだろうけど、学習データを
使うところまで行ったら、GPU使った非同期並列処理とか考えなきゃならないし。
CUDAだっけ？GPU専用にコード書かないといけないし。
なんか道筋というか、そこまでやってる自分の姿がイメージしきれない（汗
その前に詰将棋を解くプログラム開発してそう（笑）
GPGPUはもうちょっとハードル下がってほしいですねぇ
CPUよりも何十倍も速くなるケースもあるらしいし興味ありますね
CUDAをごりごり書くのは難しそうですがライブラリとかに期待。
この１か月くらいのカキこのどこかにありました（汗
９路なら序盤DBだけで押し切れそうな気がするｗ。
もう一度まっさらな気持ちになって…
めんどくさくなってすぐ昔のコード確認しちゃうｗ
駄目すぎるｗ
書き直しの時は、たいていあちこちで使用しているクラスの構造変え
たりする類の後戻りが難しい変更加える時なので、中の関数は一緒です（汗
新しい評価関数は、だいぶ落ち着いてきましたが、遡り２８手くらい
でタイムアウトになります。並べ替えに使っているので精度が上がる
と速度が速くなるのです。前は２９手、調子が良い時は３０手くらい
まで行っていたので、まだ精度が追い付いていないみたいです。
これでしばらく強化学習の具合見ながら待つだけになっちゃいました。
５×５の囲碁くらいならCNNで評価関数作れないかなぁとか、詰将棋を
作るならBitboardを２バイトに拡張しなきゃとか、悪い虫が疼き始めて
います。
最適化するな。アルゴリズムを考えろ。
アルゴリズムなら桁単位で速度アップし、過去に行った最適化は無駄になる。
と言うよな事がトップに書いてあって、それ以来（自分の）読みやすさ優先にしている。
BITBOARDのAVX2命令とか、その辺でいくつかの関数のみ、ゴリゴリにしている。
とはいえ、その辺も一応アルゴリズムの範疇かなぁ。
演算子のオーバーロードとか関数で隠ぺいしているしね。
問題は、最初にクラスの構造とかあんまり考えてないので、あとでごちゃごちゃに
なってしまう事。それで何度か書き直ししている。
アルゴリズムでの改善が行き詰まると結局泥臭い最適化に手を出すことにｗｗ
すでに一回実装したことのあるプログラムだしある程度勘所というか見通しは立つかなーと
言ってもしょうがないけどｗ
タイムアウトなどでキャンセルしたとき、探索途中の中途半端な評価値の置換表
が作成されている模様。対象の特定はできないため、置換表データをいったん
削除して、全データに対して再度遡りチェックを実施する事で、置換表データを
再作成する事にしました。
むむむ。
評価関数はそれなりの精度になっているので、それなりの速度ではチェックできる
はずですが、またしても…って感じでがっかりです。
同一評価値で変化がある分、記譜は多少は膨れるはずなので、そちらに期待。
ここからどう展開するか。
もっとも誤着手なしタイムアウト無しだと３０手だろうと遡れちゃうから、２８手あたりの
適度なところで止めちゃいましたが。
で、置換表データ激減。いままで間違ったものを相当学習に取り込んでいたっぽい。
あと、MCTSのツリーの末端（以後終盤探索しているので数値確定）の評価が時々
狂う問題がありまして、いつもではなかったので目をつぶってましたが、暇だった
ので着手。原因不明なれど、二重更新問題っぽかったので、ツリー部分のコード
を整理してみたところ、何故か治ってしまった模様。
本当に直っていたら自己対局の精度も少し良くなるはず。
つか、羽生永世７冠誕生ですね。
記譜みてみましたが、何が何だかわけわからんけどｗ
かなり時間がかかるので、新しいパソコンが欲しくなってきました。やはりCNNに行く
しかないかもという事で。
ものは試しにi9-7980でパソコン組んだら幾らになるのか、ネットで見積もってみた
のですが…そっと閉じてしまいました（汗
クロック数とか見ると、１０コア２０スレッドくらいの奴が、一番よさそうな気がするんだ
けど、どうなんだろう。
GPGPUも考えられるし。
夢想段階にあったものをことごとく圧倒的な力量でやられてしまふ。
そのうち、５分でオセロ作ったよとか言われるんだろうなぁ。
学習と評価の実行が完全に二分された今となっては、
学習に使用するハード性能は正義だと思い知らされる。
必要マシンパワーがあれですが、ムーアの法則が解決するでしょう。
囲連星とライフゲーム碁を学習させたいｗw
何日かぶん回そう。
関数さえ作れれば万能なように、完全情報ゲームでは万能だと思う。
あと強化学習による評価関数の作成も。
ただ、まだAlpha碁Zeroの論文読んでないからわからないけど、CNNの入力
については、人間が介在しているかもしれない。少なくともアルファ碁の段階
では、ちょっと特殊な入力データを用意していた。
それと、完全情報ができない以上、強さの地平線を広げたに過ぎないのも確か。
それを実現するために圧倒的なマシンパワーを使っているわけで。そのマシン
パワーを前提に、それを完全に活かせるアルゴリズムにしたってところが、評価
ポイントなのかもしれない。
かなり悔し紛れな評価だけどorz
相変わらず学習しない俺ｗ
しょうがないからDBに入れるのは序盤だけにするか。
前から思っている事をボソっと書いとく。
十分に深いDCNNの場合、表現の自由度が高いから、強化学習を繰り返す
事で過学習になる事が、起こりうる局面の大半を内部に保持する事につな
がっていて、実は汎化性能ガン無視で良いのではないか。起こりにくい局面の
評価値はグチャグチャでも構わないという事で。
と思っていたりする。
しょうがないから１プロセスだけで流すか。
これは致命的な欠陥だなぁ。
どうしよう？
諦めて今日は寝よう。
変だと思ったｗ。
でも対称局面合流させちゃってるから親が一意にならないな。。。
どうしよう。。
それこそ修正に指数的な試行が必要になっているような…
それはそうとして、メモリが欲しいですねぇ。1TBくらい
地力で脱出してくれないかな〜
大変です（汗
今晩一晩耐えられるかは微妙なラインだなぁ。
かなり学習いい感じで進んだと思ったのに、公式AIに全く歯が立たない。
やっぱ読めてない局面に分岐されると無力なのかなぁ
期待が高かっただけにガックリ。
分岐点やな。
ロールアウトで当たりの石を抜く確率と当たりの石をつぐ確率増やすか。
最終的にはアルファ碁みたいに100戦100勝したいな。
(
;FF[1]GM[1]SZ[9]
;B[de];W[dg];B[ef];W[cc];B[eg];W[fd]
;B[ec];W[eh];B[ed];W[ch];B[eb];W[fe]
;B[ee];W[ea];B[fa];W[hh];B[da];W[ac]
;B[ea])
8近傍求める関数間違ってたｗ
何が起こってるんだ…
だからか。
これで局所解抜けてくれればいいが…
何回かやり直したけど、結構簡単にNaN地獄に落ちるので、一旦仕切り直しで、
線形回帰な評価関数に注力する事にしました。
MCTSでテストすると、途中まで割と見知ったオープニングになってきているけど、
評価値自体はあんまり安定していない感じ。まあ、相対関係があっていれば、
絶対値はずれていても関係ないといえば関係ないけど。
しばらく強化学習を続けながら、ちっと別な事を考えてみます。
というか、Alpha Zeroの強化学習の回数が、思ったより少ないなぁと思ったけど、
自分がこれまでにやった回数を概算で考えてみたら、桁が２〜３くらい少なかったorz
やっぱマシンパワーは正義だなぁ。
zen+が超絶スペックという噂が流れてますが、デマリークともいわれていて、
本当だったらいいなあと思っている今日この頃。
DBがTXTで1GB行っちゃったてへぺろ。
これの凄さが分かってくれる人がどれだけいるかわからないが…
(
;FF[1]GM[1]SZ[9]
;B[ee];W[eg];B[df];W[fd];B[dc];W[dg]
;B[fe];W[ge];B[gd];W[gf];B[fc];W[cd]
;B[ed];W[cc];B[cg];W[ch];B[bg];W[fg]
;B[gc];W[gh];B[bh];W[hh];B[ai];W[ba]
;B[fd])
とりあえずバグとらなきゃorz
はたまたまかorz.
現実的な線でいってもメモリ64GBくらい積みたい。
でもMCTSのマルチスレッド化って結構難しんだよな〜
マルチコンピュータは難しいけど。
強化学習がなんかおかしい感じだったので、記譜学習で上書きしたら
かなり過学習になってしまった。強化学習で戻せばよいかと思ったけど
なんかなかなか戻らないorz
強化学習どっかおかしいのかもしれない。
排他制御とかしたら性能出なさそう
DBがTXTで1.7GBに。
実行時7GB程になりました。
std::mapを別のコレクションに変えたらメモリ使用量減らないかな〜？
int型ならatomic<int>していたりで、並列ライブラリにお任せです。
またVirtual Lossという方法があって、ツリーを下っていく時は、先に負けた事にして
降りて行って、末端から戻ってくる時に正しい勝敗に置き換える事で、並列探索
の各スレッドが同じ枝に集中しないようにして、排他がかかる可能性を減らしてます。
あとは、排他制御が必要な領域を細かい単位に分割する事ですかね。
＃と思って、ソース見たらVirtual Drawになっていた（汗
あ、そうか。DB化しているって事は、合流ありだし、盤面をキーにしなきゃならないから
そうなるとちょっとややこしいのかな？
自分は合流無視で、各ノードに盤面情報を保持していません。直前着手のみ持って
いて、ノードをたどる時に盤面情報を更新しながら降りていきます。着手もBITBOARD
の64bitは無駄なので、char型にしちゃってます（内部的にはintなんだろうけど）。
頭の片隅に入れておきます。
とりあえず、子ノードへのポインタが結構メモリを食ってるような気がします。
これを無くして毎回子局面を計算するようにしてメモリ節約するという手もありますがあんまりやる気がしないなぁ。
Intel TBBとかと中身はほぼ同じだと思います。
かなり抽象されていて、わかりやすいです。
自分はこれなしでは並列化できません（汗
ツリー構造だと子ノードへのポインタが一番大事な情報になっちゃいますね。
その場合ポインターと直前着手があれば盤面情報は不要になります。
一方で、ハッシュテーブル構造だと、子ノードポインタ不要で、キー（と衝突検出）
のために盤面情報が必須になります。
DB化するんならハッシュテーブルとかの方が向いていますよね。
自分はMCTSでツリーを作ったり消したりなので、ツリー型にしています。
shared_ptr使って、不要になったノードはシステム任せで自動的に削除して貰って
います。ハッシュテーブルだと、そう簡単にはいきませんね。
結構サイズでかくて持ち運び面倒だし、ノートPCのUSBポートに刺していると
安全装置が働いてしまうので、別途電源取っていました。
で、どうせ強化学習回しておくだけで暇だったので、専用のクーリングファンを
自作してみました。
タカチのアルミケースをぴったりサイズに切り欠いて、USBコネクタと5Vの
クーリングファンをセット。ノートPCに装着するとファンが回って冷却開始。
製作時間１時間程度。材料費は３０００円くらい。
雑に作った割にはうまくできた。
現在、簡易版と詳細版の２種類の評価関数を学習していますが、
これにより詳細版を完全にBuroさんモデルにする事ができるように
なりました。
というわけで、詳細版は再度学習し直しです。
簡易版は、多少癖があるようだけど、そこそこまともになっています。
一方、詳細版は何度もやり直し中（汗
やはりCNNなどでメモリを圧縮する必要がある。
これで当分DBで押せるｗｗ
もうちょっとヒューリスティック入れたほうがいいかな〜
New PC欲しい病再発の兆し・・・
下手に手を加えないでDB肥大化で押したほうが、
真の棋理に近づくのかもしれないなどとも思ったり。
悩ましい。
がっかりorz.
適当な回数プレイアウトして7連が一番多くできたところ付近にしぼって
モンテカルロ木を展開するというもの。
やっぱ9路でも必至、詰めろルーチンいるなぁ
そういえば直してなかった。
は〜
バグが以前ありました。おそらく並列処理による２重更新問題だろうと言う事で、
UCT探索の排他部分を強化して対応していましたが、ここにきてまた発生。
昨日原因が判明しました。まさかの、浮動小数点誤差の問題でした。
スコアの合計値と、試行回数を持っていて、合計値÷試行回数で平均スコアを
計算しているのですが、合計値が３５００万を超えたあたりで＋２をしてもfloat的
には、その２差を表現できる精度が無くなって、少しづつ合計値が不足していく
状態になっていました。
とりあえずfloatをdoubeにしてみましたが、案の定メモリーを消費する速度が大幅
増加してしまいました。小数点以下１桁もあれば十分なのでintに１０倍値を持つ
ようにしてみようかなぁと思っています。
ついでに速度アップしている分だけ、自己対局の探索時間を短くしました。
評価関数を簡易版・詳細版２種類使っていましたが、詳細版も十分に学習
できたようなので、詳細版一本に絞りました。というか、そろそろ追い抜いた
と思えるようになってきました。とはいえ自己対局の評価値を見ていると
３０手目以後はそこそこまともな感じですが、序盤はまだデタラメかなぁ。
完全読み切りですが、３０手より前に遡る事がなかなかできません。評価関数
の精度のためか、残り２８手あたりから急激に読み切り時間がかかるようになり
ます。評価関数の精度が悪いのでオーダリングが正しくできていないからでは
無いかと想像しています。強化学習で補えるかと思っていますが、まだまだの
ようです。
現在、記譜学習は完全読み切りができている盤面しか使用していませんが、
せめてMCTS探索が始まって以後の盤面も学習に使用してみようか悩み中。
これ以上の精度を求めると、やはりDLに行かざるを得ないですね。
今の探索でもツリーがメモリー内に収まるギリギリに係数を設定しているので
探索延長が起きるとあっという間にスワップ開始になってしまいます。
というわけで大きなメモリーが欲しい今日この頃です。
と思いきや勝利目前でバグが出てパス2回した後エラーはいて落ちたorz
くそくそくそくそ！
いい加減直さなきゃだけど再現性低いからバグ潰すの難しいんだよなぁ
(
;FF[1]GM[1]SZ[9]
;B[ee];W[dc];B[de];W[ce];B[ge];W[df]
;B[hc];W[fg];B[gd];W[gf];B[cf];W[eg]
;B[gg];W[gh];B[cd];W[fe];B[fd];W[dd]
;B[ff];W[hg];B[be];W[cg];B[];W[gg]
;B[];W[dg])
マジ原因がわからんorzorzorz
ログでも仕込むか？
条件絞り込みがムズイ。
とりあえず、ログかなぁ？
しばらく対局しまくるしかないか
ノードに盤面情報登録し忘れてるパスがあった。
これで落ちずに連続対戦できるようになるかな。
今のところ黒番で８勝２敗
かなりいい感じ。
だいぶ追い上げられたorz
でも連続対戦ちゃんと動いてるようで嬉しい。
メモリーサイズは一緒だけど、intの方がオーバーフローがわかりやすい。
あと、効果あるかわからないけど、置換表再利用回りをちょっと機能追加。
途中でゲーム終了になった時のスコアカウントですが、FFO計算をチェックに
使っている関係で空白マスを勝者総取りにしています。しかし、学習の時には
空白マスを含めない方が回帰の計算的には良いのではないかなと思い始め
ています。MCTS的には終局判定を入れてあり正しく終局時スコアを返すので、
あくまで学習時だけの話です。
ただ、記譜を経由していればスコア再計算で良いのですが、置換表に溜まって
いる盤面情報では、アメリカルールのスコアを割り出しようが無いという…。
DB作成を流しっぱなしにしてきたので
正月あけどれくらいデータ取れてるか楽しみ
グーグル検索⇒『来島のモノノリウエ』
G32792G4ML
もういちどleela zeroパクれるか検討するか？
うーむ。
学習が進んだ結果、３３〜３５手目あたりは正確になり、評価値の精度が上がった
事からオーダリングが機能するようになり、遡りチェックの時間は少しづつ減ってきて
いる感じですが、３０〜３２手目以前はまだまだばらつきがある感じです。
また、以前から気になっていたのですが、MCTSによる記譜作成では３５手目以後で
急に頻繁に手を間違える症状が出ています。記譜を膨らますにはちょうど良いので
放置していましたが、いよいよバグ探しを開始。やっぱり、並列処理の排他が不十分
で、末端ノードまでたどり着いて同じノードに探索が集中した時に、スコアの更新が
ぶつかっておかしな値になる事で、別のノードを探索。また探索が集中し、スコアが
狂い別のノードを探索という感じになっていた模様です。
修正したら大幅スピードダウンしてしまいましたが、精度は上がりました。
速度を持ちなおせるか色々調べましたが、ちょっと厳しい感じです。
加えてみましたが、今度は極端になりすぎて、パーフェクト勝敗な記譜が増えて
しまいました。どうしよう。
スピードダウンの影響は結構大きく、探索の終盤で、同じツリーに対する探索が集中
するためか、さらに大きく速度低下し、今度はそちらが原因で終盤間違えるように
なった感じです。あちらを立てればこちらが立たずです。
当初は、こういう問題はなかったはずなので、過去のソースを見直してみるつもり。
オセロやコネクト４もあるみたいですね。
たぶんディープラーニングしてるんだろうなぁ。
そりゃそうと、CPUのバグの影響どうなんでしょね。
あまりに時間がかかるので、ちょっと辛い。
記譜作成やめて、ひたすら強化学習にしてみようかなぁ。
後は細かい精度なので、その方が早い気がしてきた。
「あまりに時間がかかるので、ちょっと辛い。」
は、現状の学習方法だとあまりに時間がかかるので、やはり新PC欲しいんだけど、
CPUバグの話が出たので、ちょっと様子見すべきかどうかって事です。
ただ、MCTSで排他待ち合わせによる速度低下が出ているのと、読み切り探索では
並列探索の効果が頭打ちになりやすいので、本当にCPUに投資した効果があるの
かが不安になってきている面もあります。
むむむ。
まあメモリ増やすだけでも大分違うかもですが。
python 読めるようになったほうが後々いいんだろうなぁ
でもメンドクサイｗ
パイソンということを差し引いても結構難しいんだろうなって感じ
実際に実行できるところまでこぎつけるべきだろうか
Cygwinじゃきびしいかなぁ
記譜をガッツリ遡りチェック中なので暇です。で、よからぬ蟲が疼きだして、そろそろ
ボードを作ろうかと思い始めました。ソース消失前は、min-Max版時代のボードが
あったのですが、また作り直しです。
オセロにも碁盤ソフトみたいなのがあれば良いのですが、無いようなので自作を検討。
囲碁のGTPみたいなプロトコルを作って、思考エンジンとGUIを分離できたら良いなぁと。
というわけで、匿名パイプを使ったプロセス間通信について勉強してました。
サンプルコードが１０年前のC言語しかなくて解読に苦労しましたがエコーサンプル
を修正しながらテスト。coutとcerrを別パイプに分離して、スレッド管理はPPLにお任せ
にするところまでやって、ようやく納得。
ボードGUI作って、プロトコル決めて、AIエンジン部を対応させてと、まだまだやる事が
ありますが、最終的には自動対局までできたら良いなあと。リソースの限界はあります
が、パラメータで強弱が出そうなので、客観的に評価したい。
というか、GUIの作り方から学習し直しだ…
GUI触りたくないからボードソフト探していたのに、無いから自分で作るという罠。
色々見直して、若干速度は回復しましたが、最初にRollout外した時のびっくりする
ほどの速度は出なくなっちゃいました。ただ、時々瞬間的に速い時があるので、
単純ではないかもしれません。
３０手過ぎるとどんどん選択しが狭まっていきますので、ツリーサイズは小さくなって
いきます。ここで、一部の手に探索が集中して、１００万探索単位で追加探索したとき
にようやく他の枝を調べ始めるようで、それでもツリーサイズはそれほど大きくならない
ので、メモリーはそれほどボトルネックになっていない感じです。
UCB１のCをいじったり、ポリシーの探索比率をいじったりして様子をみていますが、
あまりフラットに探索すると、正解にたどり着けないまま終盤を迎えてしまうし、
かといってスティープに探索すると、間違いを訂正するまでの追加探索が大量に
必要になるしで、調整が難しいです。そもそも評価関数の精度が十分じゃないと
言う事なんだと思います。
何か読みにくいと思ったら。
もうちょっとAlphaZeroの基本アイディアを理解してからじゃないと。
ちょっと見てみたいかも。
GUI作ろうと思って調べたら、VS2017からなんかだいぶ変わっているみたいです。
MFCは非推奨との事で、ユニバーサルWindowsとかってやつと、あとはCLRですか。
両方試してみようとしたのですが、ユニバーサルWindowsはWindows10じゃないと
ダメっぽい。CLRはなんかエラーで動かない…。他にもC#だと楽だとか色々ある
みたい。MFCは使えるのですが、もう忘れたし、面倒くさかった記憶しかない（汗
C#で作るって手もあるみたい。
とりあえずC#を勉強してみようかなぁというところです。
脱線しすぎだなぁ。
ttp://https://github.com/Zeta36/connect4-alpha-zero これです
オセロ用の確立された GUI はありませんが、
nboard
ttp://http://www.orbanova.com/nboard/ xboard / winboard (alien edition)
ttp://http://hgm.nubati.net/alien.html Othello Engine Protocol (cassio)
ttp://http://cassio.free.fr/engine-protocol.htm Edax はいずれもサポートしているので、プロトコルは
ソースでも見られます。
実はROMも意外といるんだろうか
どもです。ダウンロードしてみました。
酔っぱらって帰ってきたところなので、明日以後見てみます。
ありがとうございます。
cassioはmin-Max前提みたいですね。
nboardとxboardは明日以後見てみます。
とはいえ、もうすでに作り始めてしまいました（汗
c#はVBみたいな感じですね。１０年くらいVBも触っていないので、VB自体も
昔とはだいぶ違うんだと思いますが。
まずは匿名パイプでのやり取りまで確認できました。
色々なソースのつぎはぎでわけわからんけど、何とかC++とAPIで作ったサーバ
側と同じ動作するものが動いています。
Learning to Play Othello with Deep Neural Networks
ttp://https://arxiv.org/abs/1711.06583 はチェックされていますか？
ありがとうございます。
さっそくダウンロードしました。
今これ見てます。
ttp://https://github.com/adepierre/Caffe_AlphaZero どうしようかな…
アンチウィルスソフトが勝手に何か裏で削除してるらしく
うまくmakeできないorz
なんなんだこれは？
仕事が忙しいのもあるけど
技術的に難しそうな事は気合入るんだけど、どっちが黒番とかのラジオボタン
をどうしようかとか考え出すと、思考が止まってしまう（汗
一つの項目で諦めがつくまでに３日づつかかっていますorz
ttp://http://postd.cc/alphago-zero-how-and-why-it-works/ これ読んでます。
とりあえず、一旦コードから離れて基礎知識を充実させる方向で。
おかしいので、丸々一晩デバッグしていました。ケースは特定できてた
のですが、ぱっと見まったく原因がわからず。
C#はオブジェクトを代入すると参照になるのでした。やられた。
やっぱCというのは名前だけですね。
ttp://https://github.com/junxiaosong/AlphaZero_Gomoku すいません。またコード見始めてます。
多分これがウィンドウズで動かすの一番簡単な奴な気がするｗ
theanoとかいうライブラリが上手くインストールできてないっぽいorz
誰かわかる人いる？
...
File "C:\Python27\lib\site-packages\theano-1.0.1+unknown-py2.7.egg\theano\gof\
lazylinker_c.py", line 127, in <module>
preargs=args)
File "C:\Python27\lib\site-packages\theano-1.0.1+unknown-py2.7.egg\theano\gof\
cmodule.py", line 2359, in compile_str
(status, compile_stderr.replace('\n', '. ')))
Exception: Compilation failed (return status=1): /usr/x86_64-w64-mingw32/bin/ld.
exe: error while loading shared libraries: ?: cannot open shared object file: No
such file or directory. collect2: error: ld returned 127 exit status.
Cygwinに入ってるライブラリは互換性ないってことか？
どこでライブラリ入手すりゃいいんだ？？
こちらは、どうしても画面が崩れてしまうので、最初から作り直し。
原因は、トップのFormでauto resizeをtrueにしていた事でした。
ゲームの進行を上手に管理する方法が無いか考えていると、つい寝てしまうorz
コマンドプロンプトで実行したらのようなメッセージでライブラリ名わからなかったのですが
Cygwinで実行したらライブラリ名が出てきました。
それぞれ4行づつ同じ行が出るのですが1行に削って張ります。
library stdc++ is not found.
library mingw32 is not found.
library gcc_s is not found.
library gcc is not found.
library moldname is not found.
library mingwex is not found.
library msvcrt is not found.
library advapi32 is not found.
library shell32 is not found.
library user32 is not found.
library kernel32 is not found.
library mingw32 is not found.
library gcc_s is not found.
library gcc is not found.
library moldname is not found.
library mingwex is not found.
library msvcrt is not found.
これに続いて同じ名前のライブラリはあるけどコンパチブルでない的なメッセージが出ています。
動いたっぽいです。
Theanoってライブラリのバージョンが0.7.0じゃないといけないみたいです。
ここまでめっさ時間かかったorz
遅れを取り戻さんとな。
つか多分pythonじゃなくても読むのしんどいんだけど。
１年前に書いた自分のコードもですがorz
Theano動作おめでとうございます。良かったです。
こちらは…GUI作るのに嫌気がさして、学習部をいじっていましたが、
そろそろ〜３０手の評価関数もそれほど酷いものではなさそうな気がしてきて、
中盤探索９手読み（なんの工夫も無し）で記譜作れる事に思い至りまして。
つまり、MCTSより短時間で記譜作成できると…。
この学習で、もし中盤探索の読みがそこそこな精度になってしまったら、
そもそもMCTSにする意味ないじゃんという現実からいかに目を背け続けるか
という戦いが始まりました（涙
パイソンの習得は必須…
とりあえず囲連星のルールを実装してみます。
アルファ碁でいうところのポリシーネットの学習を放棄して、代わりに評価値から
P（UCT探索に対する絞り込み項）を生成していましたが、これをQ（UCT探索の
予想スコア：これまでの探索の加重平均）から、１プレイアウト毎に再計算するよう
にしてみました。
多少探索速度は落ちますが、良い感じかなぁ。
コード書きながら読んだほうがいいかなぁ。
C#ですら混乱して、C++に帰りたくなってます（汗
というか、メモリー管理できないC#にいらついて、記譜作成回りをいじって
慰みにしています。中盤探索に置換表を足して、反復深化っぽくしてみま
したが、あんまり早くならなくてがっかり。
Python本はまだ買ってません。ウェブ上の入門を眺めたくらいです。
Pythonは構造やら変数の型の考えやら、落とし穴になりそうなところが
色々とありますね。計算式だけ見ていればわかったような気になりますが、
どういう順番で処理が進むのか、慣れないとわからん感じ。
引数に何与えていいのかとかパッとわからないorz
これからテストします。
あとはこれをに移植できれば…
これはかなり時間かかる…
複数のゲームに対応しているAlpha Zeroプロジェクトのコードを見たほうがゲームのルールが分離されてるのかもしれないなぁ
一応、別のプロジェクトに手を出すことも視野に入れるか…
謎だ…
有った方が強くなるので外せなかったみたいな事が書いてあったような。
今現在の思いつきですが、ツリーサーチの末端近くでは、手の流れに応じて
点数が変わる事で、そのツリーのルート側の評価（加重平均）に影響が出てくる
可能性はある。
囲碁の場合、同一盤面が出る可能性が非常に高いのだけど、そこに至る経路で
隙があると、相手にその隙を突かれて、分岐が生じる事で、その点数は無意味に
なる。けど、それは途中の分岐をしっかり読まないと判明しない。経路情報によって
評価値（評価関数直）を下げてしまえば、プレイアウトの振り分けが減って、別の
もっと良い手に集中させることができる。こういう事かなぁ。
ま、本当に今思いついたばかりですが。
GUIに気が進まないまま、ぼーっと学習を見ていると、何故か（効果は微妙だけど）
速度アップの方法を思いついてしまうもので…。地味に色々改良しています。
単に凝り性なだけですかね。
凝りたい気持ちと、画面遷移の罠から、心がデッドロックを起こして、
しまいに面倒くさくなってしまうという。
まいいけど。
囲碁のプロジェクトもgithubで漁るか…
すごいすな
築いて、相手の奇手にも動ぜずにさばいて、勝利って感じで、強さが際立って
いましたね。
これで勝っても漫画なら編集長にバカにされるレベルと言われていましたが、
本当に笑うしかないですね。
ただし超絶遅い。絶望しかないってくらい遅い。
10プレイアウトで10秒くらいかかります。
デフォルト1000プレイアウトになっていたのでそれぐらいないとまともな強さは出ないんでしょう。
となると1手1000秒か？
絶望しかない。
orzorzorzorzorz
／ ＼ こんな話があるかっ…！
／´ ＼
/ |＼_＞､_ ､r‐､ ＼ 命からがら… やっとの思いで…
ﾚ! ｜|_| |/_ ヽ＼} ＼ 辿り着いたのに… やり遂げたのに……
|八|-／>､∪_ u`i ト､ ＼
/ / ,くｨ夕u' | |/ ｀`‐- ､_.､__＼ 実行速度っ…！
|/ / /_ヽ┐u | ,| / ,-,.=====ゝ
ヾ' / r┘|.l__人 | /＼// ＼ あの計算量がもぎ取ってしまった……！
＼ ） | N / //＼.／´￣｀丶
｜u | /|(l(l｢| | | | せっかく手にした
｜ u｜ / | ヾ-ｲ .|｜ l、 俺の未来…希望…
_| |/| | ＼＿|_|,. く. ＼
ハ.＿__ハ >､ ＼ ＼ ＼ Alpha Zero AI を……！
こうなったらC++に移植する方向で考えるか？？
とにかく今のままじゃ遅すぎる
囲連星ルール部分がどれくらいネックになってるかもよくわからないですが多分相当遅い
当たり前か…
やっぱ囲連星ルール実装がネックか〜
は〜
死にたい
C++からPythonも呼べるみたいです。
前にPythonに手を出そうかと思った時にググったら出てきました。
前者の方が解説が多かったと思います。
自分はBitboardを使いまくりなので、Pythonに手を出しあぐねていました。
また、評価関数の学習部と、評価値計算をうまく分離できれば、前者を
Python、後者をC++で書けないかなぁと思っていますが、im2col関数の
うまい実装を考えるのが面倒で、放置になっています。
集中させたら、また変な学習になってしまったようで、迷走中です。
学習の具合が良いと、色々な探索も速度アップするんだけど、具合が悪いと全部
悪循環になってしまうという。
仕方無いので、中盤探索の反復深化を作り、その結果を置換表に溜めてオーダ
リングを行うようにしてみましたが、効果があったのかよくわからない罠。
こちらも、学習の具合が良くなったら、急激に効果が表れるのではないかと期待
しているんだけど。
なかなか手ごわい
つぎは囲連星ルールパイソンモジュールの作成ですね〜
頭に来たので、評価関数をステージ分割。
ステージ分割すると学習部分の全面書き直しとなる。
どうせニューラルネットは使わないと決めたので、線形回帰にスケールダウン。
またしてもゴチャゴチャしてきた部分を全面書き直しパターンへ。
もうGUIはすっかり忘れていますorz
動きました！
C++版囲連星ルールパイソンモジュール!!!
10倍くらい速くなりました！
でも1000プレイアウト1手約100秒
まだまだ遅い
でもこれ以上速くするアイディアもないし、とりあえず、これで進めるか。
zipから解凍したソースそのままで実行しても不正終了になるのでちょっと謎ですね。
上手くインストールできたと思ってたけど実はまだ駄目だったのかなぁorz
他に候補ある？
自己対戦など、汚いコードを綺麗に書き直し。
かけた工数的には自己対戦の方が大変だったかも。
評価関数を１手毎のステージ分割で６０ステージにして、学習し直しです。
これで序盤を学習させると終盤が狂う問題は解消されると信じていますが、
学習に６０倍の時間がかかる事が予想されるという状態で、記譜を幾ら作って
も追い付かない感じなので、強化学習主体にするつもりです。
というか、まだ、UCTの所は作りこんでいない。
まあ、ほとんどコピペですが。
で、ここまで来たところで、もういっちょ改造したくなってきた…。
素晴らしい。
合法手が無い、みたいな感じに見えますが…
いい線行ってると思うんだけどなぁ
train.pyと何が違うんだろう?
__eq__はC++のoperator==で良いみたいです。
行ったと思ったのにorz
Board.init_boardでC++のオブジェクトを初期化してなかったのがエラーの原因だったみたいです。
焦れるw
とりあえず、これでウェイトファイルが出力されれば第一段階クリアですが…
まあ確かにコード読んでてもマルチスレッドには見えなかったけど。
いかんせん遅すぎますねぇ
並列化してハードも強化してあと30倍は速くしないと…
CPUがほとんど仕事してないんだが…
いったん止めるべきかな〜
強化学習にすごーく時間がかかりそう（汗
というわけでNew PC見繕ってます。
ノートPCでi7-8700Kの６コア１２スレッドにメモリー３２メガで
GTX1080搭載のノートPCがある。
むむむ。
土曜からずっと動かしっぱなしでしたが、ここにきて強制終了は痛いですね。
解決しようにも再現させるだけで数日かかってしまうし目星を付けることすら難しそう。
予想してたよりずっとまともな手を返してきますね。
ほぼランダムに着手すると思ってました。
これはちゃんと学習できる環境整えればかなり期待できるかも！
デスクトップ２台は手狭だからなぁ
他のもっと高速化に力入れたalpha zeroプロジェクトも試してみようかな
お高いですが、デスクトップのフルスペックの1/3以下で済むようです。
回しっぱなしの奴がレアケースで異常終了すると萎えますね。
自分の奴は、たぶん怪しいところはほぼ蓋をしているので、今は安心しています。
とはいえ、評価値の保存に数秒かかるようになってしまったので、保存中にうっかり
終了してウェイトファイルを破壊しないように、いくつか策を講じました。最近はOSの
アップデートで勝手に再起動されちゃうので。
強化学習に凡ミス発見。
強化学習が良いのは、学習し続ければ何とか復旧できると思えるところorz
ttp://https://www.pc-koubou.jp/products/detail.php?product_id=617093 i9-7080XEのデスクトップだとメモリー頑張ると１００万ですからね…
ほほう？
ハイスペックノートの割には確かに安いですね。
やっぱ軽くでもテストはやっておかないとあかんなorz
強化学習単純化しすぎちゃったかなぁ。
暫定的にひたすら記譜作成＆記譜学習に戻しました。
遡り３０手が鬼門。記譜学習で、ここをクリアする事を当面の目標にします。
とはいえ、残り２９手完全読み切りの記譜がそれなりにあるのは、以前では
考えられない状況ではありますが。
のかもと思い始めました。それによって、着手して分岐しても±０となっている
みたいな。
とりあえず、記譜の増殖手段を模索中。
今は、ヌルウィンドウサーチを使用して、遡り探索を行っている関係で、間違った
着手（石損となる手）を捨ててますが、ある程度までその手も読み切って、記譜に
加えても良いのかなぁと思っています。
とりあえず、βカット（もっと良い手があった）時の評価関数は明らかに読み間違い
をしているので、そこ限定で記譜に加えていますが、ある程度以上の手数は全て
付け足しても良いのかなぁと。
今の学習は「良い手」しか学習していないという事です。
序盤はある程度ランダムな着手を入れて、結果がばらつくようにしていますが、
途中から読みを入れて、良い手だけで着手し、その結果を遡りで訂正しています。
遡りが有効なのは３０手くらいまでで、序盤のランダムは２０手程度までに抑えて
あります。とすると、遡れる範囲では、悪手を打ったらどういう事になるのかという
学習が抜けている。間違えた着手もちょっとだけ悪いだけでです。結果、最善手の
評価値はそこそこ正確なのですが、極端な悪手も、評価値としてはちょっとだけ
悪い数字でも問題が起きないという事になります。
これはこれで順序付けさえ合っていればそれで良いのですが、ちょっと学習が
進んで、微妙に係数が変わった時に、計算上０．１程度しか悪くない相当な悪手
をうっかり選択しやすくなってしまうという事で、これがオーダリングで悪さをして、
探索時間を長引かせてしまう可能性があります。
恐らく評価関数のステージ分割で、表現力がかなりアップした事から、こういう
学習漏れみたいな事が起きてくるのかなぁと。ほんと、評価関数はスカスカです。
というわけで、昨夜書いたように、ある程度深さを捨てて分岐をすべて記譜に残す
ようにしてみようかなぁと思っています。しばらく記譜作成しながら、この事を踏まえ
た強化学習をちょっと考えてみたいと思っています。
もうちょっと様子見るけど。。。
やっぱマルチスレッド化された別のalpha zeroプロジェクト探そうかな…
別のalpha zero プロジェクト本気で探すか…
ここまで来てもったいない気もするけど…
もう嫌になっちゃう。
逆にいい傾向なのか？？？
２０００程度だったのが、１５０００超えました。
が、まだまだスカスカみたいです。
ここまでするんなら、真面目に自己対戦して遡りせずに、ランダム着手に対して
分岐をリストアップさせても一緒というか、早い気がしてきています（汗
もっとも、残り数手とかの記譜もあるけど（汗
ステージ分割しているので、記譜がなかなか生成されない２５〜３０手近辺で
非常に少ない教師データで何度も学習する事になり、そのあたりが極端な
過学習になってしまった。
解消方法をいくつか検討中です。
１）時間かかっても良いので、２５〜３０手の記譜ができるまで頑張る
２）前後の盤面を混ぜて、教師データを増やしてみる
３）ランダム強化学習してみる。
２）３）をやると、おそらく、平均化されて評価値がフラットになるが大小関係は
治ってくると思う。
というわけで、今夜は２）３）を試してみる予定。
エラー（スコア間違い）が出る時がある。
運が悪い事にハンドリングミスその他で、記譜を残せていないので、
現象の特定ができていない。
頻度としては数日に１回くらい。
たぶん、全滅と直前のパスがらみだと思うんだけど。
をpytorchで学習してみます。
GPUありとなしでポリシーファイルに互換性がないんですかね？
もしかして。
初めからやり直すか…
こちらは、昨夜のバグの現象は特定しました。
スコアが６２や−６２で、mtd(f)の探索開始が６４や−６４の時に、
置換表に残った６４や−６４が悪さして、６４や−６４と誤答する模様。
とはいえ、どこを直すべきかはわかりません。探索開始が６４や−６４
の時に、６２や−６２にしてやる事で、姑息的に回避はできるので後回し。
あと、記譜作成に色々機能を加えていたら、どこかがおかしそうだという
不安な状態になってしまいまして。このまま記譜学習を進めて良いか自信
が無いので、今までのデータで安全な部分をテスト用に回して、新たに
記譜を作成開始。３４手目までは全探索しながら普通に遡れる感じです。
３３手目から先は探索時間がしんどいので、ひとしきり落ち着いてから、もう
一度、遡りチェックのプログラムをきちっと見直して、追加していこうかな
と思っています。この間に、強化学習混ぜて、過学習部分を解消して
いこうと思います。
ちゃんと時間測りたいなぁ。
全滅がらみでほかのケースでも誤答するケースが発生しました。
元々FFO#59用にmin-Max探索に入れていた、全滅時の処理くらいしか
原因となりそうなものが思い当たらなかったので、とりあえずコメントアウト
して様子見です。全滅時の探索が速度低下しますが、仕方がありません。
記譜作成で負荷テスト並みに探索を繰り返すと、全滅絡まなくても間違うケースが
出てきました。再現性が無いのが辛いところ。
その昔悩んでいた時も、やっぱり置換表がらみの問題で迷宮入りでしたが、
今回も、ケチって置換表を極力クリアせずに使用していた事から、何らかの
矛盾が起きているようです。それを言っちゃうと、置換表付mtd(f)でｆ値を変え
ながら探索することも、またその時に作成された置換表を流用して記譜作成
兼ねた読み切り処理を速度アップすることも、怪しいという事になるわけで。
間違えてしまった事が判明した時点で、その探索は捨てるくらいしか対策が
無いという事になります。
ネットで調べたら、将棋AI界隈でも置換表の問題点を書いている人がいまして。
少なくとも深さがあっていない置換表データは使うべきではない模様。
今の調子だと一晩動かすと結構な頻度で朝見たら止まっているとい状態なので
せめて発生率を下げるべく、mtd(f)に入る前に置換表をクリアする事にしました。
なぜしなかったかというと、記譜データからスコアが確定している盤面を置換表に
入れて、それを見ながら既に読み切りしている盤面は飛ばす処理をしていたから
です。置換表をクリアして盤面再構築に時間がかかるためです。別途盤面キャッシュ
を持って、そちらは追記、置換表は毎回クリアという形に変更しました。
俺がパクったプログラムも学習し続けたらあれくらい強くなるんだろうか？
GPUありなしでポリシーファイルが違うってことは
成果物を配布しようとしたらGPU持ってる人しか遊べないってこと？
ええぇ？
違う局面の探索で使用した置換表データは使いまわしてはいけないという事で。
なんか、結果的に、２年くらい前にも同じ事で騒いでいたような。
色々整ってきたので、あとはひたすら記譜作成しながら学習を回すだけになって
しまって、暇になってます。別PC買ってそっちで学習させながら、別の事をはじめ
ようかなぁと思い始めています。
学習は継続しつつ別のalpha zero プロジェクトも物色するか…
swigでC++から移植したクラスってデフォルトでガベージコレクトされないのかなぁ？
もしかして。
とりあえず8GBに増やしてみた。
メモリ増やしたのと再起動かけたのどっちが効いたのかわからんが。
もう何回目だ？TT
しかしベストポリシー更新は相変わらずなしorz
でも確かめようがないorz
でも他のプロジェクトに浮気しようにもなかなか手ごろなのがないんだよなぁ
でも多分、難解なんだろうな〜
え〜何時いじったかな全く記憶にないｗｗｗ
これで学習が進んでくれれば！！
これでベストポリシー更新が来れば！！
ベストポリシー更新きました！
次の切りのいいところで止めてプレーしてみよう
金がないから買えないけど情報だけは追っかけてみます。
爆速だといいな。
終局までの手数も順調に減ってきてるから意味のある手を打ってるんだろう多分
ワクワク
序盤、中盤は棋理の芽生えみたいなものが感じられました。
伸ばせそうなところを伸ばすとか伸ばされそうなところを止めに来るとか
でもわざと負けようとしても５連までは積極的に作りに来るのにそこからパタッと伸ばすのをやめて７連を作ってくれませんｗ
なぜｗ？
でもまあ、希望は感じられました。
もうすこし学習してみます。
前世代と比べて一割前後性能アップ？
どこかで読んじゃったからなぁ。
こちらは地道に記譜作成しながら学習させてます。
深さ優先で記譜作成すると、分岐が少ない手筋ばかり増えていくので、
幅優先で、同じ深さである程度記譜溜まってから、次の深さとするように
したのですが、空きマス２７からの記譜展開で、時間がかかるようになって
なかなか空き２８マスに行けない。オーダリングの精度が出ていないから
だと思いますが、同時に選択肢も増えてきて、余計時間がかかる感じ。
空き３０マス突破したら、かかる時間の増加率は下がるはずなんだけど。
わからんが。
終盤に行くとデータが散らばっちゃって学習できなくなるということだろうか
KKPとかよくわからないし、同じ事をやってもつまらないので、利きを点数化
しようかと考えてみまして、実際の計算方法を考えていたら、自玉周辺と
相手玉に対する利きがKKPなのではないかと思い至ってしまいました。
持ち駒の点数は駒種毎に固定で振られていて、駒同士のぶつかりによる優劣
特に駒交換はmin-Maxにて補間しているのかなと。評価関数自体は意外と単純
な事しか学習していない感じで、探索で補っている部分が大きいように感じます。
こうやって見ると、上手く単純化しているなぁと。
自分で勝手に想像した内容に感心してしまいました。
ただ、これならこれで、自玉KPと相手玉KPの合算で、２駒関係に次元を落とせ
そうではないかと思ってしまいました。まあ、無理なんでしょうけど。
自分がやる上での一番のネックは、オセロの評価関数が点数だったために、
なんちゃって強化学習しかやった事がな点ですね。あと、みなさんライブラリ化
されていて、それに則れば色々な人の考えた高速化・高効率化のネタが利用
できる点で、一から車輪の再発明していては追い付けないよなぁと。
将棋AI界はオープンソースが進んでる感じなんですかね。
そろそろちゃんとソース読み解いてみようかな。難しいだろうけど
丁寧な解説がどこかにあればいいんだけどね
いままではわざと負けようとしても勝ってくれなかったけど今回は勝ってくれた。
まだまだ弱いけどもっと学習させてみよう
計算リソースが学習にもってかれちゃってるからそこどうするか。
やっぱPC新調か？
グラボも効果あるみたいだし今度はGeforce 1080 Tiとか試してみたいな。
金がないけど。
PC新調しちゃうか思いっきり悩み中。
でもさらに学習時間がかかると思うと躊躇する。
いい感じなんじゃないでしょうか？
いいCPU作ってくれるならどこでもいいけどね。
ほかのアルファゼロクローンも似たような感じなのだろうか？
実際、必至をかける一歩手前まで行った。
終盤力さえ磨かれればおそらく公式AI越えはある。
1500が規定値だから最後まで回したいな。
こんなことなら最初から1080 Ti いっときゃ良かったかな？
学習最初からやり直しです。
さて吉と出るか凶とでるか。
ネットワークでかくしたら学習率は大きくすればいいのか小さくすればいいのか…
俺もやっぱGPU付きのPC買うべかな。
一般的にLRでは、学習率は発散しない限界まで大きくするのが良いらしく、
昔は、最初大きく、試行回数増えるごとにだんだん小さくみたいな事をしてました。
NNではRMSPropとかADAMとかで自動調整する流れだと当時理解していました。
ただ、Googleの論文読むと、普通に学習率固定っぽく読めてしまうんですよね。
強化学習だと学習率固定が良いのかも知れません。
表現力大きいからあんまり問題ない気がするのですが、学習率は小さくすると
学習に時間がかかる代わりに、収束しやすくなります。局所解には陥りやすく
なるのではないかと愚考しますが、強化学習における局所解と、教師付学習に
おける局所解は現象が違うから、よくわかりません。
空きマス２７の所（完全読みとしては２６）のところから、計算時間が案の定すごく
かかるようになってしまって、遅々として進まなくなりました。
最後の手段でとっておいた、UCT探索で仮PV作成し、それでmtd(f)にて評価値を
迅速に確定して、その評価値で正しいPVを求めるという流れにしたところ、恐らく
数倍程度に高速化され、それによって記譜が集まり正確になる事で、評価関数の
精度が上がって、仮PVが正確になりという好循環に、ようやく入る事ができました。
ただ、それでもまだ時間はかかるというか、今空きマス２８まで持っていったら、
また時間がかかる地獄に入りそう。最低でも空きマス３０までは持っていきたい。
つか、待っている時間が長い…セカンドPCが欲しい。
＞数倍程度に高速化され
あくまで仮PVが数手分合っている時の話で、仮PVが間違っていると、
むしろ遅くなる可能性があります。
あと、一つの局面に対し、最善手が複数あるケースでは、例えば最善手
が２つあると２倍程度時間がかかるという問題があるのは認識していて、
対策は可能なのですが、そうするとバグった時にβカットのエラーを吐か
ないという恐ろしい状態になってしまうので躊躇しています。
T.N.K（通称たぬき）ですが、DL勢にして高速評価関数という事なので
アピール文書を見てみました。
これ、CNNではなく、全結合のDeep Networkの模様。追加で論文も
出ているので、見たところ５層のMLPです。
入力層に玉との２駒関係を使っていて、そこは計算量が多いので、
ここだけ差分計算で高速化しているとの事。自分は行列をEigenに
任せちゃってるので差分計算していませんが、オセロでも結構使え
るはず。
もう一度オセロをMLPに拡張したくなってきた（汗
なんか学習がうまく進んでないようです。
その分初段まで誤差を遡らせるのに時間がかかるから、収束が
遅くなって当然かと思います。
あと、初期値のランダム値の幅も、適切に設定しないとなかなか
収束しなくなりますし、それでも初期値の運が悪いとまったく収束
しないなんて事もあり、ちょこっと不安定なところがあります。
XavierとかHeとか初期値の設定項目はありませんか？
本で読んだ知識なので、現実にどれくらい影響するのか良くわかりませんが（＾＾；
しらべてみます。
あー怖かったTT
うーん、なんだろう？
もっと時間が必要かな。
マジむかつく（怒
俺は通知もらうだけにして、タイミング見て自分で再起動かけてる。
まあ、２４時間経つとカウントダウンが始まるので、早目に再起動する事になるけど。
公式AIに勝つチャンスあったのに勝ちを逃してしまいました。
PCをひょいと動かした瞬間に、まさかの電源落ち。
ウェイトデータ書き込み中に停まらないように色々工夫していても、
この手の落ちには対処できるわけもなく、また大変に運が悪い事に
またしても後半１０ステージ程度のウェイトデータが飛んでしまい
ました。バックアップとっていたのですが、気づかずにいたので、既に
上書き済みという罠。
後ろ１０ステージ分のみゼロクリアして、そこだけ今のデータで再度
学習する羽目になりました。
orz
凄すぎ
でも100万局くら学習させないと真価は発揮できないかもなぁ。
うーん20層は厳しい。。。
１９層必要で、出力の全結合層つけて２０層って事なのかなぁ。
あとフィルタ数も大事だと思う。フィルタで認識する特徴の種類が決まっていると思う。
なんとなくだけど、こう仮定している。検証はしていない（汗
9路だから192 * 10 にすればよかったかなぁ
比較検証しなきゃわからんけど。
ライフゲーム囲碁はもろ周辺5マスなんですけどね。
囲連星成功したらライフゲーム囲碁もやりたいですね。
なんか足の遅い打ち方するんだよなぁ。
もういっそ20層にしちゃおうかな orz
くそ〜Googleの計算リソースがあれば30分くらいで名人超えるんだろうけど。。。
対戦相手も更新されていくなら勝率100%は行かないと思うんですが。
もともとの実装がなにかおかしいのだろうか…
まだ希望はある。
プロ棋士にも勝てるみたいですね。
は〜絶望する。
ロールアウトの回数増やしたら学習の質も上がるかなぁ？
やってみるか。。。
ロールアウトを増やしたえいきょうだろうか？
危険な賭けだが…
公式AIに初勝利！
内容としては相手のミスに助けられただけだけどそれでも格段に進歩してる！
(
;FF[1]GM[1]SZ[9]
;B[fe];W[fc];B[de];W[dc];B[ed];W[ec]
;B[gc];W[gb];B[ee];W[cb];B[ce];W[hb]
;B[ge];W[fh];B[be];W[gd];B[he])
中盤まで内容は圧倒しておきながら最後の盤端のシチョウが読めずに逆転負け。
学習途中のAlpha Zero系の弱点が出てしまいました。
でも、ここ克服したら100戦100勝もあり得るかも。
(
;FF[1]GM[1]SZ[9]
;B[df];W[fe];B[de];W[cg];B[ef];W[hg]
;B[ff];W[gf];B[cf];W[gd];B[fg];W[gh]
;B[dg];W[gc];B[gg];W[ge];B[dc];W[hb]
;B[dd];W[dh];B[db];W[da];B[eh];W[ha]
;B[eg];W[hc];B[he];W[ie];B[hf];W[if]
;B[hd];W[id];B[he];W[ch];B[hf];W[hd]
;B[he];W[hf];B[di];W[he])
以前より大分、棋理のようなものが身についてきている感じがします。
ロールアウト増やしたのが効いたかな？
(
;FF[1]GM[1]SZ[9]
;B[df];W[fb];B[ef];W[ff];B[fe];W[ge]
;B[fg];W[gf];B[gg];W[cg];B[cf];W[hg]
;B[fd];W[gd];B[gc];W[hc];B[fc];W[hb]
;B[hf];W[hd];B[he];W[eg];B[dg];W[hh]
;B[eh];W[eb];B[dd];W[gb];B[db];W[dc]
;B[ec];W[de];B[cc];W[bc];B[ed];W[id]
;B[ce];W[ie];B[ei];W[bh];B[ee];W[ba]
;B[eg])
面白い。
3線を重視し始めたようだ。
一気に256 * 20くらいに増やしてみようかな？
気が早いかな〜
でもこのまま学習続けたら何が起こるかも知りたいし…
悩ましい。
激遅になりそうだが…
まさか指数的に計算量増えたりしないよね？
１２GBも割り当てたのにｗｗｗｗ
こりゃニューマシン買うしかないな。
これでも6GB位メモリ食う。
まじでスレッドリッパーに128GB積みたい衝動に駆られるｗ
全然学習が進んでるように見えないorz
残り３０手まで行くのに半年くらいかかりそうｗ
というか、まだまだパターンが足りていないかも。
隠れ層のサイズは２乗で効いてくるから、256^2/192^2。
深さは単純に計算量が４倍になるとして、ざっと７倍くらいになるのでは？
学習は深さが増えるとどんどんきつくなるかと。
誤差逆伝播の宿命です。
おお、そうなんですか。ありがとうございます。
＞学習は深さが増えるとどんどんきつくなるかと。
24層は諦めました。
今12層くらいで試行錯誤しています。
最低限どれくらいの大きさなら弱くならないかが求められるんだけどねぇ。
Googleみたいに。
うーん欲しい。
少し気分転換するか…
どんどん後退していくが仕方ない
ttp://https://www.tdi.co.jp/miso/google-colaboratory-gpu 一回試すのに結構時間かかるのも痛いorz
ちょっと休憩します
自分が逃げたのは、それです（汗
パラメータ100種類くらい用意して同時に実行したい orz
GPU Geforce 1080
Memory 64GB
SSD 500GB
これを満たそうとするとやはり40万円近くなる。
厳しい。
なんか裏があんのかな？
Wikipedia情報によると、フロンティア神代はヤマダ電機に吸収されて解散していて、
BTOショップにフロンティアという名前だけ残っているみたいです。
ヤマダ電機なので裏は無いでしょうね。
7980XEに1080Tiで128Mとかにしていくと、だいぶ価格差は詰まっていきますが、
それでも多少安いみたいですね。というか、8700Kだったらかなり安いかも。
Cudaだよね？
ここから1層づつ減らしていって学習がまともに進むところまで後退するのを考えています。
7層は囲連星が7目並べだからあるいみちょうどいいかも？
まだわからないけど
一つ前の奴に有為に勝てる様になるまでの学習時間を図っていくという手もある
かなと思います。
面倒でやりたくないですが。
自分はひたすら記譜作成。
少しづつ改良を加えていますが、残り２８手（読み切りとしては２７手）で足踏みして
います。早ければ６分程度で終わるのですが、いかんせん２５〜２６手目の評価
関数が穴だらけみたいで、長いと４時間とかかかってしまい、なかなか棋譜が集め
切れません。記譜が集まると速くなるのですが、集まるまでの時間がかかりすぎ。
とくに他人のコードだと。
弱くてもオリジナルのヒューリスティック実装するのは楽しいんだよなぁ。
うーん。
だから、非効率でも、自分でNNのライブラリ作っちゃおうとしたりするのでする。
もう少し粘るか悩むorz orz orz
結局、全部無駄だった orz orz orz
出張中に丸４８時間動かしっぱなしにしましたが、３つしかできなかった。
一つ１６時間ｗ
ちょっと単純化しすぎな気がするが、やっぱ層が足りてないのか？
過学習かなんかか？
アルファゼロのポテンシャルはこんなものではないはずだが。orz orz orz
まだ詰めはあまいけど、まるで地を取ることはいいことだという棋理を理解したような打ち方で勝った！
まだ希望はある！
(
;FF[1]GM[1]SZ[9]
;B[ee];W[eg];B[ec];W[ff];B[gd];W[dg]
;B[cd];W[cg];B[fd];W[dd];B[de];W[fh]
;B[gg];W[gh];B[hh];W[gf];B[hg];W[dc]
;B[hf];W[bg];B[he];W[ah];B[hc];W[hd]
;B[id];W[ba];B[hb];W[bi];B[hd])
十分学習したら詰みルールを外したら学習時間短縮できたりしないんだろうか？
ルールが違ったら全く重みが役に立たなくなっちゃうかな？
毎日棋風が変わっていくな。
AIが自らいろいろ試してるみたいでホントに知性があるかのような錯覚を覚える。
７連を作るにはほぼ必須なので克服してほしい。
ここは何としても克服せねばなりませんなぁ。
(
;FF[1]GM[1]SZ[9]
;B[hh];W[df];B[cg];W[fg];B[gc];W[ef]
;B[gf];W[ge];B[cc];W[fc];B[ce];W[ed]
;B[cf];W[cd];B[bd];W[dd];B[bc];W[bh]
;B[bg];W[ff];B[fb];W[eh];B[ec];W[fi]
;B[fd];W[dc];B[db];W[eb];B[ea];W[cb]
;B[bb];W[dh];B[be];W[bf];B[ca];W[gb]
;B[cb];W[ch];B[gh];W[hb];B[de];W[ee]
;B[af];W[ba];B[fh];W[hc];B[ah];W[hd]
;B[eg];W[dg];B[gg];W[fe];B[ei];W[gd]
;B[ig];W[bi])
成立しているけど、他の記譜との接点が無い）を見つけて、続きを実行するような
仕組みを作りました。
これで心置きなく途中で止められる。
気分を変えて囲連星やめてライフゲーム囲碁に逃げようかと思ってます。
プログラムもgithubから別の拾ってこようかと思います。
マルチスレッドに対応してて大規模ネットワークを想定してそうな奴。
他ゲームに応用が利かなさそうな怪しげなコードが見受けられるｗ
シチョウのコードとかあるっぽいし。
つっても囲連星なら応用効くだろうけど。
逆に１９路囲連星に走るというのも考えられるｗ
まあ勉強にはなるかもしれんがモノになるかは微妙だｗｗ
モンテカルロでも割といい線行ってたんだとちょっと思いました。
なにかもう一度動き出すきっかけが欲しい。
現状の記譜の中に、ランダム着手の記譜が混じっていて、そいつらを
遡るのにものすごく時間がかかる事が経験的にわかっています。
つまり、そこそこ最善に近い手を打っている記譜の遡りは早く、悪い手
ばかりの記譜は遅い。
現状、最善に近い手に対しては、そこそこまともな評価関数になっている
という事は言えるので、一旦遡り対象の記譜を消して、この評価関数で
作られる新しい記譜で継続学習させた方が良いかもと思い始めています…。
3連休も無為に過ごしてしまったorz
あと一日あるけど
過去の奴に当てはめると結構面倒な事になるので、
の予告通り記譜はいったんリセット。
あと、パブリックドロー（残り４０手最善）な記譜が
いくつか見つかったので、そいつらも棋譜に混入。
もっとパブリックドローな記譜が欲しい。
やりっぱなしじゃ勿体ないかもしれないし。
もし学習連続運転してたら火吹いて火事にでもなってたかもな
電源ボタン押すとファンが少し動いて止まってを繰り返す
暑さで逝ってしまったか？
うちは、ここ２〜３日回線ダウンでした。本日ようやくNTTに連絡して再開。
暑さでONUが死んでたみたいです。
棋譜作成は、結局元の棋譜もマージしてしまいました。
おかげさまでえらく時間がかかっています。
何かに追われるように毎日過ごしてましたからね。
メインマシンも壊れたまんまだし。
それはそうと１３日にスレッドリッパー発売ですね。
金がないから買えないけど１ファンとして楽しみにしてます。
そろそろハイクラスPCを買って、完全に放置プレーしようかと思っていたりします。
DCNNに対する興味はすっかり薄れてしまいました。
しばらくはゆっくりしたいですね。
それを機にPC新調してこのスレに復帰するか…
新しいHDD買ってきて動かしてみたけどはずれだった見たいorz
あんまハードウェアのトラブルシュートの経験ないんだよなぁ
ありがとうございます。
しかし、BIOSの画面すら立ち上がらない状態なのでどうしたものか…
もうやる事はないだろうとか思っても、なんか出てくるんですよね。
販売店に持ち込んでチェックしてもらった方が良いかと思う。
ハード障害の切り分けとかスキルとしては面白いけど、今の本題じゃないし。
まあ、やはりここはしばらくお休みをいただいて
Geforce 2080のレビューが出るのをまって
よさそうだったらPC新調してそれから復帰します。
Geforce人工知能系も強化されてるとのうわさもありますし。
性能もいいけど値段もいい値段するとかって話で悩ましいですね。
しばらく様子見か。
対応したとしてどれくらい性能上がるかみきわめてからですかね？
仮に大金だして買うとしても。
地味に棋譜作成を続けていますが、そろそろ色々と重くなってきたので、
裏で新バージョンを作り始めています。探索に関係ないところは、色々
整理して結構軽くなった（と思う）のですが、探索部分の速度が大幅に
低下してしまって悩み中。
現バージョンとまったく同じ条件で比較したところ中盤探索で３倍弱は遅い。
比較してないけど終盤探索は下手すると１０倍近く遅い感じ。
中身はほぼ一緒なので、何が原因で遅くなっているのか不明。
コンパイルオプションなんかは一緒。共通で使用しているclassのどこかに
原因が潜んでいそうなんだけど、違いが見当たらない…
全部取っ払ったら中盤探索については逆に速度３０％アップ。
変な事考えないでコンパイラに任せましょうというお話でした。
１８コア３６スレッドが安くなるかなぁ。
棋譜作成を新バージョンに乗り換えました。
全体的に速くなる修正については、１０〜２０％程度なので効果不明。
あと特定の条件で遅くなる原因を見つけて地味に潰しています。
後者については、一つ原因わかっていて直しようが無いものが。
並列処理にPPL使っているのですが、parallel_forではせっかく並び替えしても
ランダムに処理が走ってしまう事。ybwcなのでPVを最初に実行する事は保証され
ているのですが、PVが間違っていた時に、parallel_for内部で２番目の順位の
スレッドがいつキックされるのかわからないどころか、最悪一番最後の可能性も
ある点です。null window searchでβカットに強く依存しているので、ここは非常に
困ります。
解決策１）parallel_forの改良版を自分で書く
解決策２）スレッド数の多いPCに乗り換えて、この問題が起きる確率を下げる
どうしよう（汗
結局新PC購入に踏み切れてないけど、
来るべきその日のためにGithub漁るところから再スタートしようかなぁ
forwardのロジック（最善手の手順で着手可能な手を展開）を全面改訂。
今まで降りていく手を、BitboardのLSBに近い方から１つだけ選択してましたが、
これによって局面の偏りが生じていたようなので、全て展開するようにしました。
棋譜の増殖が凄い事になっちゃうんだけど、仕方ありません。
同じ仕掛けでbackwardも書き直し。
Eigenの並列化、リソースモニタ見ても２コアしか使っていない感じ。４コア使う指定
しているのに。謎。
その他、並列化できるところは並列化を検討。
やっぱPC欲しい…１２コアくらいでも良いかという気がしてきた。
新しいforwardでは反復深化の評価値を表示するようにしたのですが、探索が進む
ほどに０になっていきます。そこで盤面のパターンが一回も出てこないケース（０値）
を調べたところ、後ろの方が大量に…。前回書いたLSB問題の影響がかなり大きい
という事です。
というわけで、棋譜作成の時には、少なくとも複数選択しあるときにはランダムに
選択するように変更し、既存の棋譜については、仕方がないので後ろの方をランダム
を導入した仕組みで再探索したものを追加していく事にしました。
１件１秒程度でできるので、折に触れてランダム化していこうと思います。
全部展開すると件数が大変な事になるので、様子を見ながらこの辺でお茶を濁して
みようと思います。
久しぶりに再燃したので熱があるうちに…
50万棋譜計画のバグっている棋譜、被っている棋譜を消去して、22マス空きからの読み切り訂正をやってます
プログラムを3つほど立ち上げて一日9万局…めどは一ヶ月ぐらい
最近寒くなってきたのでちょうどいいかなとw
FFO45が32秒ぐらいで、まだまだトッププログラムには及びませんけど、
この棋譜訂正で大幅に縮まらないかと希望を持ちつつ進めてます
とりあえずAQのコードに結構詳細なコメントが付いてることにいまさらながら気づいて
もう一度チャレンジしてみるかどうか迷ってるところ。
はじめまして。新規参入嬉しいですね。
５０万記譜計画の記譜は今はHPからダウンロードできないですね。懐かしい。
評価関数が正しくないと、探索時間かかりますからね。
自分は今は、自作の記譜を後ろから順番に訂正していってます。
が、やはりすごく時間がかかりまするorz
もっと大きな問題な気がしてきました。
マイナスの評価値になるはずの局面から、中盤探索を反復深化で深くしていく時、
途中で評価関数的に未知の局面に入って、評価値０を返すようになる事があります。
もともと期待される評価値はマイナスなので、評価値０のルートに乗り換えてしまい
ます。どうもこの様な現象が起きる事で、探索を間違える事がありそうです。
これから、デバッグ用のプログラム書いて、現象を確認してみようと思います。
もしかしたら、評価関数の初期値をゼロから始めるのが、良くないのかもしれません。
初期値を−１にすると、未知の局面は−６６点（パターンの種類）になるし、１つ２つ
混入したくらいでは、評価値への影響も小さいのかなと思っています。
評価関数のゼロデータを−１にして動かしてみる方が早いかなぁ？
頻度はだいぶ減りました。が、まだ時々おかしな時があります。
デバッグ用のプログラムが案外簡単にできたので、評価値の計算を確認して
みたところ、反復深化の計算のどこかにバグがありそうだという結論に…。
ただ、ほとんどのケースでは正しそうなんだなぁ。
ほぼtypoの類でしたorz
これで探索少し早くなるかな？
原理的にはマイナス評価値の問題は起きそうなのですが、評価値ゼロはあまり
発生していない感じです。
残り２７手読み切りあたりから今のやり方では追い付かなくなって来ていますので、
MPCモドキの導入を考えています。MPCのスレッショルドの計算を真面目に
やると、それだけで日が暮れてしまいそうなので、あくまでモドキですが（汗
置換表から作り直しになるし、記譜作り直しで、まだ２７手まで時間がたっぷりある
ので、１週間くらいじっくり考えてから始めようかと思います。
しかし、何もしないままでただ時間が過ぎていくほうが怖いような気もする。
マジ？
もうしばらく様子見が正解か…
作ってます。とりあえずスレッショルド計算のところまでできました。線形近似と誤差の
標準偏差の計算ですが、以前はループでゴリゴリ計算してました。今回はEigen使って
行列で計算するようにしたら超簡単でびっくりするほど早くなりました。
結局、計算時間の大半は浅い探索になります。
で、結果を見れば見るほど、無理に計算しなくてよいのではないかと思えてきます（汗
誤差は１σ＝４〜５程度の固定値。線形近似は、１次係数は1.0で０次の定数（バイアス）
を、深さが偶数で＋１〜＋２、奇数−１〜−２くらい。探索の深さを変えると、誤差は
減っていきますが、あまり頑張るとオーバーヘッドになります。
そもそもIterative Wideningでは、探索精度ではなく、徐々に探索対象を広める事で、
置換表の精度を上げていく事で高速化をしますので、アドホックな値でも良いのかなと。
誤差やバイアスは今の自分の評価関数での値ですが、気が向いた時に再度チェック
するくらいで良いのかなと思う次第。
というわけで、大幅に簡素化・定数化して、読み切り処理の方に移る事にしました。
かなり入手困難みたいですね。
ZEN2くるかなー？
とりあえず今は待ちか。
いまはRyzen 2700xを買っていつでも乗り換えられる体勢を取るのが正解かなぁ？
ProbCutのバグ取りに時間がかかりました。というか、なかなか高速化できません。
むしろ倍以上時間がかかってしまいます。
もっとひどい事に、今までのやり方のうち、比較的単純なやつが最も早い可能性が
高いという事に気が付いてしまいました…。下手すると４０％くらい早いかも。
ProbCut比では３〜４倍速いという事です。
もともとProbCu自体は中盤探索で前方枝刈するための仕組みです。
これを読み切りしながら順次探索範囲を広げる事でソート順を修正する方向で
活用しようとしているのですが、下位のところを何度も読むオーバーヘッドがあり、
そこを置換表で高速化と考えていましたが、どこかがおかしい…。
そうこうするうちに、評価関数の精度が上がって、反復深化で十分実用になる
ソート順がセットできる事になった模様です。
まだバグの可能性は捨てきれませんが、一旦諦めようかな。
作り直した時に、末端ノードの処理を結構簡素化しちゃったので、やり直しです。
で、Zebraの初期バージョンのオーダリングを日本語で解説した資料を見つけて
色々とノウハウを得まして、Fastest Fastの処理を見直したり、その他色々やった
ところ、速度が倍になりました。
が、見たくない現実としては、まだZebraの当時のFFOテストより若干遅い感じです。
以前はFFO#20限定で０．３秒くらいまで行っていたのですが、まだ１〜２秒前後。
ちなみに、似たスペックのPCでの計測値が公表されているマスターオセロは、
更に１０倍程度高速です。ぬぬぬ。
棋譜作って学習していくと、探索時間が地味に短くなっていくし、時にはオーダリング
の間違いが直ってジャンプするように特定の盤面で高速化する事がありますので、
まだまだ辛抱かなぁ。
それだけだと終盤探索にあまり効き目はなかったようです…
これで終わりたくなくて色々見直したところ、なんとかFFO55が6000秒から2500秒切るレベルまで高速化されました
ただ問題があって、空きマスリストを用意していない影響で、空きマスが2つになるまでビット演算で着手番号を取得してるので、NPSがかなり低くなっています
ここを改善するだけでも20%ぐらいは高速化するのではないかと…今週はそのへんやってみようかと思います
ここから２倍ぐらいになれば、MasterReversiの背中が見えてくるレベル・・・まだまだです
YBWCとかやらないとなぁ
Microsoft Windows 10
Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz
キャッシュサイズ256MB
FFO#40 ( Exact:(a2:+38) 1.19sec node: 12.33[Mn] nps:10323[Knps] )
FFO#41 ( Exact:(h4: +0) 2.99sec node: 35.31[Mn] nps:11825[Knps] )
FFO#42 ( Exact:(g2: +6) 2.86sec node: 39.98[Mn] nps:13961[Knps] )
FFO#43 ( Exact:(G3:-12) 2.49sec node: 25.47[Mn] nps:10236[Knps] )
FFO#44 ( Exact:(D2:-14) 4.08sec node: 40.86[Mn] nps:10006[Knps] )
FFO#45 ( Exact:(b2: +6) 29.92sec node: 449.45[Mn] nps:15022[Knps] )
FFO#46 ( Exact:(b3: -8) 7.48sec node: 87.43[Mn] nps:11687[Knps] )
FFO#47 ( Exact:(G2: +4) 3.71sec node: 49.65[Mn] nps:12851[Knps] )
FFO#48 ( Exact:(F6:+28) 18.78sec node: 216.42[Mn] nps:11523[Knps] )
FFO#49 ( Exact:(e1:+16) 53.12sec node: 655.97[Mn] nps:12350[Knps] )
FFO#50 ( Exact:(d8:+10) 141.11sec node: 1.39[Gn] nps: 9873[Knps] )
FFO#51 ( Exact:(E2:+6) 39.81sec node: 509.68[Mn] nps:12804[Knps] )
FFO#52 ( Exact:(a3:+0) 54.33sec node: 725.60[Mn] nps:13355[Knps] )
FFO#53 ( Exact:(d8:-2) 774.22sec node: 10.74[Gn] nps:13873[Knps] )
FFO#54 ( Exact:(c7:-2) 965.65sec node: 14.37[Gn] nps:14973[Knps] )
FFO#55 ( Exact:(G6:+0) 7124.95sec node: 105.41[Gn] nps:14794[Knps] )
FFO#56 ( Exact:(H5:+2) 244.72sec node: 3.22[Gn] nps:13475[Knps] )
FFO#57 ( Exact:(a6:-10) 926.60sec node: 11.06[Gn] nps:13352[Knps] )
FFO#58 ( Exact:(g1:+4) 551.11sec node: 8.16[Gn] nps:14803[Knps] )
FFO#59 ( Exact:(g8:+64) 0.94sec node: 5.28[Mn] nps: 5626[Knps] )
今回はこちらです。比較になってちょうどよかったかも
FFO#40 ( Exact:(a2:+38) 1.29sec node: 10.63[Mn] nps: 8244[Knps] )
FFO#41 ( Exact:(h4: +0) 2.97sec node: 25.54[Mn] nps: 8599[Knps] )
FFO#42 ( Exact:(g2: +6) 2.24sec node: 20.58[Mn] nps: 9189[Knps] )
FFO#43 ( Exact:(C7:-12) 2.54sec node: 19.23[Mn] nps: 7572[Knps] )
FFO#44 ( Exact:(B8:-14) 4.32sec node: 32.07[Mn] nps: 7418[Knps] )
FFO#45 ( Exact:(b2: +6) 27.68sec node: 294.61[Mn] nps:10644[Knps] )
FFO#46 ( Exact:(b3: -8) 7.56sec node: 68.56[Mn] nps: 9070[Knps] )
FFO#47 ( Exact:(G2: +4) 3.25sec node: 36.70[Mn] nps:11293[Knps] )
FFO#48 ( Exact:(F6:+28) 21.11sec node: 195.99[Mn] nps: 9286[Knps] )
FFO#49 ( Exact:(e1:+16) 34.84sec node: 346.90[Mn] nps: 9958[Knps] )
FFO#50 ( Exact:(d8:+10) 108.94sec node: 960.91[Mn] nps: 8820[Knps] )
FFO#51 ( Exact:(E2:+6) 36.21sec node: 378.54[Mn] nps:10453[Knps] )
FFO#52 ( Exact:(a3:+0) 63.95sec node: 730.82[Mn] nps:11429[Knps] )
FFO#53 ( Exact:(d8:-2) 545.77sec node: 6.17[Gn] nps:11304[Knps] )
FFO#54 ( Exact:(c7:-2) 626.09sec node: 7.42[Gn] nps:11848[Knps] )
FFO#55 ( Exact:(G6:+0) 2492.74sec node: 31.10[Gn] nps:12475[Knps] )
FFO#56 ( Exact:(H5:+2) 212.26sec node: 2.52[Gn] nps:11894[Knps] )
FFO#57 ( Exact:(a6:-10) 520.85sec node: 6.35[Gn] nps:12183[Knps] )
FFO#58 ( Exact:(g1:+4) 588.80sec node: 8.54[Gn] nps:14512[Knps] )
FFO#59 ( Exact:(g8:+64) 1.88sec node: 8.86[Mn] nps: 4722[Knps] )
ttp://s.kota2.net/1542443012.jpg こうなるとオーダリングのコストを下げるしか無くなってきました
自分もi5なので、新しいPCが欲しいところ
せっかくなのでなにか͡コテ名乗ってくれませんか？
まあ無理強いはしませんが。
うーん、壊れる前のマシンの倍くらいにはなってるんですかね？
差しあたっての目標はAQをwindowsでビルドかな
よくみたらキャッシュ256MBってどうゆうこっちゃｗ
気分転換にAQのあらかじめexeになってるものを落として動かしてみたら割とサクサク動く。
そして当たり前だけど強い。
これは期待が高まるｗ
なお、気が短いし、記譜訂正が２６手目くらいまでしかできていないので、
今は#40-#44の５つしか計測していません。昔から#41がピンポイントで遅い。
空きマスのビット演算、ちょうどやったところです。
mobility使わずに、ｆｌｉｐ関数がゼロだと着手不能ってパターンです。
静的オーダリングを使っていますが、角優先×最後って事で。
パターン配列作ってループ回してＡＮＤ版と、先に空きマスをpextで並び替えて、
テーブル引いて元に戻して着手する版と２種類トライしまいしたが、速度差は
誤差としか言いようが無いレベルでしたorz
元に戻す演算を思いついたらまたトライする予定。
本日はProbCutを再トライ。今度はちゃんと高速化しているようです。
スレッショルド１．０σで反復無しで、その結果を用いてアスピレーションウィンドウ
サーチして、少し高速化できたかなぁと言う感じ。
ただ、投機的に高速化しているので、FFOで比較しても、苦手盤面がありそうです。
棋譜が揃って来たら投機のヒット率が上がると信じて、しばらく使ってみます。
自分はSurface3で、i7-4650Uの1.7GHz（2.29GHz）×４です。
キャッシュとかどこで見れるのかなぁ。
使えずにいます。
ZebraはUndo方式で空きマスリストを常時更新しているようです。
僕はCopy方式で、末端の該当ノードで空きマスリストを作ろうとしているので
すが、なかなかうまくできません。
過去にpaint処理みたいな方法で完全な空きマスリストを作成しましたが、
当然オーバーヘッドが大きくて使い物になりませんでした。
最近は「どうせ４隅でしょ？」という事で、盤面を４分割して空きマス計算して
いますが、それでも遅い。
「どうせ４隅」が良くないのか、偶数理論の理解が間違っているのか…
熱風もなかなかorz
あんまり連続実行しないほうがいいのかもorz
メモリに余裕あるからってなめすぎじゃね？
なるほど、では495ということで…
あとキッシュサイズは置換表のサイズです
コテありがとうございます。よろしくお願いします。
CPUのキャッシュかと思ってビビりましたｗ。
CMake用の入力ファイルが見当たらないorz
windowsもBAZELでやるんだろうか？そこからわからんorz
とは思うが腰が重いorz
なんかwindows10とlinuxのデュアルブートは罠があるらしくちょっと怖い。
もっと簡単そうなのに逃げるべきだろうか？
とほほ
だから、日経Linux では、仮想OS を使うように書いてある。
Virtual Box が多いかな
Ruby できるなら、Vagrant, Chef から使うのもよい
漏れは、WSL・Ubuntu16.04 を使っている。
ただし、WSL はGUI なし。コマンドのみ
開発用だから、本番では使えないし、Docker なども使えないけど、
WSLは単なるアプリだから、遊ぶには気楽
最終的にはwindowsでやりたいからそこも悩みどころ。
FFOについては相変わらずさんと比較して速度は半分くらいかな。
一方で記譜作成的には倍速になったイメージ。細かく４σまでWideningして
いる事で、仮探索の誤答が減った事が効いています。
仮探索で増える時間
＞ 仮探索が正解した時に減る時間 ＋ 誤答した時に増える時間
Iterative Wideningで、仮探索時間の削減と正答率の向上の両方が実現できた
感じです。この辺、課題盤面との相性がある話なので、統計的に計ろうとすると
かなり面倒です。というか、統計的に計るためには、前提となる評価関数をロック
しなきゃなりませんが、現在記譜作成しながら評価関数学習させてますので、
前提が常に動いてしまいます。
現在オーバーヘッドが嫌で、ノード数をとっていません。並列化するとロック
の待ち時間で数％〜１０％くらい速度が落ちちゃうからです。ノード数をとれば
純粋な速度比較がしやすいのですが、悩みどころです。
リハビリの意味でもしばらくこれいじってようかな。
囲碁のkgsとかだってかなり廃れてきてるのに
とりあえず、結果だけ求めるのは謹んで、
地道に愚直にディープラーニングの勉強するのが正解だろうか？
続けているだけだからなぁ（汗
目標でかすぎるとか、期限切りすぎると、焦って嫌になるだけだよ。
オセロなんて、既にやってる人ほとんどいないから、ちょうど良いのだｗ
今の目標は、６０歳になるまで続ける事ｗ
結局自分のペースで一歩一歩進んでいくしかないですよね
ありがとうございます
以前、途中までうまくいきかけた9路囲連星を移植したalpha zero クローンのコードを読み解くのやってみようかなぁ。
それとももっと本とか読んで理論の基礎から固めていくべきだろうか。
前のマシンではメモリリークなかったのに？
OSとかpython とかCUDAのバージョンが変わったせいだろうか？
うーん、解決する気力がいまいち湧いてこないorz
うーん。
(;SZ[19]
;B[jj];W[ji];B[ii];W[hi];B[ih];W[ik];B[ki];W[jl]
;B[hh];W[ij];B[jh];W[lh];B[gg];W[ff];B[fg];W[gi]
;B[kg];W[eg];B[lg];W[hg];B[hf];W[jg];B[jf];W[km]
;B[ig];W[hj];B[fh];W[ln];B[mo];W[lj];B[hg];W[mj]
;B[jg])
自然な流れからのダブル必勝形。
こういうのがたまにあるから止められないんだよなぁ。
でも正しく打てばたぶん黒の勝ち。
せめてなにかこれだという方針が定まらないと。
焦っちゃダメと頭では分かっていてもついｗｗ
その線で探ってみるか
無駄になるかもしれないけど、何もしないよりはいいよね？
なかなか圧巻ですな
ファンがうるさいけど
開発用と計算ぶん回す用で２台欲しいｗｗｗ
ありえないけど。
自分のは並列化処理に使用コア数カウンタ入れて、同時並列数を制限している。
もっとも常に４コアで４多重マックスで動かしているけどorz。１６コアなら１つくらい
他のプロセスに空けても、あんま速度低下なさそうでうらやましい。
今現在は記譜作成がメインなので、気が向かない時もほっとけば棋譜を訂正しながら
勝手に学習して、少しづつ速度アップしてくれている。気が向かない時に焦らずに済む
のでお勧め(^^;
一時速度アップに燃えていたけど、１勝９敗以上の比率で速度アップに失敗して（まあ
そんなもんなんだけど）、今は停滞期間中ｗ
その手がありましたねｗｗ
作業中は１２プロセス位にしとくか
なにはなくとも棋譜取りだけはコツコツつづけます。
一日で多分３〜４０００局くらい取れるはず。
ちなみに今これ見てるけど速攻挫折しそうorz
ttp://https://github.com/HerveFrezza-Buet/RLlib 思ったより取れてる。
まあ、棋譜取りしてるだけでもいくらか気がまぎれるけど。
１００万局目指すか。
ここまで長かった
つかリンクオプションで-lgslつけなきゃいけないとかずっぽり嵌ったわ
久々にプロファイラで確認したところflip関数が３０％、mobility関数が８％ほどでした。
Edaxのソース見つけたので禁断の答え合わせ。flip関数は一つ昔のタイプなので、
恐らく自分の方が早い。mobilitiy関数は少し早そうなので、考え方を導入。でも誤差
範囲の効果しかなかった。
速度計測ルーチンを作って、並列単体速度比が１．２程度しか無い事が判明。
並列処理で排他待ちしそうなところに無駄がないかチェックしたところ、ほぼ全部無駄
だった事が判明（汗。無駄箇所を全て削除したけど、誤差範囲（汗
後方枝刈（ヒューリスティックスなオーダリング）が気になるので、ノード採取してみた。
やはり２割程度速度ダウンするので、プリプロセッサで普段は切り離す事に。
その他もろもろ誤差範囲の改良を積み上げた結果、なんとなく１〜２割は速度アップ
した気がしますが、並列処理の効率が悪いのと、後方枝刈の工夫が足りていないの
２か所が、これからの課題かなと思います。
あれ？なんか、ループしてmin-Max探索の高速化に目的が戻ってきている（笑）
全部無駄だった？
www
浮き草のような人生だ。
今これ見ようとしてます。
ttp://https://github.com/novoselov-ab/ai-zero とりあえずいまVSインストールしてる
久しぶりに一歩進んだ気分。
うーんなんだろ？
他人のコードってなによりいまいち情熱が湧いてこない。
でも他人のコードも読めるようにならないと先はないんだろうなぁ。
我流じゃすぐ限界迎えそう。
悩ましい。
windows10でも変わらずか…
今、LV3 vs LV3の棋譜が61950局分溜まってます。
ファンがうるさいから夜中は回してないから日中だけなのにこのペース。
8コアはさすがといったところか。
アルファ碁Leeが16万局分の棋譜を使ったらしいからとりあえずその辺目指すか。
していたけど、ある日突然２０％くらい悪化。元に戻せるところは戻したけど、
結局ダメで、裏で評価関数の学習し続けた結果、途中経過でたまたま探索が
悪化するところにはまってしまったと言う事かなぁと。
実際、悪化しているの#49だけで他は改善していたし、学習都度表示している
FFO問題の８手読みの次の一手の合否が、14/20から11/20に悪化している。
こういうのあると、速度アップで何を信じて良いのかわからなくなるよね…
ノード数に圧倒的な差が。NPSは速いけど、それ以上にノード数が多い。
枝刈の差というにはあまりに大きな差で、一桁近い差です。
これ、Iterativeな手法で生じる置換表探索の差じゃないかと思う。
自分のは置換表の動作が遅いので、あまり深い探索まで置換表を適用できず、
読切において後ろの方は置換表が無い（そもそも使用していない）事で、何度も
再探索しているからかなと。
concurrent_unordered_mapを使っているけど、自前でハッシュDB作った方が
良いかもと思い始めた。そこで速度アップすると、置換表適用深度を深くできる。
こういう時、自前で作る人はチェーンハッシュ使っているのかな？
自分の場合STLでいいじゃんみたいな結果でした。
テーブルのサイズをでかくすると意外と巡回が遅くなるみたいな。
パターンをかなり覚えて７割くらい勝てるようになりました
囲碁とかも真の棋理が明らかになった方が
逆に人間がコンピュータに勝てるようになるかもしれませんね
インターフェースを既存のstlに合わせようとか思って調べ始めたら面倒になりました。
で、色々見ていたら、そのまんま効率化できそうな使い方を見つけた。
有れば読み込んで更新、無ければ追加の方法です。
あとバケットサイズとか個数とか、その辺を調べていった方が早くなるかも。
並列処理だとtry_emplaceが使えないのね。これが使えたらきっと早くなるのに。
まあいいけど、もう諦めぎみ。
なんか仕事が急に忙しくなってますますコーディングから遠ざかってますが、
棋譜だけは地味に溜まってます。今82889局分溜まってます。
並列化ハッシュってどんななんですかね。そういえば知らない。
Hash関数がきちんとばらけさせてくれたら、基本的にあんまり排他で捕まる事は
無いので、それほど気にしなくてもパフォーマンスに影響ないかなぁと。実際に
concurrent_unordered_mapの配列用意して、適当にハッシュでばらけさせて格納
してみたら（つまり、同じmapじゃなければ排他はおきない）、排他で遅くなっている
訳ではない事が確認できています。
と言いながら、iteratorとか考えだすと、何を並列セーフにして、何をアンセーフに
するかみたいな事で悩んじゃいます。
先日の続きでmax_load_factorとかbacketサイズとかいじってみましたが、
パフォーマンスにほとんど影響がないです。というか、どうせ後で逐次的に拡張する
くらいならと、backetサイズを増やしても性能は上がらないし、max_load_factorを
増やしても、性能が落ちるだけだったり…。
棋譜作成だけなら並列化レベルをもう１段上げて、４記譜同時作成とかすれば、
個々の読み切りはシングルスレッドに下げられて、ただのunordered_mapが使えるし
その方が棋譜作成的には速度アップしそうな気がしてきた（汗
FFO的には別処理になるけど。
確かにうち筋は変わってる気がしますが強くなってるかはよくわからないというorz
まあ序盤DBは誤魔化しみたいなものだから期待しすぎもよくないか。
やはりモンテカルロに代わる何かを実装しなければ…
１３０MBくらいなのにUSBメモリってやっぱ遅いんだな。
並列処理の基本は、なるべく上位の層で並列化すべしでした。
現状、並列探索の速度は、シングル探索の２倍程度です。
１つ１つの探索には時間が2倍かかるけど、４つ並列なので、トータルでは
半分の時間で処理できるので、実質２倍みたいな。
探索中のオーバーヘッドはほぼ無いはずで、待ち合わせロスくらいなので、
大量に一気に処理する分には、ほぼ無視できるかなと。
これやると、スレッドの数がモロに効いてくるんで…４８並列くらいできたら…
AMDでもzen2はかなりコスパいいものが来ると思いますが…
やっぱそうなのか。
1/4くらいになっているイメージ…。深さが深いものほど遅いという事は、
置換表周りかなぁ。
棋譜作成する対象によって速度が結構変わるので、評価しづらい。
メモリー配置等の問題も考えないといかんような気がしてきた。
いかん。夜も更けていく…。
なんか、フラッシュメモリー自体は書き込みが遅くて、SSDだとその辺を並列
化とかキャッシュとかで回避しているらしいです。USBメモリーは、その辺真面目
にやっているもの（高価）と、そうじゃないもの（安価）で差があるけど、それでも
SSDには敵わないとか。
深層学習のプログラム、組みたいなぁ
でも難しいんだよなぁ
シングルmin-Maxの並列動作と、パラレルmin-Maxのシングル動作。
どうも速度的には大差ない感じ。
２倍くらい速度出ると思ったのに…。
スレッド数が増えたら差が出てくるのかなぁ。
並列探索で６分。シングル単独動作で１２分。シングル４並列動作で１８分。
やはり、シングルも４並列する事でなにがしかのオーバーヘッドがあるようです。
単純計算だと並列探索６分を４個で２４分に対して、シングル１８分で４つ解ける
事から３３％の速度アップが見込める事になるけど、体感そこまでの効果が感じ
られないというか、時間がかかる問題では更に差が大きくなっていて、そいつらに
足を引っ張られている印象。
そのうえで、裏でゴソゴソやりながら計算させる時に色々弊害があるので、
CPUの増強を決断するまで放置しようかと思います。
色々あがいた結果か、並列探索ですこーし速度アップした感じ。
１０％行くかいかないか。
無いので、もうちょっと性能出るんじゃないかと思っていたのです。
あと、うまく説明できないけど、ノード数が多い探索は、ノード数比以上に
時間がかかっている気がしています。まだ感覚の話ですが。
直せるもんなら直したほうがいいんだろうけどかなり大変だろうな
パラレルで解いたら１時間４０分だった。空きマス２６だと通常１分程度なんだけど、
時々こういう時間がかかる盤面がある。今までテストが面倒なので、１０分以内に
終わりそうな奴でテストしていたけど、もしかしたら探索ノードが多い奴ほど、
シングル並列動作での速度低下が大きいのかも知れない。
時間がかかる奴ほど、シングル・パラレル比が悪化するなら、今考えている大体
３倍程度ってのは成り立たなくなって、もっと悪い事になる。それなら感覚的に
合致する。普通に流れている時には、シングル並列で高速化できそうな手ごたえ
があるんだけど、時間がかかる盤面が来ると急速に逼塞していって、なかなか
回復しないという感じ。
パフォーマンスモニタにらみながら、unordered_mapのメモリアロケーションの方法
を想像してみた。初期確保件数指定（倍々で自動追加される）してみたけど、溢れて
もいないのにダラダラとメモリー使用量が増えていく。もしかしたらOSにメモリーを
貰いに行く動作が排他待ちになっているのかも知れない。どうやって検証しよう。
やっぱ自前置換表作るしかないのかなぁ。
ヒープをダラダラと確保するのが気になったので、色々いじりました。
ordering用のvectorを、配列にしてスタックに。ついでにクラス化してメンテ性アップ。
少しだけ速度アップした気がする。
自前ハッシュテーブル型の置換表を作ってみた。
最初に大きく領域確保して、溢れた時以外領域確保しないようにした。
基本、余計な機能は実装していないので、処理は軽いはずなんだけど…
極ほんの少しだけ速度ダウンした感じ…
記譜作成はunordered_map版で実行しながら、改良をしてみたいと思います。
とはいえ、ソース的にはあんまり改良の余地がないんだよなぁ。
速度がそん色ないところまで行けたら、シングル版の並列での速度低下が
メモリー確保が原因か検証できるかなぁ。
メモリー獲得し始めるので、オープンアドレス型に変更して、まとめて領域を追加
するようにしました。
この辺、もう趣味の世界ですね。
何をしても、速度は上がりも下がりもしない（汗
やっぱり探索ノードを減らす工夫が重要ですね。
せっかく棋譜も集めてるので教師あり学習をやってみようかと思案中。
そろそろ寝るか。。。
プログラミングってこれがあるから怖いよねｗ
そんな感じ。
いかん、寝なければｗｗ
質のいい棋譜がそれだけ集まればいいですがそれはほぼ不可能ですし…
囲碁将棋でいえばアマチュア３段くらいには相当するはず。
でもまあ強い時はかなり強い。
なんとなく読み取りが変な感じなんだけど、どこがおかしいのか全くわからず。
棋譜たくさん集めて序盤DB作ったら、その序盤DBのMax手順以外の手について
は、分岐した以後の盤面だけで学習させると序盤の穴が埋まるというか、間違った
盤面でぼやっとした学習するの避けられるかも。
今、序盤についてはそのやり方で学習させてます。
グラボ使えればちっとは違うんだろか？うーむ。
ここに愚痴ると、直後に原因がわかる罠ｗ
この数日の葛藤は何だったんだ。
Tiny-DNNはGPU対応していないんじゃないかなぁ。
結局、DCNNはGPUで処理しないと無理っつー気がする。
あ〜やっぱそうなんですかねぇ。
GPUも結構いいの買ったのでぜひ活用したいところではあります。
社会人として自制しなければｗｗｗ
そういやそんなのあったな。orz
初期化したら損失減ったｗ
ちょっと希望が出てきた。
ネットワークの形状が悪いんだろうか？学習率だろうか？
うーん、深みにはまりそうorz
普通のSGDだと、あちこちぐるぐる回ったり、平野トラップで立ち往生したり、
局所最適解から抜け出せなくなったり。また、SGDは学習率（α）を大きくすると、
簡単に発散しちゃったりしますので、学習率を低めにして１０００回とか学習する
事になります。それでも上記の問題で、なかなか収束しなかったり、うまく学習
できなかったりします。
そういうものなのです。昔は、初期値（乱数設定しているはず）を変えてみたりして
トライ＆エラーしてましたが、今なら別のオプティマイザ（RMSpropやADAM）を試す
べきかと思います。それでも数百回は学習を繰り返さないといけないと思います。
久々に検索したら結構種類が増えてた。
ttp://https://qiita.com/ZoneTsuyoshi/items/8ef6fa1e154d176e25b8 自分は線形回帰モデルですが、SMORMS3を使って効率化を図っています。
それでも、数百回学習しないと損失は落ち着いてきません。
生じないようにし、メモリーをある程度のサイズでまとめて確保する、チェーン型
ハッシュに落ち着いています。
普段速度計測に使っているFFO#40-49ではconcurrent_unordered_map版より若干
遅いのです。が、どうも残り２８手（現在はそのあたりをチェック中）では、自作チェーン
ハッシュの方が早いというか、ノード数が増えた時に速度低下が少ないように感じて
おり、現在は自作置換表を使っています。
とはいえ、２９手や３０手まで行った暁にはチェーン接続が多発し始めて速度低下が
始まると思われるので、対策を考えて行きたいと思います。２８手が終わるまでまだ
一カ月くらいかかるので、幸か不幸か時間はたっぷりあります(--;
今のところチェーンの代わりに２分木を置いて、ハッシュが衝突したときの速度低下を
O(n)からO(log(2)ｎ)にしてみようかと考えています。
棋譜がまずいのかな？
生活のリズム崩すのはいくない。
これだというアイディアが湧くまでこねくり回すしかないか。
うーん。
でも難しいんだよなぁ。
とくにウィンドウズだと。
この辺が限界かなぁ
それともぞうきんを絞るようにまだまだ損失減るんだろうか？
とことんまで回すと今度は過学習も怖くなってくるし。
こちらは、自作concurrent_mapクラスができました。
ハッシュキーは二分木で、ハッシュ値は64bit。
配列ハッシュキー版と同様に、削除もiteratorも無し。
すこーし速度があがったかなぁ程度。
衝突時の処理はチェーン式。流石に64bitだとキーの衝突が無い。
棋譜訂正は時間がかかるので、暇つぶしが必要な状態。
二分木を赤黒木に変えてみようかと思い始めています（汗。
本当はヒューリスティックスの改良の方が効果あるんだろうなぁ。
でも土日は休める。
いかんのではないかと…。置換表のように追加の頻度が高いケース
では、排他待ちでパフォーマンス出ないかも。
まあ、やってみるしかないけれど。
さすがですな。
うーん。
単に学習量がたりてないのかなぁ。
混乱してきたorz
層減らしたら違う値になった。
まあDNNの学習の効果の勝利というよりも序盤DBと詰みルーチンの補助による勝ちなんだけどね。
でもとりあえず、それっぽく動くところまで来ました。
でもランダムよりはマシに見える。
こんなにプログラムが楽しいの久しぶりやな
ていうかあればあるほどいいい。まだまだ良くなる。
可能なら１００万局を目指したい。
元々ハッシュでランダマイズしているから、二分木の末端ノードまでの深さは
綺麗な正規分布になっていて、赤黒木にしても木の最頻高さで３割程度しか
小さくならないという事で、ツリーを修正するオーバーヘッドが効いているのか、
それとも木全体でしか排他できないのが原因なのか。
もうちょっと調べてから諦めます。
じぶんで開発したとして対戦相手=プログラムありますか
とりあえず、落ち着いて。
過去ログから読んでください。
まあ、βカットの具合でだいぶ変わるので、学習進むと減るんですが。
最低でも残り３０手まで行くつもりなので、１０００万くらいは想定したいです。
次の一手ソート用の配列は、Array型にしています。３２個確保すれば足ります。
こちらも比較したところ、明確に速度差がありました。この辺から、領域をチマチマ
確保されるオーバーヘッドが気になりだした次第です。
で、赤黒木ですが、実装が悪いのだと思いますが、現時点で２分木と比較して
およそ３倍時間がかかります。シングル動作でも同じくらいの差になるので、
排他待ちではなく、木のつなぎ替え処理の重さが原因かなと。置換表は追加が
の比率が大きいので、ポインタたどるロスは優位ではない感じ。
というわけで、赤黒木はちょっと放置。
というか、二分木もシングル動作は１０倍くらい速い感じなので、今一度シングル
探索の並列化を試そうと思っています。
min-Max前提だと、探索値を求める際には勝率（点数）が必須で、
次の１手評価関数はオーダリングや前方枝刈向きではないですか？
探索深さ１なら次の１手で行けますが。
初代アルファ碁も、両方組み合わせていますが、次の１手評価関数で
手の優先順位をつける事で読み深さを実現した変則mctsで、最終的には
評価値で判断していますよね。
もうしばらく勝率で学習させてみます。
本当は小さいネットワークでエポック数を稼いだほうがいいのかもしれない。
だったら対象局面ありの方が良いと思う。
オセロは悩み中。
初手をF5固定にした時に、本当に対称局面が出てくるのかわからない。
対称局面が同じ重要性で生じないのであれば、評価値を希釈しちゃうだけ。
学習の時間も単純に倍々で増えるので、今はやっていない。
強いて言うなら、F5F6E6の次がF4とD6で斜め対称になるので、ここだけは
記譜作成時にはF4固定にして、D6の対称局面を作っている。
一旦リセットして、最初からやり直して、当初の目的に戻ろうと思うorz
とくにDeep Learningさせてると（ネットワークの規模にもよりますが）だいぶ過学習しなくなります
もっとも、Deep Learningするんだったら対称性を考慮したネットワークにしたほうがいいのかもしれないですが・・・
オセロは着手可能場所が限られるので、現れない局面が結構ありそう。
ちなみに、オセロは８倍じゃなくて４倍。初期配置が４対称だから。
囲連星は初手天元固定なのかな？
たしかに棋譜で考えると4対称しか無いですね
今のところ、学習させるときには現局面しか渡してないので、
90度回転で一致する局面が存在するかもしれないから8倍で良いはず…
出来れば自己対戦による強化学習とか取り入れたいな〜
対称局面もやってみますね。
スリープは解除してるはずなんだけどなんなんだろう？
そんなLV0といい勝負の俺のAIもあれだけど。
やればやるほどLV3の完成度の高さが際立つ。
結局のところ、unordered_mapを作っていた形になります（汗
当初は領域の追加について、データ部分をまとめて追加する方向で改造し、
ハッシュ配列については２２ビット固定で、高速化をしました。で、ハッシュ配列が
２２ビット固定は芸がないと、二分木・赤黒木などを試しましたが、速度大幅低下。
要するに、unordered_mapにmapを組み合わせて、ハッシュのメリットを相殺して
しまっていたという事で。
最終的に、ハッシュ配列の追加方法をようやく思いつき、組んでみたところ、それが
そのままunordered_mapのrehashだと気が付きました（汗。その後、max_load_factor
などを追加して、unordered_mapと条件を揃えて速度比較となりました。
iteratorと削除が無い分だと思いますが、unordered_map、concurrent_unordered_map
に対して、それぞれシングル版、concurrent版とも若干高速になりました。
新たな課題は…stlも自作版も、どちらも並列に動かしたconcurrent版の方が遅いと
言う事です。もともとそういうものなのか…テスト方法が並列向けじゃないのか。
4対称で16GB位食ってる。
ケチらず64GB積むべきだったか？
これは厳しいorzorzorz
GPUが使えれば…
対称局面を入力とすることで特徴量がよりはっきりしたということだろうか？
まだわからんが。
対称局面学習以後はどちらかというと知性があるっぽく見える。
まだわからんが。
まだわからんが。
Googleに匹敵するマシンパワーが！
でも希望が出てきた。
モンテカルロは強いけど思考時間長すぎたからな。
まさか32GBで足りないとは…
多分DNNのみより強くなってます。
10局目
黒(airandom.dll)の勝利回数: 8
白(ai-lv1.dll)の勝利回数: 2
まずまずの結果かな。
ちなみに白番はうまく動いてなくて１の１とか打っちゃうので途中で中断しました。
悪くない手ごたえがあったと思いましたが…
25局目
黒(airandom.dll)の勝利回数: 15
白(ai-lv1.dll)の勝利回数: 10
詰めろがあるときは詰めろを優先的に打つ。
当たりの点数を恣意的に上げる。
DNNでLV3に初勝利！
(;SZ[19]
;B[jj];W[kj];B[ji];W[jk];B[kk];W[kl];B[lk];W[ih]
;B[li];W[mj];B[lj];W[kh];B[ki];W[mi];B[lh];W[ll]
;B[lg];W[lf];B[kf];W[ik];B[le];W[mf];B[jh];W[mk]
;B[ke];W[ml];B[kj];W[kg];B[jg];W[mh];B[mg];W[mm]
;B[mn];W[kd];B[kh];W[ld];B[kg])
対LV1も流しなおしててこんな感じ
24局目
黒(airandom.dll)の勝利回数: 18
白(ai-lv1.dll)の勝利回数: 6
ぐっとこらえてすべての源泉である棋譜取りにリソースを回すのが正解かも？
長いトンネルを抜けたようだ。
まだまだ負け越すだろうけど、偶然の勝利じゃないってことか。
(;SZ[19]
;B[jj];W[ik];B[ii];W[jk];B[kk];W[lk];B[ll];W[kj]
;B[kl];W[hh];B[mm];W[ji];B[ij];W[ih];B[nn];W[oo]
;B[jm];W[ml];B[hg];W[hk];B[om];W[lm];B[ln];W[nl]
;B[nm];W[im];B[pm];W[km];B[kn];W[pp];B[km];W[qp]
;B[lm])
そろそろ切り上げるかｗｗｗｗ
ちょくちょく長連に引っかかる
コア数は足りてるはずだがメモリ帯域が足を引っ張ったのだろうか？
奥が深いすな。
まずは大量の棋譜を手に入れる。
量が質に転換する地点が必ずあるはず。
でも計算量がどうなるかだなぁ。
遅いのはコリゴリ。
3手は計算量的に相当厳しそう。
１手読みから明らかにうち筋が良くなっている。
もし３手読みにしたら…
計算時間がやばいので前方枝刈で思いっきり枝刈してます。
今すごくいい勝ち方しそうだったのに！
(;GM[1]FF[4]AP[Zenith:7.0]SZ[19]HA[0]KM[6.5]CA[UTF-8]PB[]BR[]PW[]WR[]
ZT[60]DT[]RE[];B[jj];W[ik];B[kk];W[hj];B[ii];W[jk];B[ll];W[hh];B[mm];
W[nn];B[hi];W[gi];B[jl];W[hl];B[ki];W[km];B[lh];W[mi];B[kg];W[kl];B[ke];
W[kf];B[jf];W[lf];B[jd];W[ie];B[je];W[ig](;B[jg];W[jh];B[ih];W[ji];B[kh];
W[jh];B[ji];W[gg];B[jh])(;B[kh];W[jg];B[ih];W[gg];B[nm];W[gk];B[fh];W[gh];
B[gj];W[fj];B[gl];W[ek];B[fk];W[fl];B[mk];W[gm];B[mh];W[gl];B[jh];W[gj]))
もしこの勝ち方ができてたら瞬間最大棋力は名人に届く、ってくらいすごかった。
正直、もっと勝てるかと思ってました。
まだまだ精進せねば。
41局目
黒(airandom.dll)の勝利回数: 33
白(ai-lv1.dll)の勝利回数: 8
58局目
黒(airandom.dll)の勝利回数: 48
白(ai-lv2.dll)の勝利回数: 10
32局目
黒(airandom.dll)の勝利回数: 6
白(ai-lv3.dll)の勝利回数: 26
;B[jj];W[ij];B[ik];W[hk];B[hj];W[ii];B[hl];W[gk]
;B[gm];W[ki];B[jl];W[fl];B[km];W[gi];B[ji];W[jh]
;B[lm];W[im];B[il];W[in];B[ml];W[ll];B[lk];W[gl]
;B[nl];W[kl];B[kk];W[ol];B[ll];W[pl];B[kl])
;B[jj];W[ij];B[ik];W[hk];B[hj];W[ii];B[hl];W[jk]
;B[gk];W[hi];B[jl];W[kk];B[gi];W[km];B[kl];W[im]
;B[il];W[gl];B[gm];W[fl];B[ki];W[fn];B[lk];W[mk]
;B[fk];W[lh];B[kj];W[jn];B[kk];W[mg];B[hk];W[ng]
;B[jk])
ターボブーストが利かなくなる分クロックが落ちるということだろうか？
結構違いますね。
38局目
黒(airandom.dll)の勝利回数: 37
白(ai-lv1.dll)の勝利回数: 1
28局目
黒(airandom.dll)の勝利回数: 28
白(ai-lv2.dll)の勝利回数: 0
30局目
黒(airandom.dll)の勝利回数: 12
白(ai-lv3.dll)の勝利回数: 18
バグか。
ゲタ打った！！！
(;SZ[19]
;B[jj];W[ji];B[ki];W[ii];B[ik];W[kh];B[jh];W[kj]
;B[li];W[hi];B[lh];W[mg];B[kk];W[lj];B[mi];W[mj]
;B[ni];W[ij];B[jk];W[hk];B[nk];W[gl];B[kg];W[fm]
;B[en];W[hm];B[gj];W[il];B[mh];W[hh];B[hj];W[gi]
;B[oh];W[fi];B[ih];W[ei];B[di];W[jg];B[nh];W[ig]
;B[kh])
この衝撃がみんなに伝わるかなぁ。
なぜ？
置換表は、だいぶ前にリハッシュ対応して、この辺にしとこうか状態になってます。
多分unordered_mapの仕組みはそこそこ理解できたと思います。
deleteとガベージコレクション、iteratorを除いてですが。
Edaxのソースを解析しようと、VC++で読み込んでみましたが、Edaxは裸のCで…
_s地獄とコンパイラの違いで、動かすところまで持ち込むのが相当大変な感じ。
一番の地獄は、探索部のソースを見ても何がなんだかわからない事。
せめて偶数理論のところは見つけたいんだけど。滅茶諦めモード。
というわけで、記譜作成を動かし続けるしかなくなってしまいましたorz
WZebraのソースが見たい…。
メモリバスの帯域とか、L2キャッシュ溢れとか…
わかっているけど、エビデンスが取れないので、認められないorz
パッと見成立しないんだけど、なんとなく味が悪いことわかってるんだな。
すごい！
(;SZ[19]
;B[jj];W[ji];B[ki];W[ij];B[ii];W[jk];B[jh];W[li]
;B[kk];W[kg];B[ik];W[jl];B[hj];W[lj];B[lh];W[hl]
;B[jg];W[if];B[mk];W[lk];B[ll];W[kl];B[kj];W[lm]
;B[ml];W[mm];B[mi];W[il];B[mj];W[gj];B[nj];W[lj]
;B[li];W[jm];B[lk];W[oi];B[ij];W[pi];B[lj])
マルチ性能も大事だけどシングル性能も結構大事で
並列計算するか結構悩みどころですね。
学習結果が早くほしい時は棋譜取りしないというのもありっちゃあり。
むしろ中盤力のほうが勝り始めてる気がする。
序盤DBが物足りなく感じる。。。
日中は棋譜取りに専念するのが吉か？
１７手目が面白い手でうまく必勝形につなげた。
正直この手は俺にも見えてなかった。
(;SZ[19]
;B[jj];W[ij];B[ii];W[hi];B[ik];W[ih];B[hj];W[gh]
;B[gi];W[fj];B[hh];W[hg];B[fh];W[jl];B[gg];W[kk]
;B[kh];W[ig];B[li];W[fi];B[mi];W[ji];B[jh];W[km]
;B[ki];W[ln];B[hi];W[mn];B[ji])
オーバーヘッドが極小なのは、オーダリングへ影響する値だけゼロにして、
ほぼ速度低下が無い事で確認済です。が…何をどうしても速度がダウンします。
というわけで、またしても偶数理論挫折。
次ネタ考え中。
ネタを一つ見つけたけど、結構全面改訂になりそう。
とりあえず、棋譜取りだけは地味に続けるけど。
FFO40-49のタイムは３０％強短縮した。
FFO40が悪化して、49はだいぶ短縮しているので、探索深さが深い方が
効果が出る傾向に見える。という事は、残り２８か所空きをやっている棋譜
作成では、もっと改善する可能性あるかも。
思い込みって怖い。正直、何故今まで思い付かなかったのだろうというレベルorz
白番でLV2に勝ちました！
(;SZ[19]
;B[ef];W[eg];B[fg];W[fh];B[eh];W[dg];B[gh];W[fi]
;B[gf];W[di];B[df];W[fe];B[cg];W[dh];B[gi];W[ff]
;B[gg];W[ge];B[hi];W[ej];B[ij];W[de];B[hd];W[hj]
;B[he];W[if];B[hf];W[ih];B[hh];W[ig];B[hc];W[hg]
;B[gj];W[hk];B[gl];W[gk];B[fj];W[ei];B[cd];W[cf]
;B[jk];W[kl];B[ed];W[ee];B[ek];W[dj];B[jh];W[dk]
;B[il];W[df])
残り２８手空きの記譜作成は、トータル倍弱まで速度アップした模様。
とはいえｌ、記譜作成の方は、解く問題によってばらつきが大きすぎる
ので、もう少し様子を見ないと、どれくらい早くなったかはなんとも
言えない。早くなったのは確実。
さて、またネタが無くなった（汗
序盤DBに取り込んでもいいかなってちょっと思うようになった。
lv3が強すぎてlv2のいいところが取れないっぽいんだがｗｗｗｗ
これは計算外
思ったよりはlv2が善戦してるかな？
15局目
黒(airandom.dll)の勝利回数: 13
白(ai-lv1.dll)の勝利回数: 2
14局目
黒(airandom.dll)の勝利回数: 14
白(ai-lv2.dll)の勝利回数: 0
7局目
黒(airandom.dll)の勝利回数: 0
白(ai-lv3.dll)の勝利回数: 7
10局目
黒(ai-lv1.dll)の勝利回数: 1
白(airandom.dll)の勝利回数: 9
6局目
黒(ai-lv2.dll)の勝利回数: 3
白(airandom.dll)の勝利回数: 3
6局目
黒(ai-lv3.dll)の勝利回数: 3
白(airandom.dll)の勝利回数: 3
lv1には文句なく勝ってますね。
lv2もトータル勝ち越せるかも。
lv3は白番でいい勝負なのはすごいですが、
黒番で勝ててないのが気になりますね。
序盤DBが完全に筋に入ってる感じですかね。
対lv3の戦績もlv2 vs lv3の戦績と比較して決して悪くないです。
40局目
黒(airandom.dll)の勝利回数: 36
白(ai-lv1.dll)の勝利回数: 4
42局目
黒(airandom.dll)の勝利回数: 42
白(ai-lv2.dll)の勝利回数: 0
25局目
黒(airandom.dll)の勝利回数: 9
白(ai-lv3.dll)の勝利回数: 16
50局目
黒(ai-lv1.dll)の勝利回数: 7
白(airandom.dll)の勝利回数: 43
30局目
黒(ai-lv2.dll)の勝利回数: 22
白(airandom.dll)の勝利回数: 8
33局目
黒(ai-lv3.dll)の勝利回数: 24
白(airandom.dll)の勝利回数: 9
ちょっと気を抜くと負かされてしまうような怖さが。
lv2とlv3にはそれがある。
50局目
黒(airandom.dll)の勝利回数: 45
白(ai-lv1.dll)の勝利回数: 5
50局目
黒(airandom.dll)の勝利回数: 50
白(ai-lv2.dll)の勝利回数: 0
40局目
黒(airandom.dll)の勝利回数: 14
白(ai-lv3.dll)の勝利回数: 26
50局目
黒(ai-lv1.dll)の勝利回数: 7
白(airandom.dll)の勝利回数: 43
48局目
黒(ai-lv2.dll)の勝利回数: 39
白(airandom.dll)の勝利回数: 9
46局目
黒(ai-lv3.dll)の勝利回数: 32
白(airandom.dll)の勝利回数: 14
ホントは全部50局打ちたかったんだけど時間がかかるので打ち切りました。
結局、生勝率が一番いいのかな…
ttp://https://github.com/okuhara/edax-reversi-AVX は VC でもコマンドラインならビルド可能です。(NMakefile)
（本家の Edax も NMakefile は付いているが、多少変更が必要）
Edax の偶数は基本的に Zebra と同じ。QUADRANT_ID あたりを追ってみては？
情報ありがとうございます。そのソースなのですが、コマンドラインなのですね。
ビルドしたかった理由はデバッグモードを使いたかったからです。
QUADRANT_IDのあたりは追っかけたのですが、もともとの探索の構造が
読めなくて、デバッグモードに頼ろうとした次第です。
で、処理内容を予想して自分で組んでみたのですが、FFOテストでは速度が
若干ですが、落ちてしまうのです。
あと、実はVC++しか使った事ないというか、オセロ開発でC++使い始めたので、
makefileが何やってるのかわからないです（汗
というわけで、ちと調べてみます。
動くだけでも、自動対戦の相手になってもらえる可能性ありますから。
ちょっと意外。
とりあえず、自己対局による強化学習をぼちぼち何とかしたい。
(;SZ[19]
;B[jj];W[kj];B[kk];W[ji];B[lj];W[ki];B[ij];W[lk]
;B[ll];W[mk];B[ii];W[ml];B[mm];W[nn];B[hh];W[gg]
;B[oo];W[on];B[ih];W[nm];B[po];W[mj];B[nk];W[ok]
;B[ol];W[ni];B[nl];W[mo];B[ln];W[mn];B[lm];W[li]
;B[hk];W[oj];B[oi];W[pi];B[oh];W[qj];B[pk];W[nj]
;B[pj];W[pl];B[il];W[qk];B[in];W[pj];B[im];W[lj])
両当たりかけられるところを放置したり抜かなくていい石を抜いたりいろいろ危なっかしいところはあるが
現状、こんな感じです。
対LV3の棋譜をとる→序盤DBを更新する→DNNを更新する→対LV３の棋譜をとる
のサイクルを繰り返すことにします。
白必勝形のダブルリーチ
この形は非常に珍しいと思う。
(;SZ[19]
;B[jj];W[kk];B[ki];W[ik];B[ii];W[hi];B[ij];W[jk]
;B[hk];W[hl];B[gj];W[hj];B[gk];W[gl];B[jl];W[gi]
;B[fi];W[jm];B[kl];W[km];B[ll];W[im];B[fm];W[lm]
;B[hh];W[mm];B[hm];W[lk];B[gh];W[hn];B[gm];W[mk]
;B[li];W[nl];B[om];W[ok];B[nj];W[nk])
どこかのタイミングで爆発的に強くなったりしないかな？
暇なので、mctsでも組んどこうかと考え始めたら、置換表の新アイデアが。
今までは、unordered_mapにとらわれていましたが、もともと探索木は文字通り
ツリー構造なので、その形のまんま置換表にして、探索しながら木を同時並行
でたどっていけば、置換表内で「探す」必要が無い上に、着手リストがそのまま
ノードとして存在しているので、反復系の探索の時に何度もmobility関数を呼ぶ
必要が無い。
結構大掛かりな修正になりましたが、とりあえず基礎的な探索まではできるように
なりました。速度計測はこれから。
あと、shared_ptr使った事で、不要な置換表データを自動削除できるので、minMaxで
AIを組んだ時に、置換表を縮小しながら再利用できるかなと。
あ、mctsはどこに行ってしまったんだろう（汗
29局目 黒(airandom.dll)の勝利回数: 15 白(ai-lv3.dll)の勝利回数: 14
32局目 黒(airandom.dll)の勝利回数: 15 白(ai-lv3.dll)の勝利回数: 17
32局目 黒(airandom.dll)の勝利回数: 20 白(ai-lv3.dll)の勝利回数: 12
34局目 黒(airandom.dll)の勝利回数: 16 白(ai-lv3.dll)の勝利回数: 18
30局目 黒(airandom.dll)の勝利回数: 12 白(ai-lv3.dll)の勝利回数: 18
32局目 黒(airandom.dll)の勝利回数: 6 白(ai-lv3.dll)の勝利回数: 26
30局目 黒(airandom.dll)の勝利回数: 12 白(ai-lv3.dll)の勝利回数: 18
33局目 黒(airandom.dll)の勝利回数: 18 白(ai-lv3.dll)の勝利回数: 15
37局目 黒(airandom.dll)の勝利回数: 17 白(ai-lv3.dll)の勝利回数: 20
32局目 黒(airandom.dll)の勝利回数: 13 白(ai-lv3.dll)の勝利回数: 19
トータル 144勝 177敗
勝率 44.9%
これはLV2 vs LV3 と比べてかなりいい数字です！
良く考えたら、ツリー構造で自分の値を残しておくという意味で、mtd(f)や
反復深化の系統には効果あるけど、同じ局面を見つける事ができないので
そもそも置換表ではありませんねorz
その代り、並列探索でも排他制御をしなくて良い事になります。
メモリー使用量も少なくて済みます。
速度については、今のところ微妙。
棋譜作成が一段落したらPCリセットしてクリーンな状態で再計測の予定。
何局くらいやれば信頼できるんだろ？あんま統計詳しくないんだよな〜
LV0とかLV1にも序盤不利になったりするorz
最終的に逆転できることもあるんだけど、そのまま押し切られることもあるorz
まずいでしょうこれはorz
ダメ筋だったかも。
途中速度アップしてる気がしていたけど、単にバグっていただけだった。
置換表機能が消えて、余計な筋を読んでいるのか。
それとも、パラパラとmake_sharedしているからなのか。
どうせやる事ないので、しばし検討。
モアパワー、モアトルクだ！
独学は厳しいorz
あとちょっとだったのに、悔しい！！
(;SZ[19]
;B[jj];W[jk];B[ki];W[ij];B[ik];W[hk];B[il];W[kj]
;B[ji];W[ih];B[hl];W[gm];B[ii];W[hi];B[gl];W[li]
;B[hh];W[ig];B[kk];W[ll];B[km];W[jl];B[jn];W[kl]
;B[lh];W[mg];B[lj];W[hj];B[gk];W[gh];B[lm];W[hf]
;B[he];W[kh];B[gi];W[hg];B[gj];W[jg];B[gg];W[lg]
;B[kf];W[fg];B[ef];W[kg];B[ng];W[gf];B[fe];W[gg])
勝つチャンスはあったと思うけどな〜惜しいな〜
(;SZ[19]
;B[jj];W[kj];B[jk];W[ki];B[kk];W[kh];B[il];W[lk]
;B[ll];W[ml];B[in];W[ji];B[im];W[ih];B[nm];W[hi]
;B[jo];W[gi];B[li];W[fh];B[ij];W[ii];B[io];W[ei]
;B[ip];W[fi])
そのほうがランダム性も出せるし
でも遅くなったらやだな。うーん
シチョウルーチンにバグがあるのか、DNNの評価値でシチョウを追いかけてしまったのかイマイチ判断がつかないな。
自分のAI vs lv 3 の棋譜を取り入れたせいで序盤DBが狂っちゃったかな。
のサイクルはちょっと手詰まり感。
棋譜取りも逆に弱くなりそうでさぼってます。
中盤、終盤はある程度読みでカバーできるけど序盤はマジ謎が多いからな。
再現性がなさすぎて、よーわからん。
頻度の低さと、再現性の無さから、置換表の二重更新だと思うんだけど…
それっぽい箇所も見当たらない。
アイディアも枯渇したし。
どこかにネタ落ちてないかな。
これは手間が半端ないｗ
なかなかいい棋譜が取れない
基本的に無理筋orz.
うって返しでました！
(;SZ[19]
;B[jj];W[ki];B[ii];W[kj];B[kk];W[ih];B[hh];W[gg]
;B[ll];W[mm];B[mk];W[jk];B[jl];W[ik];B[il];W[hk]
;B[hl];W[gl];B[gk];W[ji];B[hj];W[ij];B[jj];W[hi]
;B[jk];W[gi];B[ik];W[nk];B[lk];W[ok];B[hk])
弱くなる可能性は潰せてないのですが、何もしないよりはましだと思って。
30局目 黒(airandom.dll)の勝利回数: 16 白(ai-lv3.dll)の勝利回数: 14
21局目 黒(airandom.dll)の勝利回数: 10 白(ai-lv3.dll)の勝利回数: 11
29局目 黒(airandom.dll)の勝利回数: 12 白(ai-lv3.dll)の勝利回数: 17
22局目 黒(airandom.dll)の勝利回数: 6 白(ai-lv3.dll)の勝利回数: 16
24局目 黒(airandom.dll)の勝利回数: 14 白(ai-lv3.dll)の勝利回数: 10
27局目 黒(airandom.dll)の勝利回数: 14 白(ai-lv3.dll)の勝利回数: 13
27局目 黒(airandom.dll)の勝利回数: 14 白(ai-lv3.dll)の勝利回数: 13
30局目 黒(airandom.dll)の勝利回数: 15 白(ai-lv3.dll)の勝利回数: 15
23局目 黒(airandom.dll)の勝利回数: 10 白(ai-lv3.dll)の勝利回数: 13
28局目 黒(airandom.dll)の勝利回数: 13 白(ai-lv3.dll)の勝利回数: 15
トータル 124勝137敗 勝率 47.5%
悪くない
途中負けかけたけど相手がミスした。
終盤の数手が素晴らしい一局だった。
(;SZ[19]
;B[jj];W[ki];B[ji];W[jh];B[ih];W[ig];B[kh];W[jg]
;B[kj];W[hf];B[li];W[kg];B[lg];W[gf];B[lk];W[mj]
;B[hi];W[fg];B[eg];W[mi];B[lf];W[lj];B[fi];W[gi]
;B[gj];W[gh];B[ej];W[fk];B[fj];W[ij];B[ik];W[ge]
;B[ii];W[hj];B[hk];W[fd];B[ki];W[me];B[ij];W[ne]
;B[hj])
奮発してメモリ32GBにしといてよかった。
やっぱハードウェア性能は正義だな。
Zen2のスリッパ出たらうっかり買いそうで自分が怖いｗ
29局目 黒(airandom.dll)の勝利回数: 12 白(ai-lv3.dll)の勝利回数: 17
30局目 黒(airandom.dll)の勝利回数: 17 白(ai-lv3.dll)の勝利回数: 13
28局目 黒(airandom.dll)の勝利回数: 11 白(ai-lv3.dll)の勝利回数: 17
28局目 黒(airandom.dll)の勝利回数: 10 白(ai-lv3.dll)の勝利回数: 18
36局目 黒(airandom.dll)の勝利回数: 13 白(ai-lv3.dll)の勝利回数: 23
25局目 黒(airandom.dll)の勝利回数: 11 白(ai-lv3.dll)の勝利回数: 14
31局目 黒(airandom.dll)の勝利回数: 14 白(ai-lv3.dll)の勝利回数: 17
28局目 黒(airandom.dll)の勝利回数: 13 白(ai-lv3.dll)の勝利回数: 15
32局目 黒(airandom.dll)の勝利回数: 13 白(ai-lv3.dll)の勝利回数: 19
33局目 黒(airandom.dll)の勝利回数: 17 白(ai-lv3.dll)の勝利回数: 16
31局目 黒(airandom.dll)の勝利回数: 17 白(ai-lv3.dll)の勝利回数: 14
25局目 黒(airandom.dll)の勝利回数: 8 白(ai-lv3.dll)の勝利回数: 17
156勝200敗 勝率 43.8%
弱くなったのか誤差の範囲なのか、うーん。
DNNは序盤DB拡張と学習のサイクルを繰り返し行っているので秘伝のタレみたいになってますｗ
これで今夜からもう一度対LV3対戦やってみます。
7局目 黒(airandom.dll)の勝利回数: 4 白(ai-lv3.dll)の勝利回数: 3
7局目 黒(airandom.dll)の勝利回数: 3 白(ai-lv3.dll)の勝利回数: 4
5局目 黒(airandom.dll)の勝利回数: 4 白(ai-lv3.dll)の勝利回数: 1
7局目 黒(airandom.dll)の勝利回数: 4 白(ai-lv3.dll)の勝利回数: 3
5局目 黒(airandom.dll)の勝利回数: 3 白(ai-lv3.dll)の勝利回数: 2
4局目 黒(airandom.dll)の勝利回数: 1 白(ai-lv3.dll)の勝利回数: 3
5局目 黒(airandom.dll)の勝利回数: 3 白(ai-lv3.dll)の勝利回数: 2
9局目 黒(airandom.dll)の勝利回数: 7 白(ai-lv3.dll)の勝利回数: 2
6局目 黒(airandom.dll)の勝利回数: 4 白(ai-lv3.dll)の勝利回数: 2
6局目 黒(airandom.dll)の勝利回数: 2 白(ai-lv3.dll)の勝利回数: 4
7局目 黒(airandom.dll)の勝利回数: 4 白(ai-lv3.dll)の勝利回数: 3
42勝33敗 勝率56%
出だしは好調！
明日一日回してどうなるか… 👀
Rock54: Caution(BBR-MD5:1341adc37120578f18dba9451e6c8c3b)
文章の繰り返しが駄目なんか？
155勝 209敗 勝率 42.6%
やっぱ対局回数増やすとこの辺に落ち着くのか、うーん
211勝289敗 勝率42.2%
となりました。
やっぱこの辺が真の値なのかな。
まあ確率的にはそうなのかも。
結局1000局くらいやらないと駄目ってことかな?
143勝 220敗 勝率 39.4%
このままこの学習サイクルを進めていいか迷うorz
しかしあれは計算時間が半端ないからな。
出来れば避けたい。
うーん、コレジャナイ感がorz
LV3が強すぎる気がするｗ
もしかしてLV3には学習機能がついていて計算回せば回すほど強くなるとか？ｗ
んなわけないか。
弱くなってもいいから計算量削る方向で調整しています。
66勝 70敗 勝率48.5%
今のところむしろ勝率上がってます！
速度も若干だけど速くなったはず…
勝率50%が欲しい！
悪くない。
新型版はテストのためにいちいち学習を止めるのが面倒で、放置しています。
一晩耐久テストやらないとわからないので。
で、未だずーっと棋譜作成＆学習を続けています。
もともと８００件強の記譜をベースに間違い訂正をしたり、確定しているところ以降
の全分岐を作成したりして学習データにしていたのですが、昔作った記譜なので
序盤で結構間違いが多く、効率よく学習できないのではないかと考えました。
で、最近は序盤の定石６〜２０手からスタートして記譜を作成したりしていました。
そこそこ序盤の間違いが訂正されてきたのですが、まだところどころおかしい
ところがあって、Zebraで並べてみながら、多分間違えたであろう箇所を特定して
それ以後の記譜を作らせる事で、強制的に正しい手順に戻すなんていう、禁断の
ドーピング技を始めてしまいました。
現在は１２００記譜くらいまで増えていますが、まだまだ間違いも散見されますし、
パブリックドローの変化っぽいのに、記譜が無いものもあり、まだまだ記譜が足り
ていない感じです。
あと、ドーピング作業やりながらZebraの評価値見ていると、２０〜３０手目あたりは
進行の種類によってはZebraの評価値もあまりあてにならないなぁと言う事に気付い
てしまいました。ここら辺の精度を上げると、もっと強くできるのではないかと思います。
自動対戦してくれる序盤DB付きのオセロプログラムがあると、ドーピング作業が更に
楽になるんだけど（汗
現在残り２０手目以後の学習に使う盤面は７０万件くらいになっています。それでも
残り２０手以後の初見の盤面の評価値では結構な誤差があります。本当にBuroさん
の線形評価関数で良いのかというのも相変わらず悩ましいところです。
悪くない。
一旦対局中断します。
そうすれば対戦統計も棋譜も全然もっと取れるのに
50局目 黒(airandom.dll)の勝利回数: 48 白(ai-lv2.dll)の勝利回数: 2
勝率 96%
50局目 黒(airandom.dll)の勝利回数: 45 白(ai-lv1.dll)の勝利回数: 5
勝率 90%
一回止めるか。
ちなみにいまは強さよりも速度が欲しいかも。
黒番 対 LV3 107勝 102敗 勝率 51.2%
200戦以上して勝率50%超えはすごい！
今日一日回してみます。
165勝 174敗 勝率48.7%
でも決して悪い結果ではない！
239勝 237敗 勝率 50.2%
キター！
まあ、今だと50%行くかどうかはホント運しだいなんだろな。
分割しないと駄目か〜
素人相手なら勝てるんだろうか？
今年になってブログでまとめて発表してくれている人がいた。
ちょうど良いタイミングすぎる（汗
２種類あるのと、自分がZebraから拾った奴を合体して、３２手目まででカット。
ソートして重複削除したら４５０件程度に。多分既存の記譜と多少重複してると思う。
全部やるとかなり記譜が偏る気がするけど、やっちゃうかな。
不利なオープニングを避けるだけで勝率めちゃくちゃ上がりそうな予感がするんだが。
ようにするとか。まあ、ぶっちゃけ記譜単位でmctsやってるような事になるの。
だとするなら、DBの棋譜をテキストに吐き出すなどして、チェックしたら？
間違いっぽい分岐見つけたら、正解着手させてその後を対戦させて記譜を
強制的に正しい分岐を学習させるの。そのあとでも間違えて、なかなか治らない
事もあるけど。
これがで書いたドーピング。
２種類あって、もう一つは代表的な序盤定石から適度に着手した後で、
残り３０手を読み切ったリストで、ドローとは限らなかった。
遡りチェックの時にあり得ない奴があったので、気が付いた。
試しにZebraで並べて評価値見てみたら、中盤で結構変な手順になっていたりする。
まあ記譜の足しにはなるかなぁという感じ。
まあ、負けた棋譜だけ水増ししてDBに登録するのはあるかも？
棋譜訂正も自動化すべきかな。
うーん
終局スコアの予想はできて、間違いが見つけやすいけど、囲連星では
そうはいかないですね。
途中で変な手を打つのは、恐らく記譜が足りていないからではないかと
思います。オセロでもドーピングやらないで純粋に自己対局学習だけで
やった場合、１万〜１０万対局くらいは必要かなと思っています。
おんなじ割合で水増ししたら意味ないかもｗ
とりあえず負けたほう増やすか
定型パターンにはまりやすいLV2にはかなり効果あるのですが
変幻自在なLV3には今一つみたいです。
うーん。
棋力が下がっても計算量を抑えて、速度を稼ぐ方向で行くべきか？
これはちょっと採用するか迷う。
なんか評価値の計算まちがえたか？
とりあえず、白番持った時に相手が初手天元付近に打たなかったときは、中央寄りの斜めに打つように変えた。
これで少しでも緩和されるといいな。
確率の理論を根底から壊してしまうみたいなので。
やっぱ遅いようでもじっくり行くのが確実っぽい。
新しい棋譜が古い棋譜の１〜2%程度になるくらいに水増ししてます。
バグを見つけてしまった。
今ある記譜５０万件の数％くらいに間違いがありそう。
直管的には、全データに対して読み切り処理を噛まさないと間違いの有無すら確認できない。
多分、逆順探索処理を簡素化した時にバグが入り込んだのだと思う。
暇なのでログ書き出しの処理を作ってたら見つかった。
うぐぐ。
もうしばらく様子を確認して、他にもバグが無いか見た上で…どうしよう。
一旦記譜をリセットして作り直すべか。
ログの側のバグだった事に…
お騒がせ様でした。
8対称すべてはメモリに収まらないので半分づつ学習させます。
8対称、勝率あんまり上がらないですね。
うーん、うち筋は悪くないと思うんだけど。
なにかブレークスルーが欲しいですね。
うーん。
2手読みに戻したらかえって勝率さがりましたね。
誤差の範囲かもわかんないですが。
必勝形のダブルリーチ
これほど少ない石数でこの形を作れるとは…
(;SZ[19]
;B[jj];W[kj];B[jk];W[li];B[ji];W[lh];B[kl];W[jm]
;B[ih];W[lk];B[ig];W[jf];B[il];W[ik];B[hk];W[if]
;B[im];W[ij];B[hj];W[lg];B[ii];W[in];B[ik];W[jn]
;B[ij])
それだと手が固定されてしまうかなと思って勝率のいい手かつあまり選ばれてない手を優先的に選ぶようにしたら
147勝 220敗 勝率40.1%
これは誤差とは言えないほどの差ですねぇ。
棋譜取り＆序盤DBへの取り込みを継続したら少し勝率戻りました。
50%付近まで頑張ろう。
こういう風に毎回打てるといいんだけど
(;SZ[19]
;B[jj];W[ij];B[ki];W[ii];B[ik];W[ih];B[jh];W[ji]
;B[kj];W[jg];B[kh];W[if];B[hj];W[ig];B[lk];W[jk]
;B[jl];W[hk];B[kk];W[km];B[hl];W[gk];B[gm];W[fn]
;B[kg];W[kf];B[lf];W[mg];B[lg];W[gi];B[le];W[lh]
;B[mh];W[mi];B[li];W[ie];B[id];W[md];B[lh];W[nd]
;B[lj])
棋譜取り、序盤DB更新、DNN更新だけでは50%の壁は突破できないかもな。
ん、勝率かなり落ちた。
何が起きた？
ひたすら記譜作成中に、やっぱり暇なので、記譜管理周りをリニューアルしていたら、
結局記譜ファイルの形式を大きくいじってしまい、かなり全面的なリニューアルに。
そしたら、あちこちバグが出て、結局記譜作成より新作デバッグ優先に（汗
序盤DBは、記譜溜めていくと途中で弱くなるけど、いずれ直ってくるものだと思う。
正しい手順があるとして、１回間違えると、間違えた側が負ける記譜ができる。
負ける事で、その手は選ばれない事が記譜に登録される。
しかし、探索の精度が低い状態で記譜作ると、２回間違える記譜ができて、本来
負けのルートで勝ってしまう。これが記譜に登録されると、この２回目の間違いが
訂正されるまでは勝率が下がる。
どのくらいで直るのかは、直接なのか評価関数経由の間接なのかなど、フィード
バックのかかり方で変わってくる。直接的なら割とすぐに直るはず。
自分のは間接なのでかなり時間がかかりそうで面倒なので、Zebraで２つ目の間違い
箇所を特定して、そこまで着手した後探索をする棋譜を作って、かなり強制的に直し
ちゃった。
序盤は大体良いのだけど、確定値で学習している箇所と、序盤DBで学習している
箇所の境目で、確定値が足りないまま過学習になっている評価値ステージがあって
そこらあたりで大抵間違える（汗
ま、やらないけどね
色々と入れ替えながらバグ発生箇所を特定に成功しました。
が、なぜそこでバグっているのかわかりませんorz
まともに動いたから良しとするしかない感じ。
あと２か所改良したいところがあります。
あと２日では無理だなぁ。
原因は複数ありそうですorz
やっぱり当初の置換表に変なデータが登録されているのが正解だった。
残した課題のうち１つもできた。
さて、何をしよう。
あと中盤終盤でDNNの値の比重を大きくしました。
なんとか勝率50%弱まで戻せました。
262勝 248敗 勝率51.4%
誤差の範囲かもしれないけど嬉しいっ
悩ましいい。
149勝 202敗 勝率 42.5%
そんなに微妙なものではないと思ってたが？？
実は微妙なものだったのか、誤差の範囲なのか？
±5%くらいは誤差ででるのかもしれないなぁ
179勝 149敗 勝率54.6%
この数字をどう解釈すればいいのか…
222勝 194敗 勝率53.4%
そろそろ棋譜反映させるか。
さてどうかな？
対LV2 白番はもうちょっと勝ちたいかな
対LV1
黒番 61勝 9敗 勝率87.1%
白番 49勝 4敗 勝率92.5%
対LV2
黒番 57勝 0敗 勝率100.0%
白番 10勝 28敗 勝率26.3%
対LV3
黒番 25勝 16敗 勝率61.0%
白番 13勝 28敗 勝率31.7%
一回止めるか。
対LV1
黒番 90勝 10敗 勝率90.0%
白番 64勝 6 敗 勝率91.4%
対LV2
黒番 78勝 0敗 勝率100.0%
白番 14勝 33敗 勝率29.8%
対LV3
黒番 39勝 23敗 勝率62.9%
白番 19勝 40敗 勝率32.2%
249勝 204敗 勝率55.0%
なんだろう？
対戦してみたけど思ったほど負けてないな？
モンテカルロで役に立つし。
データは同じ。
10倍速くらい早くなると思ってたのに3倍速くらいだ。
ちょっと簡素化しすぎかも？
探索部は全く改善していませんが、その他の部分が大幅にスピードアップ。
自動記譜作成時のオーバーヘッド（探索以外の時間）がかなり減った。
あとは学習の時間を減らしたい。
さて、使い物になるかな？
モンテカルロに使おうと思ったらプレイアウト回数かなり減らさなきゃだめだな。
だが激遅。
だかが300プレイアウトでここまで遅いとは…
ブレークスルー来たか？？
奥が深い。
ジリジリ損失減ってる。
まだ対戦回数少なすぎて結論出すのは早いけど、もっと50連勝くらいするかと思った。
対LV1
黒番 17勝 3敗 勝率85.0%
白番 13勝 3敗 勝率81.3%
対LV1
黒番 156勝 15敗 勝率91.2%
白番 109勝 8敗 勝率93.2%
次は本丸、LV3と決戦や！
47勝 34敗 勝率58.0%
ふーむ、まあ悪くないけど、正直もっと期待していたｗ
400〜500戦くらいはしないとまだ結論は早いけど。
120勝 80敗 勝率60.0%
ふーむ、まあ悪くないけど。
最終的には対LV3黒番勝率 70% を目指したい。
どんな負け方してるのかちゃんと把握せねば。
せっかくいいの買ったんだから。
アルファゼロアルゴリズムが心のどこかで捨てきれない。
ルール実装が結構効率的な奴思い付いて、1000万プレイアウト/s位出ました。
並行でやるっつっても計算資源が問題だなぁ。
囲連星はアイディアないしちょっとお休みかなぁ。
内容的にも文句ない勝ち方だ！
(;SZ[19]
;B[jj];W[ji];B[ii];W[ih];B[ki];W[jh];B[kk];W[kh]
;B[lj];W[ij];B[hi];W[hk];B[hh];W[lg];B[gl];W[mg]
;B[gg];W[ff];B[gk];W[gj];B[ll];W[mm];B[fj];W[fi]
;B[gi];W[hj];B[hl];W[jk];B[ik];W[hj];B[gj];W[gf]
;B[gm];W[gh];B[fn];W[fh];B[lh])
本当は白黒総合勝率でLV3に勝ってからが理想なんだけど。
あとDBのファイルサイズでかいんだよなぁ。
ちなみに対LV2黒番必勝ではなくなってしまっているようです。
あと思考時間かなり長いです。
ttp://https://drive.google.com/file/d/1M86qczNQQScvkH-ZMyZVAlDvJ-K0OlVc/view?usp=sharing まあもともと過疎スレだからしかたないか。
ダウンロードしたけど、記譜作成中なので、CPU食いたくなくて（汗
ttp://https://medium.com/applied-data-science/how-to-build-your-own-alphazero-ai-using-python-and-keras-7f664945c188 マネージドコードとアンマネージドコードがどうたらとか、、、
でも12章のactor critics法というのが面白そうで頑張って読みたい
ショック
目が滑る
頭に入ってこない
そして意外と強い。
終局は実装されてないのかな？
棋譜作成がいまいち上手く行っていないので。
金さえあればニートになるのにｗｗ
まあさすがに土日は休めるだろうけど。
一日無駄になったorz
これや将棋は微妙な線で、人間に勝ち目あるかもしれん。
囲碁より勝ち方、有利のさせ方が分かりやすい差。
人工知能なしの人間技で、人工知能に勝てる方法あるんじゃないかと。
ttp://https://ima.goo.ne.jp/column/article/5290.html ビビットカラーを使ったポップなデザインの二人用ボードゲーム「ガブル」
ttp://http://boardgame-kikou.blog.jp/archives/9311305.html LOGY GAMES ボードゲームカタログ
ttp://http://www.logygames.com/index.html#catalogue オシャレで簡単、だけど深いボードゲーム
ttp://http://sweetint.com/ic/tinttile-game コンポーネントに酔いしれて、戦略にゆったり溺れる「箱庭の国」
ttp://http://sake.saloon.jp/dojin_miniaturized-world/ 『すずめ雀』初心者でも本格的な駆け引きを楽しめるミニマル麻雀ゲームが登場
ttp://https://www.inside-games.jp/article/2018/05/02/114450.html エクストリーム将棋の企画から販売まで
ttp://https://nakagawa-hands.com/digital-fabrication/ex-shogi_a2z/ しつこく食らいついてたらすこしずつ目が滑らなくなってきてる。
何とかものにしたい。
気が付かなかったぜ！
これで勝つる！
マルチスレッドにも対応してるっぽいし。
これはかなり期待できる。
tensorflow-gpuうまく入ってないみたいだ。
16C32Tじゃ足りない。
64C128Tが欲しいｗｗ
なぜ？
こんなことってあるのか？
web_demo.pyあたりで行けそうな気もするが…
やはり zen2 スレッドリッパー買うしか…
ネットワークが小さすぎるんだろうか？
うーん。アルファゼロに幻想持ちすぎかも知れんな。
とりあえず、GPUを使えるように頑張るのが先かなぁ？
仕事で使うPCなので慌ててPro6の発注をかけました。
一応コア数２倍の４コア８スレッド、メモリーも１６Gになる予定。
そろそろスピードの限界を感じていたので、痛しかゆしなところ。
ようやくIntelの呪縛から解放されるAVX2対応のCPUがAMDから出るというのに、
専用新型PCが遠のきました。
どのくらいスピードアップするかなぁ…。
乙です
せっかく週末なのになぁ。
現在液晶の表面パネルバキバキで、タブレット機能止めて、
セロテープで補強してだましだまし使ってますが、発熱によって
内部が歪んじゃっているみたいで、通常状態でも液晶が湾曲してます。
で、将棋の探索の深さが意味不明だったので、色々考えていましたが、
なんとなく想像がついてきました。多腕バンディット使って、反復深化と
絞り込みを行っているのではないかと思います。
現状中盤探索の速度がいまいち遅く、シングルプローブカットすると
何故かさらに遅くなるという状態。棋譜作成メインだったので、あまり
気にしていなかったのですが、新しいPC来たらちょっとトライしてみよう
かなと思っています。
前回思いついた中盤探索ロジック。具体的に実装を考え始めたら、
MCTSでいいじゃんということに（汗
これからVisual Studioのダウンロードです。
VS2017→VS2019でエラーチェックが厳格化したものがあったようで、ソース修正。
Win8→Win10でコマンドプロンプトがなんか変わって、CTRL-Sの動作がよくわからない。
などなど、細かい点はいくつかありますが、速度的には思いのほか効果が出ていて、
ほぼ倍速くらいな感じです。並列のオーバーヘッド増加分を、クロック他CPU単体の
パフォーマンスアップで吸収していると思われます。
俺も頑張らねば。。。
SSD丸ごと1個あけて別ドライブにインストールすればwin10とも干渉しないはず…
でも環境構築する根性が湧いてこない。
あしたにするか。。。
今日だけで4回フリーズしたorz
うーん。惜しいなぁ。
バージョンが違うからかなぁ
絶望した！
なんで俺が試したプログラムとそんなに違うんだ？
反省（反省するとは言っていない）
しばらく休憩するか…
ttp://https://github.com/xuetf/AlphaZero_Gobang 気分を変えてこれに手を出そうかと思ってます。
評価値で黒番＋２、白番−１くらいの差が生じているので、
評価関数にバイアス項を導入しました。
他、若干の高速化ネタ。
中盤探索でProbcutすると遅くなる問題を回避。本格修正するか悩み中。
というか、そもそもZebraより圧倒的に遅い原因がわからん。
python 超つらい…
きょうびOSごと落ちるってどういうことだよ？
一つは、普通に無駄な処理を見つけて修正。
もう一つは、評価値の計算に差分計算を取り入れました。
今まで並列処理で差分ってどうやるんだろうと思っていましたが、
単にDepth=1のところ（次がLeaf）で、順次評価値計算するのを
差分すればよかったのね。
この２つで、中盤探索で２手ほど深く読めるようになりました。
何が悪いんだろう？
思い切って、不要そうに思える棋譜をバッサリ削除してみました。
削除しすぎたかも。
いろいろ細かく修正と、デバッグ用表示の改良。
とかやっていたら、丸１日近く動かしたところで、なぜか急激にパフォーマンス低下。
もともと空きが少なかったSDDが一杯になっている…。とはいえ30Gはあったはず。
再起動していたらもとに戻った。原因不明。
対症療法で不要プログラムアンインストールしていたら、使っているOfficeを間違えて
アンインストールしてしまった。
HDD一杯が原因なのか、評価値のファイルが壊れていた。
ギリギリ間に合ってバックアップから復旧できた…と思う。
セキュリティー対策ソフトの監視対象管理DBのファイルが合計で400G越え（汗
ところが、管理者権限ないと停止できず、ファイル掴んでいるため削除できない。
今日は管理者休暇中。
logファイルを頻繁に追記しすぎて、ファイルサイズ変化する都度DBファイルが
作られているのではないかと想像。棋譜バッサリ削除して、一気に遡り探索やり直し
していて、これまでと比較にならないペースと数で追記処理が起きているので、
その影響の可能性が。
Officeは再インストールしてもらったけど、何故かセキュリティ解除キーの入力ができない。
来週月曜日は出張なので、来週火曜日までだましだまし行きます。
古い方のPCがまだ生きているので、Excel作業はそちらでやる事にしました。
残念
分岐のチェックで、以前は全ての分岐を棋譜化していたけど、今度のは軽い探索で
怪しい評価値（同一評価値〜−４程度まで）のものだけ棋譜化するようにして、
棋譜数を大幅節約。学習が楽になるという算段です。
棋譜づくりが順調になり暇ができると、細かく気になっていた、どーでもよいところを
改良し始めて、バグとりで棋譜づくりが滞るという悪循環orz
よくよく考えたら、PCのパワーアップしたので、またDCNNトライとかしてみようかな
とか思い始めた。tiny-dnnしか選択肢無いんだけど。
最近さぼりっぱなしだったけど、ちょっと見てみるか。
まだちゃんと見てないけど
もう無いだろうと思いつつ、ちょこっとした事に気づいて修正を繰り返してます。
置換表のハッシュ関数を改良。
格納効率が結構良くなったので、衝突が減ったはず。
終盤探索の時にBOOK（確定）も参照して余計な探索を減らしました。
基本遡りで確定させているので、運が良い時に滅茶苦茶早くなりました。
無い時は今まで通り（汗
学習データが不足しているのではないかと、置換表内に残っているスコアが確定
した局面FIFOで貯めて、折々に学習に回してみました。１回探索で１００〜５００件
程度。これをFIFOで５００万件。棋譜に残っていない局面で学習する事で、過学習
が防止できるかなと思っていますが…。
現在、２７手確定局面で大体１４０００件の棋譜とその分岐で合計２３万件ほどですが、
まだ棋譜が足りていない感じです。が、件数が増えすぎて手に負えません。
BOOKの確認ができるWindowsアプリ作ろうかと思い始めています。
やっぱアルファゼロは手を出してはいけないかったんや。
計算プロセス自体は、NNを極端に単純化したものが線形回帰だと思えば、
NNで生まれた計算ノウハウが流用できますよ。
というか、今の時代、ただのLRでDCNNとほぼ同じ強さ、とかの方がオシャレ
ではないかと思う、ひねくれものの僕。
githubにもっと易しそうなのでてくるまで待つか？うーん。
そろそろ計算回しっぱなしにしてもいいかな。
つっても回せるプログラムがないけど。
ttp://https://github.com/yangrc1234/Gomoku-Zero もしかしたら微妙に強くなってるのかもしれないけどあまりに成長速度が遅すぎる
やっぱアルファゼロは計算時間が半端ないのかも？
うーむ
満足できる教師データがそろってから評価関数に使ってみる程度にしないと…。
自由度が高すぎるので、まともな評価関数に収束するまでに、相当な試行回数が
必要なんじゃないかと思う。
自分は棋譜作成をずーっとやっていますが、現在は棋譜作りの目的がBook充実
になりつつあります。なんというか、現在の形はいつの間にかQ学習＋ε-Greedy
っぽくなってきています。
アルファ様のお陰で、目標を見失いましたので、手段のためなら目的を選ばない感じ
で、プログラム作る楽しみという方向になっています(^^;
ヒューリスティックなしのモンテカルロで1手10000プレイアウトで1局に約1分かかります。
それを16並列で1分当たり約16局採取できる予定。
棋譜の質があまりよくないのが難点ですがとりあえず、これでやってみます。
全コア動かすとシングルよりやっぱ少し遅くなるみたいですね。
