[過去ﾛｸﾞ] 【オセロ,将棋】ボードゲーム【囲碁,War】 (1002ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
906: 310 2017/07/16(日)00:06 ID:z0mkcRg4(1) AAS
なんかもともと関数呼び出しの方が速いという事で数字で実証するサイトがありました。
まあ、コンパイルの最適化のかかり具合なのかなぁ。わからないです。
コンパイラのバージョンで違うのかも。
バグの原因はわかりました。関数呼び出しにするときに、同時にパスの扱いを変えた
のが原因だと思います。が、確かめる際にもとに戻したら、普通の関数の方が速かった
という結果に。バグってるときの実行時間なので、あてになりませんが。
というわけで、全部もとに戻して、少しだけ確認しましたが、あまり差はない模様orz
記譜の中に間違った読み切り手順が混じってしまったので、全部再計算。
こちらもパスの扱いを変えたのが原因で、別のバグが出ました（汗
二次災害大です。
再計算は２４００記譜で１時間半くらいで、着手は最善手の中でのランダムなので、
１回実行してアペンドすると倍、２回で３倍というように、記譜の増殖が可能と思い
当たりました。これを使えば学習データを簡単に増やすことができます。
907: 310 2017/07/17(月)22:52 ID:GI+vwgP1(1) AAS
評価関数まわりを作ってデバッグ。
その中で致命的がバグが発覚しました。
学習用に溜めた記譜データにおかしなデータがいくつかあるというもの。
学習やり直しです。
記譜データ消した後で気が付きましたが、復旧できないわけではなかった。
後の祭りですorz
912: 310 2017/07/22(土)02:06 ID:6HI7Rmqm(1/2) AAS
結局４０手までランダム＋残り２０手完全読みな記譜集めて、残り２０手の評価関数と
Policyを作ってます。ランダム１０００件に対して３０件のMCTS自己対戦混ぜたもので
学習してます。ランダムだけで十分学習になるようで、悩むより数を集める方が大事な
感じです。４０手以後の評価関数ですが、３０手過ぎくらいから、そこそこ使えるみたい
です。
で、これを使ってPUCTな形にしてます。
完全読みが使えないので、２０〜４０手あたりで最善手（に近い手順）をどうやって
作ろうかという感じです。
まずは、後ろから探索で、何手までまともな手だったか遡るプログラムを作って、
残り２５手くらいまで遡れたら良いかなぁと。
つか、強化学習に行っちゃおうかなぁ。
913: 310 2017/07/22(土)20:32 ID:6HI7Rmqm(2/2) AAS
逆順チェックのプログラムして、学習時に、正解手順で遡れる盤面も含むようにして
みました。仕組みとしては、最終盤面からヌルウィンドウサーチして、もっと良い評価に
なる手が無いことをチェックして、OKなら１手遡ります。置換表にてPVの評価は即求まる
のと、ヌルウィンドウサーチを使っているので、２５手までなら楽勝です。
MCTSで対戦したデータには２７手より前まで遡れるものもあるようですが、丸１日
チェックしても終わりそうにないので、２５手で打ち切り処理を入れました。
記譜に正解手順で遡れる手数を持たせて、学習時には、その手番以後の盤面を使用
する事で、３０手過ぎの評価の精度を上げられたら良いなぁと思います。
916: 310 2017/07/23(日)23:50 ID:DIga1NIH(1) AAS
遡りチェックしていたのですが、普通のUCT時代の方が精度が高い。
そこで気合入れてPUCTのチェックをしてみたら、案の定符号がひっくり返って
いる箇所があったり、パスの処理が抜けてたり。
たぶん、これで大丈夫だと思います…。
これでしばらくは、高速化しながら、記譜集めですね。
918: 310 2017/07/29(土)22:16 ID:YHqII1DK(1) AAS
遡りチェックの高速化で迷走中。
２８手までなら問題なさそうなので、現在チェック中。
２８手まで３５分で遡れる記譜で２９手目が１日経っても最善手か否かがわからない。
あまりに極端な差なので、何か条件があるのか、たまたまそういう記譜なのかを調べる
ために、いったん２８手まで遡れる記譜を探すという段取りです。
その間、PPLのキャンセル処理について、厳密に考えていたら、今のやり方ではベータ
カットでのキャンセルが効いていないのではないかという疑念が。ループの中で再帰し
ているので、そこにcancellation_token_sourceオブジェクトを渡してやって、ポーリングを
して、下ノードでもキャンセル処理をしないといけないが、していなかったので結局中断
せずに、普通に終了待ちしてしまっているという事。
で、キャンセル処理を直したのだけど、時間変わらず。メッセージ出すようにしてデバッグ
したところ、ベータカットが１件も起きていないという謎な事態が確認されました。出てくる
答えは合っているので、しばらく考えることになります。
920: 310 2017/08/06(日)10:08 ID:zi8YR8lq(1/2) AAS
キャンセル処理については確認完了。たぶん大丈夫。
ただ、キャンセルが多発するはずの、最善手じゃなかったときに、通常より時間がかかる
傾向に見えるのが気になる。mctsが間違えるくらい枝分かれが多いからかもしれないけど。
遡りチェックはやはり遡り２９手目から日単位で時間がかかるものが出てくる。
２８手まで遡ると、最大数時間くらいな感じなので全部チェックするなら２８手が限界かも。
当分の間、記譜集めという事になりそうですが、１日動かして数十記譜では終わる目途が立たない。
精度落とせばスピードアップできるけど。
あと、mctsで末端ノード１００万単位まで探索して引き分けの時に、完全読みかけるとそう
じゃないときが結構ある。どこかで枝の探索漏れが生じてるっぽい。Policyの方はかなり
小さくても探索はかかってるようなので、Valueの方じゃないかと思う。
921: 310 2017/08/06(日)21:21 ID:zi8YR8lq(2/2) AAS
最善手じゃなかったときの時間問題、原因判明。オーダリングでした。
オーダリングでは置換表にあるものを優先していたのですが、遡りチェックの時には
ベータカットを起こすには置換表に無い方から探索しなければいけないわけで。
遡りOKの時は、どういう順番から探索しても、全て探索するしαは更新されないので
かかる時間がほぼ一緒ですから、順番変えてOKです。
でも、これ通常探索時には逆になります。条件的には、ヌルウィンドウサーチの時と
そうじゃないときで区別できそうですが、ちょっと考えてみます。
探索の方の問題は、やはりValueの評価値とRolloutの勝率がともに悪いと、本当は勝ち
手順でも簡単にはチェックがかからなくなってしまうという問題かなと思います。この辺は
精度アップで対応するしかなさそうです。
922: 310 2017/08/07(月)20:08 ID:3J92NhXM(1/2) AAS
オーダリングを詰めて、さらにヌルサーチ専用の処理を追加。
ベータカットが早めに起きるようにしたのもありますが、それ以外の部分でも
倍速近くなっていると思います。が、まあ、それでも２８手目以前まで遡りチェック
するのに時間がかかるという点では焼け石に水。
記譜集めからの逃避はこの辺にして、記譜集めに戻らないと…。
ここまで来ると準確定石によるアルファカットも再度実装してみたい。
準確定石を求める処理も、ソースごと消失しています。
以前は盤面与えると都度再計算していましたが、石を置くごとに更新していく
ような方法にできないか考えています。とはいえ、なかなか良い方法が思い
浮かばないので、あくまで記譜集めしながら考えてみる程度ですが。
924: 310 2017/08/07(月)22:15 ID:3J92NhXM(2/2) AAS
がんがれー。
自分も実をいうとかなり行き詰ってるけど、やれることを少しづつやってる感じ。
まあ、一回ソース全滅したの書き直すイベントのおかげで、リセットできたってのもあるけど。
926: 310 2017/08/11(金)17:12 ID:3ANYT76m(1) AAS
自分の場合、何倍になるんだろ。単純に考えて１０倍くらいになるのかなｗ
まあ、アムダールの法則あるから、そこまではいかないだろうけど。
メモリーも、8Gだと遡り３０手あたりでスワップ始まるので、もう少しほしいなぁ。
最近、PC通販サイトを時々覗いています。
スレッドリッパーほしいですねぇ。
相変わらず遡りチェックの高速化を地味に実行中。
min-Max探索の並列処理は粒度が大きいので、待ち合わせロスが多くなりますが、
その辺を何とかしました。遡りチェックはヌルサーチにおけるベータカット検出がメイン
であるという点に依存しますので、普通の探索では使えませんが。
平行して確定石の計算作ってますが、なかなかうまくSIMD演算に落とし込めない。
しばし悩み中です。ただ、３０手遡りとかまで行くと、確定石を使ったアルファカットが
かなり効きそうなので、早くなんとかしたいです。
928: 310 2017/08/13(日)23:11 ID:icrdxDk8(1) AAS
確定石とりあえずできました。
自分の実装で３ステップあるうちの２ステップでSIMD化できましたが、
最後の１つはまだシフトとループの組み合わせです。
で、さっそく敵確定石数からアルファ値アンダー検出のカットロジックを
入れてみましたが、遡りチェックに入れると、途中でバグるという状態。
しばし長考が必要です。
というわけで、記譜集めに戻りましたが、こちらもランダム着手付
の探索で、稀に間違った着手をするというバグが出てます。こちら
も、しばし長考が必要かもしれません。
むむむ。
929: 310 2017/08/14(月)23:05 ID:4KkLvd6h(1) AAS
記譜側のバグ取りしてました。
というか、ランダム着手部分を全面的に作り替えました。かなり簡単になりました。
が、テスト中に突然のあり得ないレベルの速度低下。
原因は、ふと並列探索にできる箇所を追加した事にありましたorz
丸一日大損です。
ついでに速度を調べていたら、ただの探索より置換表の方が遅いという恐るべき事態。
オーダリングもおかしくなっていましたので、ここも修正。
それでも、まだybwc探索と置換表探索の速度が変わらないという問題あり。
あちこちいじりすぎてわけわからなくなってます。むむむ。
931: 310 2017/08/19(土)00:06 ID:+u+2ZNgB(1) AAS
なんか優勝したみたいだね。
強いAI同士で戦うと、ぎりぎりの攻防の結果、人間には穴があるように見えて
しまうのかも知れん、と、ふと思ったりして。
933: 310 2017/08/21(月)01:03 ID:fSNFfFNF(1) AAS
せっかくまともに動いていた記譜集めですが、つい直したくなって直していたら
バグ出る、速度落ちるで、さんざんでした。ようやく落ち着いたかな。
キャンセルメッセージ、再帰処理だと結構混乱してしまう。
最上階層でのβカットの際、キャンセル待ちでかかっていた時間を、ほぼゼロに
短縮しました。たぶん、タイムアップのキャンセル待ちも。ただし、まだ未検証。
とはいえ、まだ記譜数が足りないのか、評価値が安定しない…
935: 310 2017/08/25(金)00:10 ID:9p5u+Oh3(1) AAS
スレッドリッパーいきなり値下げですね。秋冬ごろ狙おうかなぁ。
記譜集め開始したら、耐久テスト状態になってバグがちらほら。
ここ１週間くらいで直したところに原因がありました。またか。
困った事に、たまたまエラートラップに引っかからない事があるため、記譜が
全て正しいという保証が微妙な事。仕方ないので、記譜のチェックをしなきゃ
ならん…。
また、やけにおかしいと思っていた評価関数でも、問題が発覚でした。
937: 310 2017/08/31(木)22:05 ID:lyHOCTEv(1) AAS
スレッドリッパー単体で１２万円くらいですからね。
CPUクーラーと電源頑張らないといけないから、それなりの価格にはなっちゃいますね。
畳みこみは３×３を基本にしても、アルファ碁で１９２フィルターの１２段構成とかです。
自分は今のパソコンでオセロの８×８に対して３×３の４８フィルタの２段構成で試して
みましたが、学習終わる気配がないので、ペンディング中です。
普通にMNISTの手書き数字認識は、しょせんオートエンコーダの３段とかなので、大した
時間もかからずにできちゃうんですけどねぇ。例題と実践のギャップがでかすぎ。
ただ、畳み込み演算自体は昔からあるもので、たぶんFFTとかでも同じような計算して
いるはずなので、しっかり勉強すれば、何か、計算速度アップの技がありそうな気は
しています。
デバッグ考えると、ハードで頑張った方が精神的に楽ですが。
938: 310 2017/09/03(日)08:52 ID:sEBlGL7A(1) AAS
相変わらず記譜集め中。
オセロの読み切り処理の並列化は、粒度がでかくて、待ち合わせロスが大きいので、
CPUがアイドルしている時間が長く気になります。そこで、スレッド数をチェックしてコア
数を下回っている時は、リーフに近いところでも並列探索に戻るようにしてみました。
PPL機能ではスレッド数は取得不可能で、結局自分で増減カウントしました。
リソースモニター上ではCPU使用率が１００％近くに貼りついているいるので、待ち合わ
せロスはほぼゼロになりましたが、早くなったかどうかは未確認です（汗
941: 310 2017/09/06(水)00:21 ID:lfEM6HyT(1) AAS
乙です。
こちとら、またまた終盤探索にバグが見つかりまして。
２日ほど根つめてデバッグ。その間記譜収集停止orz
いつも出てくれればよいのに、同じ記譜でも３０回に１回とかのレベルで発現する
奴で往生しました。最終的にnull window search専用処理の置換表のどこかが
おかしいだろうというところまで追い詰めましたが、諦めました。時々異常に探索
時間がかかるのも、この処理が原因っぽかったので、やけになって削除。
すっきりしたかもｗ
なかなか強化学習までたどり着けない…
944(1): 310 2017/09/08(金)00:27 ID:4/v5wLbf(1/2) AAS
強化学習の準備始めました。
評価関数のファイル名決め打ちしてたり、staticだったりで、あちこち変えなきゃならん。
と、裏で記譜集めをしていたら、またまた問題が。
探索結果は合っているけど、逆順探索などで失敗。
用途の違う置換表を使いまわしちゃいかんという事の模様で、置換表クリアで対応。
mtd(f)で下から寄ったあと、置換表残したままもう一度上から寄せると、探索間違える
現象も確認。良く考えれば何が問題なのかわかりそうだけど、もう飽きた（汗
何回目の「これできっと大丈夫」なのかorz
>>943
局面数的には、全宇宙の原子数でも足りないかと…
特徴抽出と近似による汎化に頼らないと・・・
946(1): 310 2017/09/08(金)23:49 ID:4/v5wLbf(2/2) AAS
昨夜いろいろ考えながら寝ていたら、あっとなりまして。
今までmin-maxな部分ばかりデバッグしてましたが、最初にバグに気付いた時に
並列探索かつ置換表な時に問題が起きると気づいていたのに、見るところ間違え
てました。置換表の更新のところで、２重更新の対策してなかった（汗
null window searchとか、冤罪だったんじゃないかと。
まあ、徐々に耐久テストしてみます。
947: 310 2017/09/11(月)00:57 ID:ieDiiY3U(1) AAS
>>946は潜在的には問題になりえますが、関係なかったorz
都度都度置換表をクリアしながらなら問題が起きないようです。
でも、クリアしなければならない、そもそも今のトリッキーな高速化方法では
かえって低速になる事から、着手リスト作成箇所を全面的に書き直して
しまいました。
現在耐久テスト中。今のところ調子は良さそうです。
記譜集めちんたらやりすぎなので、ちょっと質を落として数を増やしてみます。
948: 310 2017/09/16(土)22:09 ID:4ZN/DTXg(1) AAS
このまま記譜集めしていても、必要分量まで集めるのにどんだけかかるかわからない
ので、悩んでいましたが、ふと思いつきました。置換表には、読み切り済の記譜が詰まっ
ていると。上限加減のタイプもあるので、全部ではありませんが、これを捨てるのは勿体
ないかなと。で、抜いてみました。２５手読み事に大体３０００局面の盤面と終局スコアが
得られます。
どういう局面が残るのかは、なんとも言い難いのですが、記譜の足しにはなるというか
結構な分量がたまるなぁという事で、これもとっておいて、再利用できるようにしてみま
した。置換表適用深さ分しかないので、限られてはしまいますが、分量的には結構に
なるので、利用を前提にしてみます。
951: 310 2017/09/21(木)20:15 ID:x7IR5Khh(1) AAS
tensorflowですか！
環境整備大変そうだと逃げてます。乙です。
速度感とか教えてください。
こちらは、ようやく強化学習の良い方法を考え付きまして。
とりあえずダミーとの対戦と学習部分までコーディングしてみたところ。
今夜デバッグして、強化部分のコーディングする予定。
rollout部で使用するのはあきらめました。
色々やっていたら、勝率も大事だけど、それよりツリー展開のドライバー
としての速度の方が大事だと言う結論に（汗
956: 310 2017/09/24(日)01:20 ID:1rFk/uJ5(1/3) AAS
並列処理すると、何使っても計算機資源占有されちゃいますよｗ
だからGPUに逃がしてCPUを空けようとしたりするんですよね。
最近扇風機で冷やすようにしてますが、扇風機無しだとクロック数が８０％以下まで
下がってしまって、そういう時に限って、読み切り処理でバグがあるような結果が出て
います。理屈ではありえないんだけど。
スレッドリッパーでもi-7900Xでも、CPUの温度対策は大事になると思います。
957: 310 2017/09/24(日)01:47 ID:1rFk/uJ5(2/3) AAS
強化学習は、適当にコーディングして結果からデバッグしているので時々不安になり
ますが、それなりに学習してくれているみたい。学習内容は同じく勝率で、これをアル
ファ碁で言うところのポリシーに使用してます。
強化学習のポリシーを導入した事で、遡りチェックも調子よく遡るようになり、最善手を
指している率が上がったように感じています。しょせん強化学習だし、まだ学習しはじめ
なので、精度は高くありませんが、使い方次第ではいける感じです。
強化学習続けたら、定石DBの代わりになるんじゃないかと期待。
しばらく学習フェーズになりますが、次はロールポリシーを改良したいかな。
961: 310 2017/09/24(日)23:40 ID:1rFk/uJ5(3/3) AAS
ウェイトデータをバイナリで持ってきて、フォワード計算を自分で書くってのじゃダメ？
パッケージに任せたい面倒くさいところって、バックワード部分だから。
自分の場合、mctsで並列処理していて、使用している行列パッケージのEigenも並列
計算していて、両方で並列化しちゃうとスレッド取り合って劇遅になっちゃうし、Eigenを
シングルスレッドで動かす時のオーバーヘッドが気になったので、AIで使用する時の
フォワード計算は自分で書きました。
963: 310 2017/09/26(火)00:08 ID:TqyA8LQm(1) AAS
強化学習、ずっと学習続けていると、途中で弱くなっていく。
アルファ碁のやり方をまねていたけど、一旦超シンプルな方法に変えてみて、
とにかく施行回数を増やしてみます。
強化学習を使って、序盤の評価関数が作れないか検討開始。
あと、時々出ていた終盤探索のバグ。
今度はたぶん大丈夫だと思う。
何度目の大丈夫だって状態だけど（汗
965: 310 2017/09/27(水)10:06 ID:CCZHsP7K(1) AAS
学習率は大事だけど、今時はRMSPropとかADAMとかで
自動計算にしちゃうんじゃないの？
967: 310 2017/09/29(金)10:10 ID:Cw2Mz5dw(1) AAS
それならAdamですね。Tensor Flowなら当たり前ですね。
学習率ってだけだったので、Optimizer無しの学習率だと思いました（汗
省略時引数はたぶんモデル発表者の提示した推奨値です。
まあ、パラメータをいじるかどうかは、個々人の好みとい事で。
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.033s