【オセロ,将棋】ボードゲーム Part3【囲碁,War】 (636ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
86: 535 [sage] 2020/02/01(土) 01:57:04.18 ID:TrLaB+Vx(1/3) AAS
もしかして現局面の対称性を考えるんじゃなくて着手後の対称性を考えるとわかるのだろうか？
151: 535 [sage] 2020/03/04(水) 21:14:38.18 ID:Q7ItuMwb(4/7) AAS
うーん、石がくっついているか離れているか標準偏差のようなものを出して学習パラメータに渡すとか
245: 535 [sage] 2020/04/22(水) 18:48:41.18 ID:mXEm0GNy(1/4) AAS
強くなってませんね。
完全なランダムでないにせよ。
もう少し様子見します。
298: 310 [sage] 2020/05/18(月) 23:50:13.18 ID:lyHQ6R5E(3/3) AAS
DBの件…
確定探索の時にはメモリーに確定分だけおいとくと考えていましたが、
今件数確認したらおよそ２／３は確定分として確保しなきゃならない
事に気づきました（汗
棋譜作成時はメモリーでやるしかないかも。
１棋譜更新でのDAG問題回避はやりたいかな。
Book再構築にだいたい２０分くらいかかる。
DAG回避で１棋譜分更新するのが１秒として１０００棋譜追加でおよそ１６分。
これ以下の時間で済むならやる価値ありそう。
314: 310 [sage] 2020/06/05(金) 22:28:59.18 ID:TnykYlJh(1) AAS
藤井７段凄かったね。今年中に８段行っちゃうんじゃないかと思った。
エラーの原因を冷静に見直したところ、どこをどう変えたか覚えていないレベルの
ちょっとした修正を加えたところからドツボって、修正するたびに更にバグを仕込んで
いたような。結局、元々のプログラムに戻して、速度も復旧しました。むむむ。
こういうのがあるからから、終盤探索に手を入れたくないorz
Bookの遡り修正ですが…行き詰っています。
Kyoto Cabinetはやはり単一キーしか扱えず。
メモリー上に逆引きDBを作ると、たぶんBookよりサイズが大きくなるためメモリーにおけない。
しばし悩み中。
息抜きで、棋譜作成のロジックをちょこっと修正。
同じような評価値が並んでいたり、最善手より評価値が良くなる分岐について、今までは
見つけて気になったところだけ手で追加していましたが、適度なペースで見つけて自動的
に追加する様にしました。
319: 535 [sage] 2020/06/18(木) 19:28:02.18 ID:i+asT3Px(1) AAS
ライフゲーム囲碁でモンテカルロ木探索の訪問回数をdnnの教師データにするのやり始めました。
今教師データを収集してるところです。
509: 535 [sage] 2021/04/24(土) 17:53:34.18 ID:XMffmkc0(1) AAS
テスト書くモチベーションが低下し始めたｗｗｗ
さすがに根性なさすぎと思うが自分じゃどうしようもないｗ
528: 310 [sage] 2021/05/14(金) 00:24:09.18 ID:UCKlrk0/(1) AAS
sqlite3でエラーになる原因がほぼ特定できて、エラー処理を全面見直しました。
・棋譜追加処理のトランザクションのCOMMITの際にBUSY状態の継続を検出した時は、
ロールバックして再度更新をやり直すという形に変更。棋譜とBOOKの整合性を保つため
にも、速度面でもトランザクションは必須。
・SQL文の事前コンパイルであるprepareでもBUSYが発生する事がわかったので、エラー
処理を行ってBUSY検出して成功するまで繰り返す事で、prepareの完了を保証する
これらにより２プロセスまでのデッドロックは何度も検出してロールバックしてやり直しが
完遂するのが確認できています。
が、３つ以上の棋譜作成プロセスを同時に動かした時に、たまたま棋譜追加のタイミングが
３つ揃うと三すくみ的なデッドロック的状況になってしまうようで、ロールバックしてリトライが
３プロセスで順番に発生して無限ループに的に繰り返される状態になってしまう…。
２プロセスでは起きた事は無いのですが、３つだと起きる模様。
まだまだsqlite3の理解が足りないようです。
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 1.072s*