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

**535** · 2018/09/18(火) 20:53:46.52

Geforceの発売が迫ってますね。
性能もいいけど値段もいい値段するとかって話で悩ましいですね。
しばらく様子見か。

**535** · 2018/09/21(金) 21:09:54.51

新Geforce、とりあえずpytorchが対応するのかどうか、
対応したとしてどれくらい性能上がるかみきわめてからですかね？
仮に大金だして買うとしても。

**310** · 2018/10/02(火) 09:01:31.04

ご無沙汰です。

地味に棋譜作成を続けていますが、そろそろ色々と重くなってきたので、
裏で新バージョンを作り始めています。探索に関係ないところは、色々
整理して結構軽くなった（と思う）のですが、探索部分の速度が大幅に
低下してしまって悩み中。

現バージョンとまったく同じ条件で比較したところ中盤探索で３倍弱は遅い。
比較してないけど終盤探索は下手すると１０倍近く遅い感じ。

中身はほぼ一緒なので、何が原因で遅くなっているのか不明。
コンパイルオプションなんかは一緒。共通で使用しているclassのどこかに
原因が潜んでいそうなんだけど、違いが見当たらない…

**310** · 2018/10/02(火) 23:18:16.56

まさかまさかの__vectorcallが原因だった。
全部取っ払ったら中盤探索については逆に速度３０％アップ。

変な事考えないでコンパイラに任せましょうというお話でした。

**310** · 2018/10/10(水) 09:51:58.44

２８コア５６スレッド…
１８コア３６スレッドが安くなるかなぁ。

棋譜作成を新バージョンに乗り換えました。

全体的に速くなる修正については、１０～２０％程度なので効果不明。
あと特定の条件で遅くなる原因を見つけて地味に潰しています。
後者については、一つ原因わかっていて直しようが無いものが。

並列処理にPPL使っているのですが、parallel_forではせっかく並び替えしても
ランダムに処理が走ってしまう事。ybwcなのでPVを最初に実行する事は保証され
ているのですが、PVが間違っていた時に、parallel_for内部で２番目の順位の
スレッドがいつキックされるのかわからないどころか、最悪一番最後の可能性も
ある点です。null window searchでβカットに強く依存しているので、ここは非常に
困ります。

解決策１）parallel_forの改良版を自分で書く
解決策２）スレッド数の多いPCに乗り換えて、この問題が起きる確率を下げる

どうしよう（汗

**535** · 2018/10/12(金) 21:02:40.65

9900Kも結構面白いかも？
結局新PC購入に踏み切れてないけど、
来るべきその日のためにGithub漁るところから再スタートしようかなぁ

**310** · 2018/10/12(金) 23:00:16.66

結局あきらめて解決策３）初段のみYBWCのお兄さんを２人にして様子を見てます。

forwardのロジック（最善手の手順で着手可能な手を展開）を全面改訂。
今まで降りていく手を、BitboardのLSBに近い方から１つだけ選択してましたが、
これによって局面の偏りが生じていたようなので、全て展開するようにしました。
棋譜の増殖が凄い事になっちゃうんだけど、仕方ありません。

同じ仕掛けでbackwardも書き直し。

Eigenの並列化、リソースモニタ見ても２コアしか使っていない感じ。４コア使う指定
しているのに。謎。

その他、並列化できるところは並列化を検討。

やっぱPC欲しい…１２コアくらいでも良いかという気がしてきた。

**310** · 2018/10/14(日) 23:06:48.18

局面の偏りが結構酷い事になっていました。

新しいforwardでは反復深化の評価値を表示するようにしたのですが、探索が進む
ほどに０になっていきます。そこで盤面のパターンが一回も出てこないケース（０値）
を調べたところ、後ろの方が大量に…。前回書いたLSB問題の影響がかなり大きい
という事です。

というわけで、棋譜作成の時には、少なくとも複数選択しあるときにはランダムに
選択するように変更し、既存の棋譜については、仕方がないので後ろの方をランダム
を導入した仕組みで再探索したものを追加していく事にしました。

１件１秒程度でできるので、折に触れてランダム化していこうと思います。
全部展開すると件数が大変な事になるので、様子を見ながらこの辺でお茶を濁して
みようと思います。

**名前は開発中のものです。** · 2018/10/18(木) 01:59:08.41

ずっと昔にオセロを作っていた者です。
久しぶりに再燃したので熱があるうちに…
50万棋譜計画のバグっている棋譜、被っている棋譜を消去して、22マス空きからの読み切り訂正をやってます
プログラムを3つほど立ち上げて一日9万局…めどは一ヶ月ぐらい
最近寒くなってきたのでちょうどいいかなとw

FFO45が32秒ぐらいで、まだまだトッププログラムには及びませんけど、
この棋譜訂正で大幅に縮まらないかと希望を持ちつつ進めてます

**535** · 2018/10/20(土) 22:43:08.00

zen2まで待つのはさすがに待ちすぎかなぁ？ｗ
とりあえずAQのコードに結構詳細なコメントが付いてることにいまさらながら気づいて
もう一度チャレンジしてみるかどうか迷ってるところ。

**310** · 2018/10/21(日) 22:20:35.21

>>475
はじめまして。新規参入嬉しいですね。

５０万記譜計画の記譜は今はHPからダウンロードできないですね。懐かしい。

評価関数が正しくないと、探索時間かかりますからね。
自分は今は、自作の記譜を後ろから順番に訂正していってます。
が、やはりすごく時間がかかりまするorz

**310** · 2018/10/21(日) 22:39:45.97

先日、局面の偏りで反復深化で評価値がゼロになっていく件を書きましたが、
もっと大きな問題な気がしてきました。

マイナスの評価値になるはずの局面から、中盤探索を反復深化で深くしていく時、
途中で評価関数的に未知の局面に入って、評価値０を返すようになる事があります。
もともと期待される評価値はマイナスなので、評価値０のルートに乗り換えてしまい
ます。どうもこの様な現象が起きる事で、探索を間違える事がありそうです。

これから、デバッグ用のプログラム書いて、現象を確認してみようと思います。

もしかしたら、評価関数の初期値をゼロから始めるのが、良くないのかもしれません。
初期値を－１にすると、未知の局面は－６６点（パターンの種類）になるし、１つ２つ
混入したくらいでは、評価値への影響も小さいのかなと思っています。

評価関数のゼロデータを－１にして動かしてみる方が早いかなぁ？

**310** · 2018/10/22(月) 22:40:29.62

一応、ゼロデータをすべて－１に置き換えてみたところ、それなりな感じで、
頻度はだいぶ減りました。が、まだ時々おかしな時があります。

デバッグ用のプログラムが案外簡単にできたので、評価値の計算を確認して
みたところ、反復深化の計算のどこかにバグがありそうだという結論に…。
ただ、ほとんどのケースでは正しそうなんだなぁ。

**310** · 2018/10/22(月) 22:53:50.11

ソース見てたら、一瞬で判明（汗
ほぼtypoの類でしたorz

これで探索少し早くなるかな？

**310** · 2018/10/23(火) 01:08:22.60

ウェイトのゼロデータを－１にしてみましたが、関係なさそうなので０に戻しました。
原理的にはマイナス評価値の問題は起きそうなのですが、評価値ゼロはあまり
発生していない感じです。

残り２７手読み切りあたりから今のやり方では追い付かなくなって来ていますので、
MPCモドキの導入を考えています。MPCのスレッショルドの計算を真面目に
やると、それだけで日が暮れてしまいそうなので、あくまでモドキですが（汗

置換表から作り直しになるし、記譜作り直しで、まだ２７手まで時間がたっぷりある
ので、１週間くらいじっくり考えてから始めようかと思います。

**535** · 2018/10/28(日) 21:48:30.83

