【オセロ,将棋】ボードゲーム Part3【囲碁,War】 (636ﾚｽ)
【オセロ,将棋】ボードゲーム Part3【囲碁,War】 http://mevius.5ch.net/test/read.cgi/gamedev/1574503798/
上
下
前
次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
抽出解除
ﾚｽ栞
ﾘﾛｰﾄﾞ規制
です｡10分ほどで解除するので､
他のﾌﾞﾗｳｻﾞ
へ避難してください｡
310: 310 [sage] 2020/05/29(金) 20:25:58.86 ID:wYh6jGrP orderingの中でパス処理をしていたのでmobility関数を呼びまくっているのが遅い原因 ではないかと思い、パスの処理の仕方を変えて、パスも１手とするように変更したところ、 １５〜２０％の速度低下まで戻りました。他にも、つられてバグが発覚したので修正。 かなりのレアケースでしか発生しないバグですが、今まで自信満々で完全読み切りは 間違っていないと思っていましたが、なんか自信なくなった。 中盤探索も同様に修正したら、浅い探索の読み筋が変わったみたいで、少しは精度が 良くなるのかなぁと期待しています。 http://mevius.5ch.net/test/read.cgi/gamedev/1574503798/310
296: 310 [sage] 2020/05/18(月) 21:57:15.59 ID:lyHQ6R5E Hash関数変更 DBのハッシュキーの効率が悪かったので、ちょっと考えてみた。 今まではshuffle_epi8でバイト単位シャッフルしていたのを、BMIのpextでビット単位の シャッフルと、rotateしたものを、xorでまとめていく方法。以前よりは、ちょっと良くなった 気がする。 何をもってよくなったかの指標が欲しくなり、ネットを探索したけど、数値指標みたいなの は見つからない。確率論の誕生日問題の反対みたいな状況なのでしばらく考えてみる。 要するに、１万人くらいの生徒がいる学校で、誰一人誕生日ではない日が何％くらい存在 するのかという類の問題です。 また、そう考えてみると、現状では直観よりかなり未使用キーが多い気がしています。 xorを繰り返してビットのオンオフをすると、いずれ立っているビット数が３２個を平均と した正規分布（二項分布）になって、一様分布にならないのではないかという疑念が。 正規分布だと、中央に近いところは重複しやすく、立っているビット数が０とか６４とか の出現確率が下がる事になります。xor繰り返すと正規分布に本当に近づいていくのか、 ちょっと検証してみたい。 http://mevius.5ch.net/test/read.cgi/gamedev/1574503798/296
297: 310 [sage] 2020/05/18(月) 22:17:24.43 ID:lyHQ6R5E DBの件 たぶんあるだろうとネットで検索してみたら、Kyoto Cabinetなるキーバリュー型の 簡易DBライブラリがある事が判明。ほかにもLevelDBとか、何種類かあるみたい。 RDB使うまでもないけど、データ量が多いとメモリーだとリソース勿体ないみたいな。 やはりみんな考える事は一緒だなと。せっかくなので導入の方向で検討。 DBの速度問題 また、おそらく１棋譜単位でのBook更新は速度的に問題ないのですが、DAG（合流） 時に、棋譜外の合流元の方の更新がされないという問題があり、学習前に一括で 再構築しています。この一括更新が件数の関係ですごく時間がかかる事が問題です。 一応、１棋譜単位で更新した時に、DAG分もちゃんと処理するロジックを検討中です。 バグさえなければ速度問題はかなり解消できるはず。とはいえ、何回もループを回す 処理となるため、速度に自信なし。 http://mevius.5ch.net/test/read.cgi/gamedev/1574503798/297
298: 310 [sage] 2020/05/18(月) 23:50:13.18 ID:lyHQ6R5E DBの件… 確定探索の時にはメモリーに確定分だけおいとくと考えていましたが、 今件数確認したらおよそ２／３は確定分として確保しなきゃならない 事に気づきました（汗 棋譜作成時はメモリーでやるしかないかも。 １棋譜更新でのDAG問題回避はやりたいかな。 Book再構築にだいたい２０分くらいかかる。 DAG回避で１棋譜分更新するのが１秒として１０００棋譜追加でおよそ１６分。 これ以下の時間で済むならやる価値ありそう。 http://mevius.5ch.net/test/read.cgi/gamedev/1574503798/298
299: 310 [sage] 2020/05/20(水) 01:15:22.70 ID:Xgj8E+2H 久々に完全読み切りでバグ発生。 ProbCutを広げながらmtd(f)している時に、どうもパス絡みで発生しているっぽい。 ProbCutによるIterative Wideningを止めたらちゃんと読み切る。 まあ、置換表絡みなんだとは思うけど、事例が少なすぎて（数か月に１回程度）、 前の記録消しちゃったので、とりあえず記録を残し、絆創膏当てて続行。 気が向いたらデバッグしてみる。可能性があるところはなんとなくわかっている つもりだけど。 Book更新時のDAG回避は、かなり悩ましい。というか頭がこんがらがる。 未使用Hashの期待値計算も頭が未だにこんがらがってます。。 http://mevius.5ch.net/test/read.cgi/gamedev/1574503798/299
302: 310 [sage] 2020/05/20(水) 17:28:20.84 ID:Xgj8E+2H Hash関数の効率判断基準できました。 同じキーにデータが８つくらい入っているようなものもあり、それが適正かどうか 判断できなくてゴチャゴチャしていましたが、昨夜しれっと書いたように未使用キー の数の期待値に着目したら簡単でした。 キーサイズと、データ件数からExcelなどで簡単に計算できます。 ３件程度調べてみましたが、理想的な一様ランダム値で生じる未使用キー数の 期待値との差は０．１％未満で、このHash関数も一様ランダム化するものと言って 良いレベルでした。 逆に言えば、自分の典型的な使用方法だと２０〜３０％のキーが未使用になる という事のようです。これはこれで…。 http://mevius.5ch.net/test/read.cgi/gamedev/1574503798/302
304: 310 [sage] 2020/05/21(木) 00:46:28.65 ID:ahADKaci Hash値、１件２件…と期待値出そうと思ったら、なんとなく昔の記憶が戻ってきて、 ０件の時は不要だけど、こちらではPとかCとかが必要になるような気がしてきた。 確率の勉強するかな。 ZDDちらっと見てみたけど、ちょっと目的と違うような感じがしている。 本買ってみるけど。 脱線はこれくらいにして、DAG考慮したBook更新に戻ろう。 http://mevius.5ch.net/test/read.cgi/gamedev/1574503798/304
308: 310 [sage] 2020/05/29(金) 00:49:53.42 ID:wYh6jGrP DAG時のBook更新の件、めっちゃ悩み中。 普通にやったら１件更新に１４秒とかかかって使い物にならない。 逆引きDBを作ろうかと思うのだけど、結構なサイズになるので、それこそメモリーに 置きたくない。形としてはunordered_multimapになるんだけど、Kyoto Cabinetが重複 キーを許すのか英文読まなきゃならないので止まってる。 そうこうするうちに完全読み切りのバグがまた発生して、事例が３件になったので、 調査開始。２か所間違いを発見。一つ目はケアレスミス。 ２つ目は最善手の直後にパスが来るケース。置換表登録はパス後、オーダリングなどで 読む時はパス前の盤面になっていた。これで値が狂う理由がいまいち理解できないの だけど、修正したら正しい答えが出るようになった。パスの処理は本当に鬼門。 たぶんバグは取れたけど、５０％くらい速度低下。どこかにまだバグがありそう。 http://mevius.5ch.net/test/read.cgi/gamedev/1574503798/308
309: 310 [sage] 2020/05/29(金) 00:56:37.17 ID:wYh6jGrP 速度低下は５０％どころではなかった…１５０〜２００％だorz http://mevius.5ch.net/test/read.cgi/gamedev/1574503798/309
312: 310 [sage] 2020/05/31(日) 10:02:44.30 ID:/CnVYfEH またエラーが… なんとなく記憶をたどっていくと、初段で並列処理してMap-Reduceすると、βカットの関係で 評価値は合っていても、ｏｒｄｅｒｉｎｇ次第で間違った手を返す事を思い出しました。 で、たまたま回避策となっていた処理を>>201で外してしまったのではないかと。 並列探索だと本質的に回避できない気がするので、初段を順次処理に変更。残り空きマス ２６での平均処理時間。一時は２０〜２５秒くらいまで来ていたのが、３０秒程度に悪化orz http://mevius.5ch.net/test/read.cgi/gamedev/1574503798/312
314: 310 [sage] 2020/06/05(金) 22:28:59.18 ID:TnykYlJh 藤井７段凄かったね。今年中に８段行っちゃうんじゃないかと思った。 エラーの原因を冷静に見直したところ、どこをどう変えたか覚えていないレベルの ちょっとした修正を加えたところからドツボって、修正するたびに更にバグを仕込んで いたような。結局、元々のプログラムに戻して、速度も復旧しました。むむむ。 こういうのがあるからから、終盤探索に手を入れたくないorz Bookの遡り修正ですが…行き詰っています。 Kyoto Cabinetはやはり単一キーしか扱えず。 メモリー上に逆引きDBを作ると、たぶんBookよりサイズが大きくなるためメモリーにおけない。 しばし悩み中。 息抜きで、棋譜作成のロジックをちょこっと修正。 同じような評価値が並んでいたり、最善手より評価値が良くなる分岐について、今までは 見つけて気になったところだけ手で追加していましたが、適度なペースで見つけて自動的 に追加する様にしました。 http://mevius.5ch.net/test/read.cgi/gamedev/1574503798/314
316: 310 [sage] 2020/06/15(月) 23:12:30.86 ID:r41RfhWg DB化、未だに方法が見いだせずストップしてます。 パブリックドロー臭いのにそうじゃない筋を手動で修正して、２０件ほどもとに戻った。 その間に、棋譜が１００万件突破しました。 が、Book眺めていると、まだまだ間違い多い。 Zebraも結構間違えているけどね。 http://mevius.5ch.net/test/read.cgi/gamedev/1574503798/316
326: 310 [sage] 2020/07/03(金) 01:33:21.30 ID:ULg6SDrD 相変わらず棋譜作成しながら評価関数学習を続けています。ようやく１００万件突破。 推定パブリックドローは大体７００件くらいで増えたり減ったりしています。 対称形や合流も重複させていますので、重複除くと４００件くらいかなぁ。 終盤は比較的多数の分岐を試しているのですが、序中盤の分岐が不足していて、 棋譜が偏っているような気がしてきたので、棋譜作成のロジックを大幅に変更して 序中盤の分岐が多くなるように。また、評価値とBook値が大きく違う分岐を再検証 するようにしてみました。これで、抜けている筋がだいぶ拾えるようになると期待。 棋譜作成中に暇な時間が多いので、試しにZebraと対戦。Zebraはランダムに パブリックドロー筋から外れる様にできているようですが、外れたら勝てるはずが、 なかなか勝てない。Zebra２６手読み、こちらは時間の都合で２０手読みくらいなので 仕方が無いのですが、それにしてもBook外れた時の評価関数の精度が悪いという事に。 あと、やはり中盤探索の速度に大きな差があり、とても２６手読みなどできない。 むむむ。 http://mevius.5ch.net/test/read.cgi/gamedev/1574503798/326
327: 310 [sage] 2020/07/03(金) 01:35:54.46 ID:ULg6SDrD つか、藤井先生強すぎ。 １回勝負なら時々一発入るけど、番勝負で勝ち越せる人いないんじゃないかな。 竜王戦勝ち進んで、豊島竜王名人との番勝負が見てみたい。 http://mevius.5ch.net/test/read.cgi/gamedev/1574503798/327
331: 310 [sage] 2020/07/11(土) 00:47:07.96 ID:UjRsM2rb 残念だったね＜Ｆ７先生。相当疲れているんじゃないかな。まだ連戦続くので心配。 こちらは棋譜じゃんじゃか追加中。もう逆順探索で正確さを高めるなんて言ってられない。 いちいち遡りチェックするより、分岐を増やしてしまった方が早い気がしてきた。 で、Zebraと対戦させると、まだまだ穴だらけ。Zebraがわざとパブリックドローから外した ところからが本番の対局となるのですが、そこから１０〜２０手の間に２回くらい間違えて 逆転される感じ。逆にZebraがほとんど間違えていない事に驚いています。評価値は怪しい ところもあるけど、選択する手のミスが本当に少ない。Zebra２４手読みに変えましたが、 こちらは１７手。読む深さの差もあるのか。 デバッグ用のBookチェックプログラムを改良して、簡易対戦と棋譜訂正が外から簡単 にできるようにしました。今まではプログラム動かしていると、気が付いた訂正箇所も いちいちプログラム止めないと追加できなかったのですが、動かしっぱなしのままで 訂正済棋譜にして適宜放り込めるようになりました。ただ、Bookが凄い勢いで増大して いるので、メモリーがかなり危機的状況になってきました。BookチェッカーもBook全体を 読み込むので、ダブルで効いてくる。今16Gなのですが32Gは欲しい。 Zebraに負けた棋譜の手を遡って最善手順っぽいの探して訂正していくと、まだまだ パブリックドローっぽい手順が結構見つかる。過去に間違えてパブリックドローではない と判断している奴も結構ありそうなので、見つけられたら最終８００件くらいは行くと思う。 中盤探索の速度差は、ただのProbCutとMulti-ProbCutの差かなぁ。あれ、再計算が重くて 以前は実装していたんだけど、PC壊れてソース全滅して以来手を出していないのよね。 http://mevius.5ch.net/test/read.cgi/gamedev/1574503798/331
333: 310 [sage] 2020/07/17(金) 13:10:16.58 ID:wiyFtChq 王位戦第二局も含めて、ツエーーーーーーーーーー！って、今更ながらに思った。 人間相手ならabemaAI的４０：６０で不利な局面程度はひっくり返せるという事なんだろうなぁ。 あと、木村王位の体育座りが悲しかった。 棋譜作成は、自動作成で一気に大量に貪欲法かけたところ、既存の推定パブリックドロー筋 の４割くらいが、事前の分岐でパブリックドローから外れる事態に（汗 想定からズレた箇所は、見つけ次第ログに書き出して、そこから貪欲法でチェックするの ですが、それでもパブリックドローから外れる筋については、Zebra使って徹底チェック。 自分のAIとZebraが同意見でも、読みが深まるにつれて揺れ動くZebraの評価値を見ていた ら、なんとなくZebraが間違えていそうな着手がわかるようになってきて、その手をさらに 深堀してチェックする事で、ほぼ元の数まで戻す事ができました。たぶん、「パブリック ドローから外れるのが正解」という筋が２系統ありまして、逆に周辺を掘って行ったら別の パブリックドロー筋が見つかったりして、現在のところ残り３０手推定パブリックドローが ７８０通り程度となりました。 増えたり減ったりはあるけど、今週だけで８０件近く増えているので最終は１０００件程度に なってもおかしくない気がします。 もろに、人間が判断して手作業で修正みたいなのが、悲しいところ。 Zebraが無ければこんな事できないわけで。 http://mevius.5ch.net/test/read.cgi/gamedev/1574503798/333
339: 310 [sage] 2020/07/31(金) 00:20:53.97 ID:EPRjv06N 一括貪欲法を何度か繰り返す事で少し落ち着いてきたみたいで、パブリックドロー候補は ８５０件くらいになりました。 別途、Bookの再構築を速度アップしました。今までは文字通り再構築でしたが、直したい のはDAGから生じる矛盾の修正だったので、トップから再帰で潜って戻りながら評価値など を更新する形にして、再構築分の手間を削減しようという目論見です。が、シングルスレッド でしか動作しないため非常に遅い。最終的に、基本の対称形を一括処理するようにして、 ２手目の分岐単位でスレッドを分割して、何とか２０分から５分に短縮できました。 まだ、スレッド３つしか使えていないので、もうちょっと工夫して８スレッド全部使えるように しようかと思っています。目論みでは２分〜３分くらいまで行けかな。 http://mevius.5ch.net/test/read.cgi/gamedev/1574503798/339
340: 310 [sage] 2020/07/31(金) 00:22:31.35 ID:EPRjv06N >>335 タイルゲームの最善手計算凄いですね。 ５×５とか６×６にしたらどうなるんでしょうね。 http://mevius.5ch.net/test/read.cgi/gamedev/1574503798/340
341: 310 [sage] 2020/08/10(月) 01:12:51.32 ID:ABN1ddg2 bookの再構築は１分５０秒台まで短縮しました。 ３０手読み切りのパブリックドロー候補は９００件超え。 割と淡々と増えているので、ホンマかいなと不安になってきています。 過去にパブリックドローとみなした筋が、パブリックドローを外れた時に、原因となった 着手を追いかけて、間違い箇所探していて、大抵直す事ができるのですが、この新しく 棋譜にした筋の評価値が結構へんてこになっています。Zebraも時々そういう局面が ありますが、結構遭遇します。おそらく過学習の絞り尻が、棋譜に出現していない局面 に押し込められているのだと思います。という訳で貪欲法のロジックを変更して、評価値 が怪しい局面から分岐をさせるように変更。とにかく棋譜を作りたいし、過去に間違えた 筋の訂正にもなるので、これをメインにしてみます。遡りチェックは、諦めて、棋譜の数の 暴力で正解筋を引く方向に変更。 そろそろ合流筋が増えて来たのと、FFOテストの局面が３つ棋譜から生成されたので、 手筋のカバー度は結構上がってきていると思うんだけどなぁ。 ちなみに現在１１８万棋譜。どこかで区切りつけたい気もしてきた。 http://mevius.5ch.net/test/read.cgi/gamedev/1574503798/341
343: 310 [sage] 2020/09/04(金) 16:05:06.49 ID:h5QFISg8 棋譜数の暴力で１３０万棋譜突破。 Book確認用画面の方で手修正を掛けられるようにして、通常の棋譜作成プログラム を動かしながら、おかしなBook値のところから後続の棋譜作成を手作業で指示して 修正がかけられるようにしました。最初は１件単位だったのが、縦深型の貪欲法で チェック掛けられるようになり、処理時間はかかるけど効率よく修正できるようになり ました。 となると、以前からパブリックドローの可能性が否定できないと思っている筋（Zebraで +0〜-1程度の変化）を重点的に調べる事ができるようになりました。調査自体はドロー ではないと確信できるまで、Zebra参考に縦深貪欲法を適用するだけですが、結構な 筋でドローが見つかりました。続いて、既存の幅優先貪欲法と３０手まで遡りチェックで ドロー筋である事を確認。幅優先貪欲法は間違いが多いので、ここで外れた筋はもう １回縦深貪欲法でチェック。これを繰り返して、 http://mevius.5ch.net/test/read.cgi/gamedev/1574503798/343
344: 310 [sage] 2020/09/04(金) 16:15:15.87 ID:h5QFISg8 途中で送信しちゃった。 まあ、要するに、色々棋譜作成していたら、現在ドロー候補が１０００件超えました。 FJTは生きてますが、LOGISTELLOは消えました。F5d6C4g5筋がそこそこ充実。 斜め取りはF5f6E6f4G5d6からE3は消えましたが、F3とD7、もしかしたらC5も候補として浮上。 まだ、間違いがあって消える筋もあり、場合によっては２００件単位でボツという事もありえ ますが、最初は１００件程度から始まった事を思えば、増えたものです。 今はとりあえずリストアップ優先ですが、最後の最後に、ガッツリとチェックの篩にかける つもりです。どれくらい残るかなぁ。 http://mevius.5ch.net/test/read.cgi/gamedev/1574503798/344
345: 310 [sage] 2020/09/10(木) 17:54:29.45 ID:4Zp+kLKC やっちまった。操作ミスで棋譜データ飛ばした。たまたま８月２０日のバックアップと、 現時点でのパブリックドローリストがあったので、現在そこから復旧中。 消えた棋譜は恐らく１０万件以上orz こういうミスが起きそうなのは認識していたし、色々プログラムも整理したいので、また プロジェクト一から作り直しするかなぁ。 http://mevius.5ch.net/test/read.cgi/gamedev/1574503798/345
348: 310 [sage] 2020/10/06(火) 23:13:30.11 ID:RrvANMT6 棋譜件数とパブリックドローリストはほぼ復活。 パブリックドロー件数は、１２００件くらいのところで落ち着きそうな気が してますが、まだしばらく増減があると思います。 ソースも整理して、気になっていたところを直しました。 これでデータ飛ばすリスクはかなり減りました。 ただ、Bookはまだまだスカスカだし、評価値もギザギザです。 棋譜が間違っていると思ったら、評価値（自作もZebraも）が間違っていた というケースも散見され、そろそろBuroさん型の評価関数の限界が見えて きた気がしています。 今ある棋譜を生かして、もっとフィット率が良い評価関数が作れないものか。 とはいえ、NN系は計算が重すぎるし、いまいちモチベーションがわかない。 http://mevius.5ch.net/test/read.cgi/gamedev/1574503798/348
352: 310 [sage] 2020/10/16(金) 00:09:49.89 ID:5RABX7jk やねうら王２０１９のソースを見つけてダウンロードしたけど、やっぱり他人のソースを 見るモチベーションが沸きません（汗。NNUEとかLazySMPとか興味はあるんだけど。 LazySMPは８スレッド以上だと効果が出るそうで、自分の CNNは十分な複雑さがあれば万能近似関数になりうるので、可能性はありますが、 http://mevius.5ch.net/test/read.cgi/gamedev/1574503798/352
355: 310 [sage] 2020/10/19(月) 14:10:40.58 ID:pQ38Gazt 書き込み途中で送信しちゃった直後から、BBQになってます。 とりあえず仕事場からカキコ。 http://mevius.5ch.net/test/read.cgi/gamedev/1574503798/355
ﾒﾓ帳
(0/65535文字)
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.032s