【オセロ,将棋】ボードゲーム Part3【囲碁,War】 (636ﾚｽ)
【オセロ,将棋】ボードゲーム Part3【囲碁,War】 http://mevius.5ch.net/test/read.cgi/gamedev/1574503798/
上
下
前次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
抽出解除
ﾚｽ栞
86: 535 [sage] 2020/02/01(土) 01:57:04.18 ID:TrLaB+Vx もしかして現局面の対称性を考えるんじゃなくて着手後の対称性を考えるとわかるのだろうか？ http://mevius.5ch.net/test/read.cgi/gamedev/1574503798/86
151: 535 [sage] 2020/03/04(水) 21:14:38.18 ID:Q7ItuMwb うーん、石がくっついているか離れているか標準偏差のようなものを出して学習パラメータに渡すとか http://mevius.5ch.net/test/read.cgi/gamedev/1574503798/151
245: 535 [sage] 2020/04/22(水) 18:48:41.18 ID:mXEm0GNy 強くなってませんね。 完全なランダムでないにせよ。 もう少し様子見します。 http://mevius.5ch.net/test/read.cgi/gamedev/1574503798/245
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
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
319: 535 [sage] 2020/06/18(木) 19:28:02.18 ID:i+asT3Px ライフゲーム囲碁でモンテカルロ木探索の訪問回数をdnnの教師データにするのやり始めました。 今教師データを収集してるところです。 http://mevius.5ch.net/test/read.cgi/gamedev/1574503798/319
509: 535 [sage] 2021/04/24(土) 17:53:34.18 ID:XMffmkc0 テスト書くモチベーションが低下し始めたｗｗｗ さすがに根性なさすぎと思うが自分じゃどうしようもないｗ http://mevius.5ch.net/test/read.cgi/gamedev/1574503798/509
528: 310 [sage] 2021/05/14(金) 00:24:09.18 ID:UCKlrk0/ sqlite3でエラーになる原因がほぼ特定できて、エラー処理を全面見直しました。 ・棋譜追加処理のトランザクションのCOMMITの際にBUSY状態の継続を検出した時は、 ロールバックして再度更新をやり直すという形に変更。棋譜とBOOKの整合性を保つため にも、速度面でもトランザクションは必須。 ・SQL文の事前コンパイルであるprepareでもBUSYが発生する事がわかったので、エラー 処理を行ってBUSY検出して成功するまで繰り返す事で、prepareの完了を保証する これらにより２プロセスまでのデッドロックは何度も検出してロールバックしてやり直しが 完遂するのが確認できています。 が、３つ以上の棋譜作成プロセスを同時に動かした時に、たまたま棋譜追加のタイミングが ３つ揃うと三すくみ的なデッドロック的状況になってしまうようで、ロールバックしてリトライが ３プロセスで順番に発生して無限ループに的に繰り返される状態になってしまう…。 ２プロセスでは起きた事は無いのですが、３つだと起きる模様。 まだまだsqlite3の理解が足りないようです。 http://mevius.5ch.net/test/read.cgi/gamedev/1574503798/528
ﾒﾓ帳
(0/65535文字)
上
下
前次
1-
新
書
関
写
板
覧
索
設
栞
歴
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.021s