うう、やっぱPCに３0万はおいそれと出せないorz orz orz
しかし、何もしないままでただ時間が過ぎていくほうが怖いような気もする。

**535** · 2018/10/30(火) 23:21:10.12

なんかRTXに不具合があるとか何とか
マジ？
もうしばらく様子見が正解か…

**310** · 2018/11/01(木) 00:10:54.87

MPCですが、完全読み切りをIterative Wideningで速度アップするためのProbCutを
作ってます。とりあえずスレッショルド計算のところまでできました。線形近似と誤差の
標準偏差の計算ですが、以前はループでゴリゴリ計算してました。今回はEigen使って
行列で計算するようにしたら超簡単でびっくりするほど早くなりました。
結局、計算時間の大半は浅い探索になります。

で、結果を見れば見るほど、無理に計算しなくてよいのではないかと思えてきます（汗
誤差は１σ＝４～５程度の固定値。線形近似は、１次係数は1.0で０次の定数（バイアス）
を、深さが偶数で＋１～＋２、奇数－１～－２くらい。探索の深さを変えると、誤差は
減っていきますが、あまり頑張るとオーバーヘッドになります。

そもそもIterative Wideningでは、探索精度ではなく、徐々に探索対象を広める事で、
置換表の精度を上げていく事で高速化をしますので、アドホックな値でも良いのかなと。
誤差やバイアスは今の自分の評価関数での値ですが、気が向いた時に再度チェック
するくらいで良いのかなと思う次第。

というわけで、大幅に簡素化・定数化して、読み切り処理の方に移る事にしました。

**535** · 2018/11/02(金) 23:35:29.24

9900K発売ですか。
かなり入手困難みたいですね。

**535** · 2018/11/04(日) 21:31:50.64

11/6にAMDからなにか発表があるとか
ZEN2くるかなー？
とりあえず今は待ちか。

**535** · 2018/11/08(木) 22:14:39.88

結局zen2は春ごろなんですかね？
いまはRyzen 2700xを買っていつでも乗り換えられる体勢を取るのが正解かなぁ？

**310** · 2018/11/10(土) 22:53:18.40

ぬぬぬ。

ProbCutのバグ取りに時間がかかりました。というか、なかなか高速化できません。
むしろ倍以上時間がかかってしまいます。

もっとひどい事に、今までのやり方のうち、比較的単純なやつが最も早い可能性が
高いという事に気が付いてしまいました…。下手すると４０％くらい早いかも。
ProbCut比では３～４倍速いという事です。

もともとProbCu自体は中盤探索で前方枝刈するための仕組みです。
これを読み切りしながら順次探索範囲を広げる事でソート順を修正する方向で
活用しようとしているのですが、下位のところを何度も読むオーバーヘッドがあり、
そこを置換表で高速化と考えていましたが、どこかがおかしい…。
そうこうするうちに、評価関数の精度が上がって、反復深化で十分実用になる
ソート順がセットできる事になった模様です。

まだバグの可能性は捨てきれませんが、一旦諦めようかな。

**310** · 2018/11/15(木) 23:13:39.64

ProbCutは一旦放置して、地道にSolverの速度アップを始めました。

作り直した時に、末端ノードの処理を結構簡素化しちゃったので、やり直しです。
で、Zebraの初期バージョンのオーダリングを日本語で解説した資料を見つけて
色々とノウハウを得まして、Fastest Fastの処理を見直したり、その他色々やった
ところ、速度が倍になりました。

が、見たくない現実としては、まだZebraの当時のFFOテストより若干遅い感じです。
以前はFFO#20限定で０．３秒くらいまで行っていたのですが、まだ１～２秒前後。
ちなみに、似たスペックのPCでの計測値が公表されているマスターオセロは、
更に１０倍程度高速です。ぬぬぬ。

棋譜作って学習していくと、探索時間が地味に短くなっていくし、時にはオーダリング
の間違いが直ってジャンプするように特定の盤面で高速化する事がありますので、
まだまだ辛抱かなぁ。

**名前は開発中のものです。** · 2018/11/17(土) 11:28:45.78

なんとか棋譜訂正が終わりました
それだけだと終盤探索にあまり効き目はなかったようです…
これで終わりたくなくて色々見直したところ、なんとかFFO55が6000秒から2500秒切るレベルまで高速化されました
ただ問題があって、空きマスリストを用意していない影響で、空きマスが2つになるまでビット演算で着手番号を取得してるので、NPSがかなり低くなっています
ここを改善するだけでも20%ぐらいは高速化するのではないかと…今週はそのへんやってみようかと思います

**名前は開発中のものです。** · 2018/11/17(土) 11:43:10.64

テスト結果を載せます
ここから２倍ぐらいになれば、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] )

**名前は開発中のものです。** · 2018/11/17(土) 11:45:17.49

間違えて前のバージョンを載せてしまいましたｗ
今回はこちらです。比較になってちょうどよかったかも

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] )

**535** · 2018/11/17(土) 17:28:43.31

うおお、ついに新PC買っちゃいました！
http://s.kota2.net/1542443012.jpg

**535** · 2018/11/17(土) 17:38:57.27

なんか買っただけで満足してしまっている自分がいるｗｗｗ

**名前は開発中のものです。** · 2018/11/17(土) 18:39:02.10

空きマスリストを作る方式でやってみたのですがビット演算のほうが5%速かったみたいです
こうなるとオーダリングのコストを下げるしか無くなってきました

**名前は開発中のものです。** · 2018/11/17(土) 18:40:00.61

RYZENですか
自分もi5なので、新しいPCが欲しいところ

**535** · 2018/11/17(土) 19:32:43.11

>>496
せっかくなのでなにか͡コテ名乗ってくれませんか？
まあ無理強いはしませんが。

**535** · 2018/11/17(土) 20:03:37.36

シネベンチマルチ１７０５CB
うーん、壊れる前のマシンの倍くらいにはなってるんですかね？

**535** · 2018/11/17(土) 20:20:24.98

さて本題のAI開発は何から始めようか？ｗ
差しあたっての目標はAQをwindowsでビルドかな

**535** · 2018/11/17(土) 22:39:28.71

>>491
よくみたらキャッシュ256MBってどうゆうこっちゃｗ

**535** · 2018/11/18(日) 00:16:59.82

windowsでビルドするの結構難しそう。

気分転換にAQのあらかじめexeになってるものを落として動かしてみたら割とサクサク動く。
そして当たり前だけど強い。

これは期待が高まるｗ

**310** · 2018/11/18(日) 01:01:51.11

おお。大体僕の倍くらいの速度ですね。
なお、気が短いし、記譜訂正が２６手目くらいまでしかできていないので、
今は#40-#44の５つしか計測していません。昔から#41がピンポイントで遅い。

空きマスのビット演算、ちょうどやったところです。
mobility使わずに、ｆｌｉｐ関数がゼロだと着手不能ってパターンです。
静的オーダリングを使っていますが、角優先×最後って事で。
パターン配列作ってループ回してＡＮＤ版と、先に空きマスをpextで並び替えて、
テーブル引いて元に戻して着手する版と２種類トライしまいしたが、速度差は
誤差としか言いようが無いレベルでしたorz
元に戻す演算を思いついたらまたトライする予定。

本日はProbCutを再トライ。今度はちゃんと高速化しているようです。
スレッショルド１．０σで反復無しで、その結果を用いてアスピレーションウィンドウ
サーチして、少し高速化できたかなぁと言う感じ。

ただ、投機的に高速化しているので、FFOで比較しても、苦手盤面がありそうです。
棋譜が揃って来たら投機のヒット率が上がると信じて、しばらく使ってみます。

**310** · 2018/11/18(日) 01:13:00.25

535さんニューマシンおめ！

自分はSurface3で、i7-4650Uの1.7GHz（2.29GHz）×４です。
キャッシュとかどこで見れるのかなぁ。

**310** · 2018/11/18(日) 01:19:18.37

ちなみに、偶数理論は何度かトライしていますが、速度低下してしまうので
使えずにいます。

ZebraはUndo方式で空きマスリストを常時更新しているようです。
僕はCopy方式で、末端の該当ノードで空きマスリストを作ろうとしているので
すが、なかなかうまくできません。

過去にpaint処理みたいな方法で完全な空きマスリストを作成しましたが、
当然オーバーヘッドが大きくて使い物になりませんでした。

最近は「どうせ４隅でしょ？」という事で、盤面を４分割して空きマス計算して
いますが、それでも遅い。

「どうせ４隅」が良くないのか、偶数理論の理解が間違っているのか…

**535** · 2018/11/18(日) 17:01:14.00

高負荷時のファンが意外とうるさいorz
熱風もなかなかorz
あんまり連続実行しないほうがいいのかもorz

**535** · 2018/11/18(日) 17:56:00.38

なんかクロームがメモリ1GBとか使ってるんだがこれで平常運転なのか？
メモリに余裕あるからってなめすぎじゃね？

**495** · 2018/11/18(日) 18:39:39.38

>>497
なるほど、では495ということで…
あとキッシュサイズは置換表のサイズです

**535** · 2018/11/18(日) 18:55:52.33

>>507
コテありがとうございます。よろしくお願いします。
CPUのキャッシュかと思ってビビりましたｗ。

**535** · 2018/11/18(日) 19:17:18.42

AQのビルド、linuxだとBAZELで、windowsだとCMakeでって書いてあるんだけど、
CMake用の入力ファイルが見当たらないorz
windowsもBAZELでやるんだろうか？そこからわからんorz

**535** · 2018/11/20(火) 20:47:23.74

いかん、投資に見合った成果を挙げねばｗｗ
とは思うが腰が重いorz

**535** · 2018/11/21(水) 22:15:48.48

windowsは一旦保留にしてLinuxに走るのが正解だろうか？

**535** · 2018/11/22(木) 23:20:13.56

ネイティブリナックスをデュアルブートにするかVMWareでいくか。
なんかwindows10とlinuxのデュアルブートは罠があるらしくちょっと怖い。

**535** · 2018/11/23(金) 15:43:50.93

うーん、やっぱAQ無理かもorz.
もっと簡単そうなのに逃げるべきだろうか？
とほほ

**名前は開発中のものです。** · 2018/11/24(土) 05:53:44.23

同一HDD 内で、Windows10・Linux のデュアルブートは、素人では元に戻せない。
だから、日経Linux では、仮想OS を使うように書いてある。
Virtual Box が多いかな

Ruby できるなら、Vagrant, Chef から使うのもよい

漏れは、WSL・Ubuntu16.04 を使っている。
ただし、WSL はGUI なし。コマンドのみ

開発用だから、本番では使えないし、Docker なども使えないけど、
WSLは単なるアプリだから、遊ぶには気楽

**535** · 2018/11/24(土) 20:30:54.02

うーん、今後の方向性が定まらないorz.
最終的にはwindowsでやりたいからそこも悩みどころ。

**名前は開発中のものです。** · 2018/11/24(土) 23:59:56.87

ボードゲームスレだよな？なんの話してんの？

**310** · 2018/11/25(日) 09:01:51.50

Iterative Widening何とかできた。平均的に高速化できていると思う。

FFOについては相変わらず>>495さんと比較して速度は半分くらいかな。

一方で記譜作成的には倍速になったイメージ。細かく４σまでWideningして
いる事で、仮探索の誤答が減った事が効いています。

　仮探索で増える時間
　　　＞　仮探索が正解した時に減る時間　＋　誤答した時に増える時間

Iterative Wideningで、仮探索時間の削減と正答率の向上の両方が実現できた
感じです。この辺、課題盤面との相性がある話なので、統計的に計ろうとすると
かなり面倒です。というか、統計的に計るためには、前提となる評価関数をロック
しなきゃなりませんが、現在記譜作成しながら評価関数学習させてますので、
前提が常に動いてしまいます。

現在オーバーヘッドが嫌で、ノード数をとっていません。並列化するとロック
の待ち時間で数％～１０％くらい速度が落ちちゃうからです。ノード数をとれば
純粋な速度比較がしやすいのですが、悩みどころです。

**535** · 2018/11/25(日) 22:15:31.15

なんも進展がないのでとりあえず昔作った19路囲連星AIをビルドする環境を新マシンに構築しました。
リハビリの意味でもしばらくこれいじってようかな。

**名前は開発中のものです。** · 2018/11/26(月) 11:23:16.87

オンラインボードゲームって作れば流行ると思うんだけど、誰もやらないってことはサーバの維持費の方が高くなるんかね？

**名前は開発中のものです。** · 2018/11/26(月) 12:10:20.62

そう簡単に流行るかよ
囲碁のkgsとかだってかなり廃れてきてるのに

**535** · 2018/11/26(月) 22:59:02.56

気持ちだけ焦るけど、何も進まないというorz
とりあえず、結果だけ求めるのは謹んで、
地道に愚直にディープラーニングの勉強するのが正解だろうか？

**310** · 2018/11/27(火) 09:45:52.43

自分の場合、プログラムいじるネタが欲しくて、ヘウレーカ！って感じを味わいたくて、
続けているだけだからなぁ（汗

目標でかすぎるとか、期限切りすぎると、焦って嫌になるだけだよ。

オセロなんて、既にやってる人ほとんどいないから、ちょうど良いのだｗ
今の目標は、６０歳になるまで続ける事ｗ

**535** · 2018/11/27(火) 18:36:07.13

そうですね
結局自分のペースで一歩一歩進んでいくしかないですよね
ありがとうございます

**535** · 2018/11/27(火) 20:02:14.21

これからどうしようかなぁ。
以前、途中までうまくいきかけた9路囲連星を移植したalpha zero　クローンのコードを読み解くのやってみようかなぁ。
それとももっと本とか読んで理論の基礎から固めていくべきだろうか。

**名前は開発中のものです。** · 2018/11/27(火) 21:15:20.03

loser_sのブログ読んだけど、重大発表やばすぎだろ

**535** · 2018/11/28(水) 22:14:06.77

VMWareのubuntuで9路囲連星のalphazeroクローン動かしてみたらなんかメモリリークする。
前のマシンではメモリリークなかったのに？
OSとかpython とかCUDAのバージョンが変わったせいだろうか？
うーん、解決する気力がいまいち湧いてこないorz

**535** · 2018/11/28(水) 22:31:22.70

やっぱ出来ればwindows & C++ で行きたいなぁ。
うーん。

**535** · 2018/11/28(水) 22:44:28.01

悶々としつつ19路囲連星AIでLV3と対戦させたら素晴らしい勝ち方した。
(;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])
自然な流れからのダブル必勝形。
こういうのがたまにあるから止められないんだよなぁ。

**535** · 2018/11/29(木) 20:09:22.49

ふーむ。ダブル必勝形で勝負ありかと思ったら白にも粘り筋があって意外と奥が深い。
でも正しく打てばたぶん黒の勝ち。

**535** · 2018/11/30(金) 20:09:22.21

やっとこさ週末か。でもどうせ進まない予感orz
せめてなにかこれだという方針が定まらないと。

焦っちゃダメと頭では分かっていてもついｗｗ

**535** · 2018/11/30(金) 20:59:59.07

理想を言えばwindows & C++ & reinforcement learning
その線で探ってみるか

**535** · 2018/12/01(土) 19:46:42.48

まだまだ方向が定まらないけど、来るべき時のために今のうちに棋譜集めを始めるべきだろうか？
無駄になるかもしれないけど、何もしないよりはいいよね？

**535** · 2018/12/01(土) 20:48:59.14

１６プロセス並列棋譜取り
なかなか圧巻ですな

ファンがうるさいけど

**535** · 2018/12/01(土) 23:10:46.72

全コア使い切っちゃうとほかの作業がしづらいorz
開発用と計算ぶん回す用で２台欲しいｗｗｗ
ありえないけど。

**310** · 2018/12/02(日) 10:27:19.04

使用コア数制限するパラメータないの？

自分のは並列化処理に使用コア数カウンタ入れて、同時並列数を制限している。
もっとも常に４コアで４多重マックスで動かしているけどorz。１６コアなら１つくらい
他のプロセスに空けても、あんま速度低下なさそうでうらやましい。

今現在は記譜作成がメインなので、気が向かない時もほっとけば棋譜を訂正しながら
勝手に学習して、少しづつ速度アップしてくれている。気が向かない時に焦らずに済む
のでお勧め(^^;

一時速度アップに燃えていたけど、１勝９敗以上の比率で速度アップに失敗して（まあ
そんなもんなんだけど）、今は停滞期間中ｗ

**535** · 2018/12/02(日) 21:28:29.33

>>535
その手がありましたねｗｗ
作業中は１２プロセス位にしとくか

なにはなくとも棋譜取りだけはコツコツつづけます。
一日で多分３～４０００局くらい取れるはず。

ちなみに今これ見てるけど速攻挫折しそうorz
https://github.com/HerveFrezza-Buet/RLlib

**535** · 2018/12/03(月) 20:43:08.98

一日回して4652局
思ったより取れてる。

**535** · 2018/12/03(月) 23:14:26.77

平日まとまった時間が取れなくてもちょっとづつでも進んでいかないとねぇ。
まあ、棋譜取りしてるだけでもいくらか気がまぎれるけど。
１００万局目指すか。

**535** · 2018/12/08(土) 23:40:47.79

RLlibやっとサンプルがコンパイルできた
ここまで長かった
つかリンクオプションで-lgslつけなきゃいけないとかずっぽり嵌ったわ

**310** · 2018/12/09(日) 13:20:20.42

まったりと記譜取りしてても仕方ないので、速度アップできないか色々あがいてました。

久々にプロファイラで確認したところflip関数が３０％、mobility関数が８％ほどでした。
Edaxのソース見つけたので禁断の答え合わせ。flip関数は一つ昔のタイプなので、
恐らく自分の方が早い。mobilitiy関数は少し早そうなので、考え方を導入。でも誤差
範囲の効果しかなかった。

速度計測ルーチンを作って、並列単体速度比が１．２程度しか無い事が判明。
並列処理で排他待ちしそうなところに無駄がないかチェックしたところ、ほぼ全部無駄
だった事が判明（汗。無駄箇所を全て削除したけど、誤差範囲（汗

後方枝刈（ヒューリスティックスなオーダリング）が気になるので、ノード採取してみた。
やはり２割程度速度ダウンするので、プリプロセッサで普段は切り離す事に。

その他もろもろ誤差範囲の改良を積み上げた結果、なんとなく１～２割は速度アップ
した気がしますが、並列処理の効率が悪いのと、後方枝刈の工夫が足りていないの
２か所が、これからの課題かなと思います。

あれ？なんか、ループしてmin-Max探索の高速化に目的が戻ってきている（笑）

**535** · 2018/12/09(日) 15:16:13.02

んあ？RLlibって強化学習のライブラリではあるけどalpha zeroとは直接関係ないのか？
全部無駄だった？
www

**535** · 2018/12/09(日) 20:10:15.58

ふらふら浮気しまくりｗｗ
浮き草のような人生だ。

今これ見ようとしてます。
https://github.com/novoselov-ab/ai-zero

**535** · 2018/12/09(日) 21:08:44.25

g++ にfilesystemってヘッダがないorz
とりあえずいまVSインストールしてる

**535** · 2018/12/09(日) 21:40:01.98

動いたっぽい。
久しぶりに一歩進んだ気分。

**535** · 2018/12/10(月) 22:15:43.67

なんか非合法手を選んでしまうみたいなんだが？
うーんなんだろ？

**535** · 2018/12/12(水) 22:24:55.51

他人のコードに頼るのやめて自力実装に走るべきだろうか？
他人のコードってなによりいまいち情熱が湧いてこない。

でも他人のコードも読めるようにならないと先はないんだろうなぁ。
我流じゃすぐ限界迎えそう。

悩ましい。

**535** · 2018/12/14(金) 00:02:46.12

まただよ（再起動）
windows10でも変わらずか…

**535** · 2018/12/14(金) 22:52:23.39

コーディングは進まないけど棋譜だけは溜まっていきます。
今、LV3 vs LV3の棋譜が61950局分溜まってます。
ファンがうるさいから夜中は回してないから日中だけなのにこのペース。
8コアはさすがといったところか。
アルファ碁Leeが16万局分の棋譜を使ったらしいからとりあえずその辺目指すか。

**310** · 2018/12/18(火) 00:10:23.05

FFOテスト（#40－#49）、色々誤差範囲の改良を加えてじわじわスピードアップ
していたけど、ある日突然２０％くらい悪化。元に戻せるところは戻したけど、
結局ダメで、裏で評価関数の学習し続けた結果、途中経過でたまたま探索が
悪化するところにはまってしまったと言う事かなぁと。

実際、悪化しているの#49だけで他は改善していたし、学習都度表示している
FFO問題の８手読みの次の一手の合否が、14/20から11/20に悪化している。

こういうのあると、速度アップで何を信じて良いのかわからなくなるよね…

**310** · 2018/12/18(火) 00:14:29.31

という問題もありながら、ノード数表示して、>>492さんの結果と比較すると、
ノード数に圧倒的な差が。NPSは速いけど、それ以上にノード数が多い。
枝刈の差というにはあまりに大きな差で、一桁近い差です。

これ、Iterativeな手法で生じる置換表探索の差じゃないかと思う。
自分のは置換表の動作が遅いので、あまり深い探索まで置換表を適用できず、
読切において後ろの方は置換表が無い（そもそも使用していない）事で、何度も
再探索しているからかなと。

concurrent_unordered_mapを使っているけど、自前でハッシュDB作った方が
良いかもと思い始めた。そこで速度アップすると、置換表適用深度を深くできる。

こういう時、自前で作る人はチェーンハッシュ使っているのかな？

**535** · 2018/12/18(火) 23:29:10.84

昔自前でハッシュ作ったことありますが素朴な実装だとさほど性能出なかった記憶がありますね。
自分の場合STLでいいじゃんみたいな結果でした。
テーブルのサイズをでかくすると意外と巡回が遅くなるみたいな。

**535** · 2018/12/19(水) 21:16:40.83

スマホでconnect4のパーフェクトソルバーをちょくちょく遊んでるのですが
パターンをかなり覚えて７割くらい勝てるようになりました
囲碁とかも真の棋理が明らかになった方が
逆に人間がコンピュータに勝てるようになるかもしれませんね

**310** · 2018/12/19(水) 22:48:18.33

ハッシュの構想し始めましたが、確かに自分が作って早くなる保証はないですね。
インターフェースを既存のstlに合わせようとか思って調べ始めたら面倒になりました。

で、色々見ていたら、そのまんま効率化できそうな使い方を見つけた。
有れば読み込んで更新、無ければ追加の方法です。

あとバケットサイズとか個数とか、その辺を調べていった方が早くなるかも。

並列処理だとtry_emplaceが使えないのね。これが使えたらきっと早くなるのに。

**535** · 2018/12/20(木) 23:32:19.98

また再起動してる。。。
まあいいけど、もう諦めぎみ。

なんか仕事が急に忙しくなってますますコーディングから遠ざかってますが、
棋譜だけは地味に溜まってます。今82889局分溜まってます。

並列化ハッシュってどんななんですかね。そういえば知らない。

**310** · 2018/12/21(金) 00:04:37.10

いや。まぁ。バケットか中のレコードか、どちらかの単位で排他かけるだけです。
Hash関数がきちんとばらけさせてくれたら、基本的にあんまり排他で捕まる事は
無いので、それほど気にしなくてもパフォーマンスに影響ないかなぁと。実際に
concurrent_unordered_mapの配列用意して、適当にハッシュでばらけさせて格納
してみたら（つまり、同じmapじゃなければ排他はおきない）、排他で遅くなっている
訳ではない事が確認できています。

と言いながら、iteratorとか考えだすと、何を並列セーフにして、何をアンセーフに
するかみたいな事で悩んじゃいます。

先日の続きでmax_load_factorとかbacketサイズとかいじってみましたが、
パフォーマンスにほとんど影響がないです。というか、どうせ後で逐次的に拡張する
くらいならと、backetサイズを増やしても性能は上がらないし、max_load_factorを
増やしても、性能が落ちるだけだったり…。

棋譜作成だけなら並列化レベルをもう１段上げて、４記譜同時作成とかすれば、
個々の読み切りはシングルスレッドに下げられて、ただのunordered_mapが使えるし
その方が棋譜作成的には速度アップしそうな気がしてきた（汗

FFO的には別処理になるけど。

**535** · 2018/12/22(土) 00:08:33.74

採りためた棋譜をもとに序盤DBを更新してみましたが、
確かにうち筋は変わってる気がしますが強くなってるかはよくわからないというorz
まあ序盤DBは誤魔化しみたいなものだから期待しすぎもよくないか。

**535** · 2018/12/22(土) 00:42:25.73

序盤DB更新で強くなってるか統計とってみたいけどモンテカルロが遅すぎてそれもままならないというorz
やはりモンテカルロに代わる何かを実装しなければ…

**535** · 2018/12/26(水) 00:12:59.86

棋譜USBメモリにコピーしたらめっちゃ時間かかるorz
１３０MBくらいなのにUSBメモリってやっぱ遅いんだな。

**310** · 2018/12/26(水) 00:20:29.39

４記譜並列作成実装してみました。ただいま本番状態でテスト中。
並列処理の基本は、なるべく上位の層で並列化すべしでした。

現状、並列探索の速度は、シングル探索の２倍程度です。
１つ１つの探索には時間が2倍かかるけど、４つ並列なので、トータルでは
半分の時間で処理できるので、実質２倍みたいな。

探索中のオーバーヘッドはほぼ無いはずで、待ち合わせロスくらいなので、
大量に一気に処理する分には、ほぼ無視できるかなと。

これやると、スレッドの数がモロに効いてくるんで…４８並列くらいできたら…

**535** · 2018/12/26(水) 00:30:44.15

310さんはintel派なんでしたっけ？
AMDでもzen2はかなりコスパいいものが来ると思いますが…

**535** · 2018/12/26(水) 00:40:17.50

試しにSSDに棋譜コピーしてみたらかなり速いｗ
やっぱそうなのか。

**310** · 2018/12/26(水) 03:07:45.74

あれれ。思ったほど速度が出ない…というか、単体の速度が半分どころか、
1/4くらいになっているイメージ…。深さが深いものほど遅いという事は、
置換表周りかなぁ。

棋譜作成する対象によって速度が結構変わるので、評価しづらい。

メモリー配置等の問題も考えないといかんような気がしてきた。

いかん。夜も更けていく…。

>>561
なんか、フラッシュメモリー自体は書き込みが遅くて、SSDだとその辺を並列
化とかキャッシュとかで回避しているらしいです。USBメモリーは、その辺真面目
にやっているもの（高価）と、そうじゃないもの（安価）で差があるけど、それでも
SSDには敵わないとか。

**535** · 2018/12/26(水) 21:06:48.31

明日か明後日あたりで棋譜１０万局分溜まりそう
深層学習のプログラム、組みたいなぁ
でも難しいんだよなぁ

**310** · 2018/12/27(木) 00:00:43.02

悩ましい。

シングルmin-Maxの並列動作と、パラレルmin-Maxのシングル動作。
どうも速度的には大差ない感じ。
２倍くらい速度出ると思ったのに…。

スレッド数が増えたら差が出てくるのかなぁ。

**535** · 2018/12/27(木) 20:54:08.52

10万局いきました。

**535** · 2018/12/27(木) 21:18:27.23

多分俺が世界で一番囲連星LV3の計算を回した人だろうなｗ

**310** · 2018/12/27(木) 22:00:15.50

色々あがいた挙句、そこそこ時間がかかる２６手空きを、それぞれで解いてみた。

並列探索で６分。シングル単独動作で１２分。シングル４並列動作で１８分。
やはり、シングルも４並列する事でなにがしかのオーバーヘッドがあるようです。

単純計算だと並列探索６分を４個で２４分に対して、シングル１８分で４つ解ける
事から３３％の速度アップが見込める事になるけど、体感そこまでの効果が感じ
られないというか、時間がかかる問題では更に差が大きくなっていて、そいつらに
足を引っ張られている印象。

そのうえで、裏でゴソゴソやりながら計算させる時に色々弊害があるので、
CPUの増強を決断するまで放置しようかと思います。

色々あがいた結果か、並列探索ですこーし速度アップした感じ。
１０％行くかいかないか。

**535** · 2018/12/27(木) 22:05:17.88

よくわからんがハイパースレッディングって単純に性能２倍になるわけではないということではなくて？

**310** · 2018/12/27(木) 23:06:53.59

もちろんそうなんだけど、排他待ちを要するデータも、待ち合わせロスも
無いので、もうちょっと性能出るんじゃないかと思っていたのです。

あと、うまく説明できないけど、ノード数が多い探索は、ノード数比以上に
時間がかかっている気がしています。まだ感覚の話ですが。

**535** · 2018/12/28(金) 20:37:08.10

LV３は強いんだけど詰み状態から詰みを逃してる棋譜が散見される。
直せるもんなら直したほうがいいんだろうけどかなり大変だろうな

**310** · 2018/12/29(土) 09:40:46.33

んー。シングル並列動作で６時間かかっても解けずに諦めた盤面とを見つけて、
パラレルで解いたら１時間４０分だった。空きマス２６だと通常１分程度なんだけど、
時々こういう時間がかかる盤面がある。今までテストが面倒なので、１０分以内に
終わりそうな奴でテストしていたけど、もしかしたら探索ノードが多い奴ほど、
シングル並列動作での速度低下が大きいのかも知れない。

時間がかかる奴ほど、シングル・パラレル比が悪化するなら、今考えている大体
３倍程度ってのは成り立たなくなって、もっと悪い事になる。それなら感覚的に
合致する。普通に流れている時には、シングル並列で高速化できそうな手ごたえ
があるんだけど、時間がかかる盤面が来ると急速に逼塞していって、なかなか
回復しないという感じ。

パフォーマンスモニタにらみながら、unordered_mapのメモリアロケーションの方法
を想像してみた。初期確保件数指定（倍々で自動追加される）してみたけど、溢れて
もいないのにダラダラとメモリー使用量が増えていく。もしかしたらOSにメモリーを
貰いに行く動作が排他待ちになっているのかも知れない。どうやって検証しよう。
やっぱ自前置換表作るしかないのかなぁ。

**310** · 2019/01/01(火) 10:13:37.88

あけおめです。

ヒープをダラダラと確保するのが気になったので、色々いじりました。

ordering用のvectorを、配列にしてスタックに。ついでにクラス化してメンテ性アップ。
少しだけ速度アップした気がする。

自前ハッシュテーブル型の置換表を作ってみた。
最初に大きく領域確保して、溢れた時以外領域確保しないようにした。
基本、余計な機能は実装していないので、処理は軽いはずなんだけど…
極ほんの少しだけ速度ダウンした感じ…

記譜作成はunordered_map版で実行しながら、改良をしてみたいと思います。
とはいえ、ソース的にはあんまり改良の余地がないんだよなぁ。

速度がそん色ないところまで行けたら、シングル版の並列での速度低下が
メモリー確保が原因か検証できるかなぁ。

**310** · 2019/01/05(土) 09:07:42.68

チェーン型でハッシュを組んでましたが、テーブルがあふれると結局ダラダラと
メモリー獲得し始めるので、オープンアドレス型に変更して、まとめて領域を追加
するようにしました。

この辺、もう趣味の世界ですね。
何をしても、速度は上がりも下がりもしない（汗

やっぱり探索ノードを減らす工夫が重要ですね。

**535** · 2019/01/05(土) 21:26:02.72

自己対戦のみで強くなるアルファゼロは理想ですが実装が難しそうなので
せっかく棋譜も集めてるので教師あり学習をやってみようかと思案中。

**535** · 2019/01/06(日) 00:55:45.70

とりあえず、棋譜データからmin-max探索して黒有利の局面か白有利の局面かの２択を学習させようかな。とか思ってます。
そろそろ寝るか。。。

**535** · 2019/01/06(日) 02:33:16.90

寝るタイミングを逸してしまったｗ
プログラミングってこれがあるから怖いよねｗ

**535** · 2019/01/06(日) 02:46:46.55

なんか１００兆局くらい棋譜を集めると序盤DBだけでもかなり押せるんじゃないかなぁ。
そんな感じ。

いかん、寝なければｗｗ

**名前は開発中のものです。** · 2019/01/06(日) 03:01:38.94

質の悪い棋譜ばかり100兆局集めてもあんまり強くならない気がするのですがどうなんでしょう
質のいい棋譜がそれだけ集まればいいですがそれはほぼ不可能ですし…

**535** · 2019/01/06(日) 03:14:04.86

そうはいってもLV3の棋力はかなり高い。
囲碁将棋でいえばアマチュア３段くらいには相当するはず。

**535** · 2019/01/06(日) 03:18:59.57

波があるからアマチュア３段は言い過ぎだったかなｗ
でもまあ強い時はかなり強い。

**310** · 2019/01/06(日) 14:23:08.43

置換表一時調子が良かったのですが、修正加えたら崩壊。
なんとなく読み取りが変な感じなんだけど、どこがおかしいのか全くわからず。

>>578
棋譜たくさん集めて序盤DB作ったら、その序盤DBのMax手順以外の手について
は、分岐した以後の盤面だけで学習させると序盤の穴が埋まるというか、間違った
盤面でぼやっとした学習するの避けられるかも。

今、序盤についてはそのやり方で学習させてます。

**535** · 2019/01/06(日) 20:12:44.73

とりあえず、昔作ったTINY-DNNのプログラムを引っ張り出してきて学習プログラムを仮組したが絶望的に遅いorz
グラボ使えればちっとは違うんだろか？うーむ。

**310** · 2019/01/06(日) 20:34:20.52

オープンアドレスうまく動くようになりました。
ここに愚痴ると、直後に原因がわかる罠ｗ

この数日の葛藤は何だったんだ。

**310** · 2019/01/06(日) 20:36:40.74

>>582
Tiny-DNNはGPU対応していないんじゃないかなぁ。
結局、DCNNはGPUで処理しないと無理っつー気がする。

**535** · 2019/01/06(日) 20:44:29.63

>>584
あ～やっぱそうなんですかねぇ。
GPUも結構いいの買ったのでぜひ活用したいところではあります。

**535** · 2019/01/06(日) 22:23:00.36

明日は仕事なのでハマらないうちに切り上げようｗｗ
社会人として自制しなければｗｗｗ

**535** · 2019/01/07(月) 20:55:27.41

学習回しても損失が全く減らない。。。
そういやそんなのあったな。orz

**535** · 2019/01/07(月) 23:12:38.14

なんかネットワーク初期化忘れてたみたいw
初期化したら損失減ったｗ

ちょっと希望が出てきた。

**535** · 2019/01/08(火) 23:12:12.87

損失減ることは減るんだけどホントにちょっとづつしか減っていかない。
ネットワークの形状が悪いんだろうか？学習率だろうか？
うーん、深みにはまりそうorz

**310** · 2019/01/09(水) 20:33:25.82

学習の速度はオプティマイザに依存します。

普通のSGDだと、あちこちぐるぐる回ったり、平野トラップで立ち往生したり、
局所最適解から抜け出せなくなったり。また、SGDは学習率（α）を大きくすると、
簡単に発散しちゃったりしますので、学習率を低めにして１０００回とか学習する
事になります。それでも上記の問題で、なかなか収束しなかったり、うまく学習
できなかったりします。

そういうものなのです。昔は、初期値（乱数設定しているはず）を変えてみたりして
トライ＆エラーしてましたが、今なら別のオプティマイザ（RMSpropやADAM）を試す
べきかと思います。それでも数百回は学習を繰り返さないといけないと思います。

久々に検索したら結構種類が増えてた。
https://qiita.com/ZoneTsuyoshi/items/8ef6fa1e154d176e25b8
自分は線形回帰モデルですが、SMORMS3を使って効率化を図っています。
それでも、数百回学習しないと損失は落ち着いてきません。

**310** · 2019/01/09(水) 22:31:13.85

置換表ですが、結局のところ、ハッシュのビット数を増やしてチェーン接続があまり
生じないようにし、メモリーをある程度のサイズでまとめて確保する、チェーン型
ハッシュに落ち着いています。

普段速度計測に使っているFFO#40-49ではconcurrent_unordered_map版より若干
遅いのです。が、どうも残り２８手（現在はそのあたりをチェック中）では、自作チェーン
ハッシュの方が早いというか、ノード数が増えた時に速度低下が少ないように感じて
おり、現在は自作置換表を使っています。

とはいえ、２９手や３０手まで行った暁にはチェーン接続が多発し始めて速度低下が
始まると思われるので、対策を考えて行きたいと思います。２８手が終わるまでまだ
一カ月くらいかかるので、幸か不幸か時間はたっぷりあります(--;

今のところチェーンの代わりに２分木を置いて、ハッシュが衝突したときの速度低下を
O(n)からO(log(2)ｎ)にしてみようかと考えています。

**535** · 2019/01/09(水) 23:20:11.40

ふーむ。要素が少ない時はリストやツリーは遅く、配列が圧倒的に早いという認識でしたが。

**535** · 2019/01/12(土) 00:34:20.08

あれ、序盤DBに棋譜を追加したら全然おかしな手を打つようになっちゃった。
棋譜がまずいのかな？

**535** · 2019/01/12(土) 01:02:50.64

くそ～強いAI（自我があるとかではないよ）作りてぇなぁ

**535** · 2019/01/12(土) 01:39:38.14

三連休とはいえそろそろ寝なければな。
生活のリズム崩すのはいくない。

**535** · 2019/01/12(土) 21:33:08.59

質にばらつきのある棋譜から良いデータを抽出する方法はあるのだろうか？

**535** · 2019/01/12(土) 22:30:56.75

うーんせっかく３連休なのに捗らないな。
これだというアイディアが湧くまでこねくり回すしかないか。

**535** · 2019/01/13(日) 22:01:49.93

結局アルファゼロという正解がある限りその呪縛から逃れるのはかなり難しいorz
うーん。

**535** · 2019/01/14(月) 21:36:22.16

やっぱグラボも活用したいなぁ。
でも難しいんだよなぁ。
とくにウィンドウズだと。

**535** · 2019/01/16(水) 00:51:29.20

昨日一日学習回して損失が初期値の2/3位になった。
この辺が限界かなぁ
それともぞうきんを絞るようにまだまだ損失減るんだろうか？

**310** · 2019/01/18(金) 00:47:06.53

NN系は学習してるんだかわからない時があるよね。
とことんまで回すと今度は過学習も怖くなってくるし。

こちらは、自作concurrent_mapクラスができました。
ハッシュキーは二分木で、ハッシュ値は64bit。
配列ハッシュキー版と同様に、削除もiteratorも無し。
すこーし速度があがったかなぁ程度。
衝突時の処理はチェーン式。流石に64bitだとキーの衝突が無い。

棋譜訂正は時間がかかるので、暇つぶしが必要な状態。
二分木を赤黒木に変えてみようかと思い始めています（汗。

本当はヒューリスティックスの改良の方が効果あるんだろうなぁ。

**535** · 2019/01/18(金) 22:51:46.73

今週は残業がひどかったorz
でも土日は休める。

**310** · 2019/01/19(土) 09:03:58.77

赤黒木を検討してますが、これ並列処理だと木全体をロックしないと
いかんのではないかと…。置換表のように追加の頻度が高いケース
では、排他待ちでパフォーマンス出ないかも。

まあ、やってみるしかないけれど。

**535** · 2019/01/19(土) 11:25:42.95

赤黒木とかめっちゃむずかしいやつですやん。
さすがですな。

**535** · 2019/01/19(土) 19:50:28.36

ん、なんか学習したネットワークがすべてのデータに対して同じ結果を返してるっぽい？

**535** · 2019/01/19(土) 19:58:01.80

学習開始時のネットワークの重みの初期化をミスってるんだろうか
うーん。

**535** · 2019/01/19(土) 20:54:13.90

tiny-dnn以外のGPU使えるライブラリで重みだけ学習してアプリケーションからはtiny-dnnを使うというのもあるのだろうか

**535** · 2019/01/20(日) 02:28:47.86

全く同じ結果ではなく微妙に違う結果を返してるのは確認できたけど。
単に学習量がたりてないのかなぁ。

**535** · 2019/01/20(日) 15:00:24.16

やっぱり全く同じ結果返してる？？
混乱してきたorz

**535** · 2019/01/20(日) 15:40:18.18

層が多すぎたのが悪かったみたい？
層減らしたら違う値になった。

**535** · 2019/01/20(日) 17:41:45.52

お、LV１に勝った！
まあDNNの学習の効果の勝利というよりも序盤DBと詰みルーチンの補助による勝ちなんだけどね。
でもとりあえず、それっぽく動くところまで来ました。

**535** · 2019/01/20(日) 17:54:10.26

序盤DBが良すぎてDNNの真価がわからないから序盤DB外してみるか…

**535** · 2019/01/20(日) 17:59:21.27

酷すぎｗｗｗｗ
でもランダムよりはマシに見える。

**535** · 2019/01/20(日) 18:24:44.15

やっぱ序盤DBに頼るか…
こんなにプログラムが楽しいの久しぶりやな

**535** · 2019/01/20(日) 20:01:09.83

たぶんだけどまだまだ棋譜増やしたほうがいい。
ていうかあればあるほどいいい。まだまだ良くなる。
可能なら１００万局を目指したい。

**310** · 2019/01/22(火) 00:34:53.58

赤黒木大体できたけど…ただの二分木よりほんの少し遅い…。

元々ハッシュでランダマイズしているから、二分木の末端ノードまでの深さは
綺麗な正規分布になっていて、赤黒木にしても木の最頻高さで３割程度しか
小さくならないという事で、ツリーを修正するオーバーヘッドが効いているのか、
それとも木全体でしか排他できないのが原因なのか。

もうちょっと調べてから諦めます。

**535** · 2019/01/22(火) 22:52:21.02

要素が１００個未満ならぶっちゃけvectorでいいと思いますが。。。

**535** · 2019/01/22(火) 23:02:42.33

前も同じこと言ったような気がするけど、学習させるなら局面の勝率より次の一手のほうがいいのだろうか？

**名前は開発中のものです。** · 2019/01/22(火) 23:17:25.29

いまきたんですがここはどんなゲームを開発してるんですか
じぶんで開発したとして対戦相手=プログラムありますか

**535** · 2019/01/22(火) 23:34:54.50

>>619
とりあえず、落ち着いて。
過去ログから読んでください。

**310** · 2019/01/23(水) 01:56:46.43

置換表に使ってるので要素数は現在残り２８手で１００万超える事もあります（汗
まあ、βカットの具合でだいぶ変わるので、学習進むと減るんですが。
最低でも残り３０手まで行くつもりなので、１０００万くらいは想定したいです。

次の一手ソート用の配列は、Array型にしています。３２個確保すれば足ります。
こちらも比較したところ、明確に速度差がありました。この辺から、領域をチマチマ
確保されるオーバーヘッドが気になりだした次第です。

で、赤黒木ですが、実装が悪いのだと思いますが、現時点で２分木と比較して
およそ３倍時間がかかります。シングル動作でも同じくらいの差になるので、
排他待ちではなく、木のつなぎ替え処理の重さが原因かなと。置換表は追加が
の比率が大きいので、ポインタたどるロスは優位ではない感じ。

というわけで、赤黒木はちょっと放置。

というか、二分木もシングル動作は１０倍くらい速い感じなので、今一度シングル
探索の並列化を試そうと思っています。

**310** · 2019/01/23(水) 02:07:28.76

>>618
min-Max前提だと、探索値を求める際には勝率（点数）が必須で、
次の１手評価関数はオーダリングや前方枝刈向きではないですか？
探索深さ１なら次の１手で行けますが。

初代アルファ碁も、両方組み合わせていますが、次の１手評価関数で
手の優先順位をつける事で読み深さを実現した変則mctsで、最終的には
評価値で判断していますよね。

**535** · 2019/01/23(水) 20:43:46.28

ふーむ、勝率のほうが応用が利くってことですかね？
もうしばらく勝率で学習させてみます。

**535** · 2019/01/23(水) 21:07:20.14

ついネットワークを大きくしたくなっちゃうけど。
本当は小さいネットワークでエポック数を稼いだほうがいいのかもしれない。

**535** · 2019/01/23(水) 21:28:27.72

そういえば、対称局面も学習データとして使ったほうがいいんでしたっけ？

**310** · 2019/01/24(木) 01:32:42.88

囲連星は初期配置ないんでしょ？
だったら対象局面ありの方が良いと思う。

オセロは悩み中。
初手をF5固定にした時に、本当に対称局面が出てくるのかわからない。
対称局面が同じ重要性で生じないのであれば、評価値を希釈しちゃうだけ。
学習の時間も単純に倍々で増えるので、今はやっていない。

強いて言うなら、F5F6E6の次がF4とD6で斜め対称になるので、ここだけは
記譜作成時にはF4固定にして、D6の対称局面を作っている。

**310** · 2019/01/24(木) 01:49:46.37

置換表自作の件、目的を見失っている（汗
一旦リセットして、最初からやり直して、当初の目的に戻ろうと思うorz

**578** · 2019/01/24(木) 01:53:14.72

私は教師データの数が8倍になるのは大きいと思って対称局面も入れて学習させてます
とくにDeep Learningさせてると（ネットワークの規模にもよりますが）だいぶ過学習しなくなります
もっとも、Deep Learningするんだったら対称性を考慮したネットワークにしたほうがいいのかもしれないですが・・・

**310** · 2019/01/24(木) 02:08:25.51

着手できる場所の自由度が高いゲームは回転させるべきだと思う。
オセロは着手可能場所が限られるので、現れない局面が結構ありそう。

ちなみに、オセロは８倍じゃなくて４倍。初期配置が４対称だから。
囲連星は初手天元固定なのかな？

**578** · 2019/01/24(木) 07:09:21.18

>オセロは８倍じゃなくて４倍
たしかに棋譜で考えると4対称しか無いですね
今のところ、学習させるときには現局面しか渡してないので、
90度回転で一致する局面が存在するかもしれないから8倍で良いはず…

**535** · 2019/01/24(木) 22:03:23.55

うーん。今のやり方だとLV0やLV1とはいい勝負になるけどLV3には一生勝てないかも？
出来れば自己対戦による強化学習とか取り入れたいな～

対称局面もやってみますね。

**535** · 2019/01/24(木) 22:45:59.18

なんか長時間計算回してると画面が真っ暗になってマウスやキーボード押しても復帰しないことがあるんだが？
スリープは解除してるはずなんだけどなんなんだろう？

**535** · 2019/01/25(金) 23:18:39.41

LV0ってやっぱ棋力低いな。
そんなLV0といい勝負の俺のAIもあれだけど。
やればやるほどLV3の完成度の高さが際立つ。

**310** · 2019/01/26(土) 17:00:37.38

自作置換表ですが、大体のところがまとまりました。
結局のところ、unordered_mapを作っていた形になります（汗

当初は領域の追加について、データ部分をまとめて追加する方向で改造し、
ハッシュ配列については２２ビット固定で、高速化をしました。で、ハッシュ配列が
２２ビット固定は芸がないと、二分木・赤黒木などを試しましたが、速度大幅低下。
要するに、unordered_mapにmapを組み合わせて、ハッシュのメリットを相殺して
しまっていたという事で。

最終的に、ハッシュ配列の追加方法をようやく思いつき、組んでみたところ、それが
そのままunordered_mapのrehashだと気が付きました（汗。その後、max_load_factor
などを追加して、unordered_mapと条件を揃えて速度比較となりました。

iteratorと削除が無い分だと思いますが、unordered_map、concurrent_unordered_map
に対して、それぞれシングル版、concurrent版とも若干高速になりました。

新たな課題は…stlも自作版も、どちらも並列に動かしたconcurrent版の方が遅いと
言う事です。もともとそういうものなのか…テスト方法が並列向けじゃないのか。

**535** · 2019/01/26(土) 17:38:15.71

8対称はメモリがやばいので4対称にします。
4対称で16GB位食ってる。

**535** · 2019/01/26(土) 17:54:22.18

思い切っていいPC買ったけどまだ足りないとかorzorzorz
ケチらず64GB積むべきだったか？

**535** · 2019/01/26(土) 18:59:37.97

１エポック4539秒
これは厳しいorzorzorz
GPUが使えれば…

**535** · 2019/01/26(土) 19:45:15.05

ん、1エポック目だけど損失がかなり少ない。。
対称局面を入力とすることで特徴量がよりはっきりしたということだろうか？

**535** · 2019/01/26(土) 19:46:56.43

ん、動きが断然よくなってる？
まだわからんが。

**535** · 2019/01/26(土) 19:53:15.64

対称局面学習以前はどちらかというとランダムに近かったが
対称局面学習以後はどちらかというと知性があるっぽく見える。
まだわからんが。

**535** · 2019/01/26(土) 20:02:51.02

これでエポックが進めばとんでもなく強くなる？
まだわからんが。

**535** · 2019/01/26(土) 20:15:10.01

マシンパワーが欲しい！
Googleに匹敵するマシンパワーが！

**535** · 2019/01/26(土) 20:40:08.93

まだLV3には遠く及ばないな。
でも希望が出てきた。

**535** · 2019/01/26(土) 21:34:58.78

学習用、棋譜採取用、対戦統計用、開発用で４台マシンほしいｗ

**535** · 2019/01/26(土) 22:03:09.49

やっぱ思考時間短いのはいいな。
モンテカルロは強いけど思考時間長すぎたからな。

**535** · 2019/01/26(土) 23:04:44.42

棋力が低すぎてすさまじい泥仕合になるの切ないorz

**535** · 2019/01/26(土) 23:32:04.39

メモリがもっとあれば異なるネットワークを並列に学習とかもできたかもなぁ
まさか32GBで足りないとは…

**535** · 2019/01/27(日) 14:58:44.29

DNNの評価値とMM法の評価値の和で最終評価値を算出するようにしてみました。
多分DNNのみより強くなってます。

**535** · 2019/01/27(日) 15:49:50.57

黒番で軽く動かしてみました。

10局目
黒(airandom.dll)の勝利回数: 8
白(ai-lv1.dll)の勝利回数: 2

まずまずの結果かな。
ちなみに白番はうまく動いてなくて１の１とか打っちゃうので途中で中断しました。

**535** · 2019/01/27(日) 16:41:37.92

うお、猛烈に追い上げられてるorz
悪くない手ごたえがあったと思いましたが…

25局目
黒(airandom.dll)の勝利回数: 15
白(ai-lv1.dll)の勝利回数: 10

**535** · 2019/01/27(日) 19:54:22.32

ちょっとヒューリスティックを入れました。
詰めろがあるときは詰めろを優先的に打つ。
当たりの点数を恣意的に上げる。

**535** · 2019/01/27(日) 21:09:49.27

うおお、キター
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

**535** · 2019/01/27(日) 21:11:57.38

ついDNNの学習に計算リソースを使いたくなっちゃうけど
ぐっとこらえてすべての源泉である棋譜取りにリソースを回すのが正解かも？

**535** · 2019/01/27(日) 21:39:45.24

いやーこんなに充実してるの久しぶりだな。
長いトンネルを抜けたようだ。

**535** · 2019/01/27(日) 22:08:36.61

うお、またLV3に勝った！
まだまだ負け越すだろうけど、偶然の勝利じゃないってことか。

(;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])

**535** · 2019/01/27(日) 22:25:29.35

明日は仕事だから夜更かしは社会人として自制しなければｗｗｗｗｗ
そろそろ切り上げるかｗｗｗｗ

**535** · 2019/01/28(月) 19:44:18.33

そういえば赤黒木って深さキャッシュして置くんですか？オーダーlogで深さを求める方法が思いつかない

**535** · 2019/01/28(月) 21:07:17.34

長連判定入れなかったのが意外と響いてるな。
ちょくちょく長連に引っかかる

**535** · 2019/01/28(月) 21:36:36.08

ん、DNN学習の裏で棋譜取りしたら計算速度落ちてるな。
コア数は足りてるはずだがメモリ帯域が足を引っ張ったのだろうか？

**535** · 2019/01/28(月) 22:36:38.66

こちらの棋力が上がるのに呼応するようにLV３も素晴らしい手を返してくる。
奥が深いすな。

**535** · 2019/01/28(月) 22:50:40.16

LV3との対戦統計とってみたいけどまだ時期尚早かな。
まずは大量の棋譜を手に入れる。
量が質に転換する地点が必ずあるはず。

**535** · 2019/01/28(月) 22:57:44.79

将来的には自己対戦による強化学習は絶対取り入れたい。

**535** · 2019/01/29(火) 20:45:33.27

今一手読みで打ってるから、３手読みとかモンテカルロか入れたらもちっと改善するかな？
でも計算量がどうなるかだなぁ。
遅いのはコリゴリ。

**535** · 2019/01/29(火) 22:13:06.04

とりあえず2手読みにしてみたけど2手読みが限界かなぁ
3手は計算量的に相当厳しそう。

**535** · 2019/01/29(火) 22:33:10.05

２手読み、なかなかいい感じ。
１手読みから明らかにうち筋が良くなっている。
もし３手読みにしたら…

**535** · 2019/01/30(水) 21:21:00.00

３手読みを仮組してみました。
計算時間がやばいので前方枝刈で思いっきり枝刈してます。