【オセロ,将棋】ボードゲーム Part3【囲碁,War】 (636ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
468(1): 310 2021/03/11(木)12:23 ID:j4c7ib4A(1) AAS
４か所ほど改造したくなってきました。
ソースの混乱を避けるためまた新ソリューションで作ろうかと思っていますが、
例のFFO棋譜で生じたBookのダメージ箇所を見つけて直す作業がかなり時間が
かかりそうです。削除しちゃえば早かったんだけど、活かして訂正かける方向に
しちゃったので、後に引けない。
どうしよう。
あと、NTESTのソース見つけた（今頃）。
NTESTの引き分けBOOKは公開されていないらしい。残念。
472: 310 2021/03/14(日)16:39 ID:Gv94SmBp(1) AAS
>>470
ありがと。それで良いんだ。
早速ダウンロードしました。
487: 310 2021/04/01(木)22:39 ID:oZ+Ylys+(1) AAS
色々改造中。たくさん改造するのでバージョン２にして全面見直し中。
棋譜２１０万件を超えて、メモリーがいよいよヤバいので、棋譜へのランダムアクセスは
色々工夫してファイルシステム任せ、BookはSQLite化して外だしを進めています。移植し
ながらの修正がまだ完了していないので、テストどころかコンパイルすらしてません（汗
片や、現行のバージョンでは、棋譜作成のロジックを修正して、結構効率よく要チェック
できるようになりましたが…こちらの処理を優先しているのも、なかなかコンパイルに至ら
ない原因だったりしますorz
489: 310 2021/04/04(日)20:24 ID:8wrL8vAJ(1) AAS
>>488
相変わらず、ソースは書いたけどコンパイルしていない状態ですｗ
KYOTO CABINETから調べ始めてましたが、気が付いたらKYOTO CABINETは次バージョン
になってて。検索してたらNoSQLという単語を知って、その系統を色々調べて…。
所詮、Unordered Mapをメモリー外でしたいだけなので、NoSQLで良いかなと思ったのですが、
SQLiteならファイル単位くらいの粗さで複数プロセス書き込み管理ができるようなので、
選択してみました。SQLiteならやりたいことができて、やりたくない事はやらなくて良さそうなの
が良い感じ。
494: 310 2021/04/13(火)01:39 ID:DfQCUB9I(1) AAS
SQLite化ができたので移行してみましたが、あちこちで問題が（汗
１．評価関数の形を変えてゼロリセットしたが、まだ学習回数が足りず探索が遅い
４日くらい回し続けなきゃならないかも。
２．uｎｏｒｄｅｒｅｄ＿ｍａｐの形のままSQLに置き換えたら、激遅箇所ができた。
ランダムアクセス減らす様に修正しているけど、何か所か妥協が必要かも。。
３．並列処理してもDB更新がボトルネックになってシングル動作並のCPU使用率。
諦めるかも。
４．Windowsが不安定になるときがある。メモリーリークかも。
というわけで、しばらく棋譜作成停止して、悩む事になりそうです。
495: 310 2021/04/14(水)20:36 ID:RDUQmrym(1) AAS
いくつか解消。
SQL周りは何とかなりそうだけど、排他周りがまだよくわからないかも。
探索速度の低下は、SQLではなく評価関数の修正が原因の模様。
今夜修正する予定。また再学習だなぁ。
そのほかの劇遅箇所は、修正しつつあります。
501: 310 2021/04/19(月)00:35 ID:MoZY+/Mw(1/2) AAS
評価関数問題は回避しました。
でも、SQliteでBook探索という一番使うところでSQLITE_MISUSEエラーが出て、
行き詰ってます（汗。よりによって、完全読み切り処理の中で起きています。
別スレッドから同じDBポインタを引数にして…という説明があるので、DB接続を分けた
のですが直らん。
テストでparallel_for内でマルチスレッド化して使ってみましたが、普通に動作する。
SQL文のtypoでもこのエラーが出るのを見つけたのですが、他の場所では動作するので
typoとは思えない。
何か他に原因があるのだろうか…
502: 310 2021/04/19(月)20:51 ID:MoZY+/Mw(2/2) AAS
原因判明。prepareのところでBUSYとなっていたのに、待っていなかったのが原因でした。
というわけで待つ様に偏向したところ、めっちゃ速度低下。そもそも探索１回あたりの処理が
軽すぎて、DBアクセスの準備が間に合わなくなっていたのが原因みたいです。
BUSYを待つようにしたら滅茶苦茶速度低下。並列化の意味なしパターンです。読み切り
処理で過去に読み切り済のBookを活用するための処理でBookを見ていましたが、初段
限定使用に改造して回避。
読み切り処理のテスト時にバグでBookに矛盾が生じてしまったので、矛盾解消の処理の
テスト始めたら、ここもバグってる感じ。毎回再構築した方が早いかも。
まだ先は長そうというか、長期間楽しめそうです（汗
503: 310 2021/04/20(火)00:26 ID:APnaWVT/(1) AAS
Book矛盾解消もBook再構築も、どちらもBUSY地獄になりました。
一旦BUSYになったら無限ループ待ち。COMMITしてみたり試したけどダメ。
Book再構築は昔は動いていたはずなのですが、DB接続を関数ごとに分離した
ために動かなくなった感じなのかなぁ。泥縄で試していくしかないですね（汗
504: 310 2021/04/22(木)02:18 ID:7rHLmRsN(1) AAS
BUSY問題解消。やっぱり更新Transaction内では参照系を別のDB接続でやっては
ダメだった模様です。
そのほか、いわゆる単体テストレベルは一通りチェックしました。後は全部繋げて
どうかという話になります。処理時間が長くて使えないものも出てきそうですが、
移行できる算段はできたかなぁ。
プログラム書いている裏で、旧版を動かしっぱなしなので、切り替えるタイミング
がなかなか作れなかったりして。
507: 310 2021/04/23(金)22:22 ID:SZ8gbg4M(1) AAS
完全移行前のチャンスだからと、今更ながらに読み切り処理の見直し。
少し前にようやくKiller Moveが何なのかわかったので、組み込んでみるも…
速度が低下してしまったorz
昔試した偶数理論もダメだったし、コーディングが悪いのかなぁ。
512: 310 2021/04/28(水)20:08 ID:z1AZ6yC/(1) AAS
そこそこ移行できて、あとは抽出処理の速度だけだと思っていたら、棋譜とBookの
確定読み切り深さの情報に不整合が発生してました。棋譜上は２６手目まで読み切り
になっているのにBookだとまだ読み切りになっていないみたいな。
棋譜からBookを作っているので、棋譜が正のはずなんだけど、同じスコアとなる分岐
となる棋譜の確定読み切り深さを、深い方に揃える処理がバグっていたのかも…
とりあえずおかしいのは棋譜の深さだと決めつけてヨタプロ書いてBookから棋譜に
戻してますが、ヨタプロが間違えていたりで、結構ゴタゴタしてます。
しかもヨタプロに限って、トランザクション中におそらくBUSYで固まるというトラブルも。
というわけで、まだ安定再稼働には至っていませんｏｒｚ
524: 310 2021/05/08(土)01:40 ID:Rn4e+nua(1) AAS
主要な棋譜作成処理は動作確認・速度問題解消できたので、とりあえずsqlite3版を
本チャンに移行して、ぼちぼち残った部分を直しています。
メモリーがスカスカになって気持ちいい。
528: 310 2021/05/14(金)00:24 ID:UCKlrk0/(1) AAS
sqlite3でエラーになる原因がほぼ特定できて、エラー処理を全面見直しました。
・棋譜追加処理のトランザクションのCOMMITの際にBUSY状態の継続を検出した時は、
ロールバックして再度更新をやり直すという形に変更。棋譜とBOOKの整合性を保つため
にも、速度面でもトランザクションは必須。
・SQL文の事前コンパイルであるprepareでもBUSYが発生する事がわかったので、エラー
処理を行ってBUSY検出して成功するまで繰り返す事で、prepareの完了を保証する
これらにより２プロセスまでのデッドロックは何度も検出してロールバックしてやり直しが
完遂するのが確認できています。
が、３つ以上の棋譜作成プロセスを同時に動かした時に、たまたま棋譜追加のタイミングが
３つ揃うと三すくみ的なデッドロック的状況になってしまうようで、ロールバックしてリトライが
３プロセスで順番に発生して無限ループに的に繰り返される状態になってしまう…。
２プロセスでは起きた事は無いのですが、３つだと起きる模様。
まだまだsqlite3の理解が足りないようです。
532: 310 2021/05/17(月)00:32 ID:eljQUmfc(1) AAS
よびのりたくみ先生のYoutubeに、谷合四段が出演して、自作将棋AIでよびのり先生
（おそらく有段レベル）と対局した顛末がアップされていました。
ライブラリ活用して２日で作ったそうです（驚）が、見事に快勝されていました。
独自部分はDLで自然言語処理向けのネットワークを使ってみたとの事で、探索部は
MCTSで動作しているようです。おそらく、ポリシーネットに使用しているのかと思います。
流石、東大大学院で自動運転技術の研究している異色の棋士ですね。
で、今更ながらにライブラリの存在に思い至りました（汗。盤面とか指し手生成とか、その手
の処理を今から作っても車輪の再発明にしかならないし、自分が考えていた独自性に至る
手前の障害物となっていたので、時間ができたら調べてみようかなぁと思います。
また、自然言語処理は今まで関心がわかなかったのですが、ポリシーネットに使うという
アイデアに惹かれています。多分、手筋の学習に強いのかなと。
当分オセロにかかりきりですが、少しづつ勉強してみようかなと思います。
とかいって、また途中で放置しちゃうのかなぁ。
オセロのAIだって、いつかやろうと思ってから２５年放置していたし（笑）
538: 310 2021/06/21(月)22:52 ID:uctn9NI1(1) AAS
だらだらと棋譜を作り続けています。
２５０万件突破したけど、チェック対象の局面が大量に残っていて、また偽引き分け筋を
発見するために棋譜を作成する処理も組んでいて、まだまだ棋譜がスカスカな感じです。
５００万件までやるとまだ何年かかかるのかなぁ（笑えない）
sqlite化して重くて使えなくなったいくつかの処理（棋譜内の矛盾チェックなど）については、
まったく進展せず、使用頻度を下げる事で逃げています。
上記の様に、引き分け筋の正当性チェックやら、引き分けから除外された局面が本当に
引き分けじゃないかのチェック対象がたくさんあって、３０手目以後確定引き分け筋の
件数は１６００〜２４００件の間を行ったり来たりで、現在は２０００件くらいです。
540: 310 2021/08/06(金)23:32 ID:WgZOTDfh(1) AAS
ご無沙汰です。535さんが書き込んだ日に書こうとしたら巻き添え規制でした
棋譜数２７６万件超えました。
ドロー筋は結構入り繰りありますが２２００〜２４００件くらいで推移しています。
久々に学習しようとしたら連続領域確保できないと怒られて、慌てて速度低下
覚悟の中間vector廃止しました。最後の手段はファイル掃き出しですが、その
ためにはオンファイルのソートユーティリティが必要です。
そのうち探します。
将棋については、頭の中で新機軸の方向性を思い描いていますが、未だに
盤面のデータ構造を決められずにいます。既存の奴を見て真似すれば良いの
ですが、やはり他人のソースを見るのに耐えられない状態ですorz
542: 310 2021/09/16(木)19:51 ID:ZzfQmSXn(1) AAS
久々です。棋譜２９７万件。あと少しで３００万件。
そろそろドロー筋も出尽くしたかなと思って、既知のドロー筋が本当にドローなのか
重点チェックする処理を動かしていますが、凄く時間がかかるのと…。
ドローの可能性がある筋が更に１０００件くらい増えてしまいました。
多分かなりの数が脱落していくと思いますが、予想外でした。
そろそろ終活始めないといつまで経っても終われないというのにorz
545: 310 2021/10/04(月)03:16 ID:OVA3Pvl4(1) AAS
棋譜３０５万件。まだまだ落ち着いてくれません。
久々に評価関数の学習しようとしたらまたしても連続領域確保できませんエラー。
仕方無いので教師データをバイナリファイルに外だしして準備をすることにしましたが、
並び順のshuffleでスワップ発生しまくって進まないorz
シャッフルしないと過学習が起きやすくなるので、とりあえずバイナリファイル上で
シャッフルしてみるつもり。ダメなら２分割とか考えないと。
今夜はBookの再構築までにしておきます。
メモリーが倍あれば、まだしばらく大丈夫なんだけどなぁ。
549: 310 2021/10/21(木)09:52 ID:1G6/45ua(1) AAS
無限時間を相手にした時に本来の確率通りになるのは自明ですね。
短い時間での試行だと、階段状になるので解析は難しいかも知れません。直観ではAが
勝った時には追加時間が入るようなものなのでAが有利になりそうではありますよね。
面倒なので勝手に問題を書き換えてみます。
「糞粘りするソフトAが有利にならず真の強弱を判定するためには、どのくらいの時間を
かけて対戦させ計測すればよいのか。」
時間を考慮に入れずに試行回数を決めて計測すれば解決する問題な気がします（汗
また、真の強弱を調べる場合に必要な試行回数は、母集団の推定ってやつなので、どこか
探せば出てくると思います。時間で区切る場合は、その試行回数を実行した時の「経過時間
の分布」ととらえる事もできますので、ここで問題を分割して、どのくらい試行時間を掛ければ
十分な試行回数が得られるのか問題ととらえなおすことができると思います。
実際の計算は…
この定理に関して、私は真に驚くべき証明を見つけたが、この余白はそれを書くには狭すぎる（笑）
553: 310 2021/10/27(水)22:24 ID:EdJdOKHZ(1/2) AAS
自明というほどの証明は僕にはありません（汗
開幕１９連勝しちゃうとかなり期待しますよね。
やはり強さを確定するためにはそれなりの試行回数が必要という事なんでしょう。
開幕２９連勝したお方は凄い事になってますし。
タイルゲームまたやってみようかな。
MCTSと親和性高そうだし。
min-Max系は自分の力では、これ以上高速化できない気がしています。
554: 310 2021/10/27(水)22:32 ID:EdJdOKHZ(2/2) AAS
オセロの方は、評価関数は自己対局用にそこそこの奴ができればいいやと、Book構築
の方に力を入れています。ロジックで間違っていそうな筋を分岐させてみたり、ドローっ
ぽい棋譜はかなり厳しめに分岐させてチェックしてみたり、目視で怪しいところ見つけたら
手動で分岐させてみたり。でも、なんか賽の河原状態に陥っています。どこかで安定しだ
すと期待していたら逆で、どんどん宿題が積み上がっていく感じです。
気分転換に、以前一回諦めた、読み切り処理で正解分岐が複数あって、既に確定済の
筋以外の手を選ぶロジックを見直していました。半年〜１年くらい放置していた奴です。
今見たら何を悩んでいたのかというくらい、当時の問題があっさり解決しました。まあ、
読み切り速度が２０〜３０％遅くなってしまうのですが、分岐を作れるので教師データに
は良いかなと。
評価関数の学習は、またパンクしてしまったので、バイナリファイル上でシャッフルする
処理を書きましたが、処理時間が怖くてまだ試していません。いっそ、もう一度評価関数
をステージ分割してしまった方が良いのではないかと思い始めています。
やればやるほどZebraの評価関数の正確さに頭が下がる思いです。
556: 310 2021/10/28(木)20:34 ID:tAZRxFew(1) AAS
ルールを理解して、盤面の内部表現と勝敗判定を考え始めたところで
うっちゃってますので、まだ何もしていません（汗
558: 310 2021/10/30(土)22:23 ID:KcRkQNBB(1) AAS
パソコンうらやましす。
メモリー１２８Gで３２スレッドくらい欲しいなぁ。
評価関数は結局ステージ分割にしています。が、学習途中でEigenがコケる。
なんとなくステージ単位での件数オーバーっぽいので、更にステージ分割を
細かくしてみていますが、今日１日の作業がパーで、また丸１日くらいかかる
のかなと。
まだ原因特定できた訳ではないし、件数が大丈夫かも判然としないので、また
こけないか心配ではあります。
561: 310 2021/10/31(日)23:27 ID:wMiG8knd(1) AAS
GPUにはそんな相性問題があるのですか…
色々調べてやらないとダメですね。
コケる原因と思われるところを見つけました。
色々やった挙句、矛盾した盤面がありそうだという事になって、調べたらビンゴ。
これからヨタプロ書いて、問題の棋譜を見つけて削除するつもり。
デバッグ中にさらに色々評価関数のを見つけてしまいました。
評価関数って多少バグってても、それっぽく学習しちゃうんだよねorz。
562: 310 2021/11/01(月)07:58 ID:dM9ZkTyW(1/2) AAS
多分解決。
棋譜の問題じゃなくてBook構築時の問題でした。
４０手目までBook登録しているのですが、４０手目以前に全滅した時の
終局判定が漏れていて、無いはずの矛盾した後続の盤面を作ってました。
普段は全く影響でないのですが、Bookまとめて読みだして処理をかける時
だけ出てくる奴です。
昨夜学習開始しましたが、まだ問題箇所を全部通過したわけではありません。
が、たぶん大丈夫だと思う。昼過ぎにはわかるはず。
Book再構築に１時間と、学習に丸１日以上かな。
明日の朝までには第一陣の学習が終わるかな？
まだ学習回数不足で評価値が安定していなので、バグが快勝していても、
しばらくは時間がかかりそうです。
564: 310 2021/11/01(月)23:01 ID:dM9ZkTyW(2/2) AAS
とりあえず問題箇所全クリアは確認できました。
エポック１０回で１日半かかるのが面倒。
せめて５０エポックくらいしたい。
今週は学習週刊になりそう。
568: 310 2021/11/05(金)20:47 ID:TX9UwcXB(1) AAS
心の迷いから、途中まで学習して止めて、ちょこっと修正してを繰り返してますのでまったく
学習が進んでいません。Bookチェック用コンソールでの浅い探索がびっくりするほど遅く
なってしまい、原因を探したりなんやかんややっていたのが迷いの原因です。
最終的にステージ分割を止めて、８対称を４対称に落として教師データを半分にしたりして
学習再開しました。１エポック１時間半でとりあえず３０回学習させてみるという事で仕上がり
は日曜日の夕方〜夜の予定。まるまる１週間パーになりました。
もともと件数オーバーでメモリ溢れ始めたのは、４対称だったのを８対称に変えてからだった
ような気がしてきました。また、ステージ分割も、昔１回トライして、速度低下が酷くてやめ
ちゃった事があったような記憶もうっすら残っています。なんつーか、こういう類の手戻りが多いorz
ただ、探索がステージ分割だけで遅くなるとも思えないです。浅い探索は単純なαβで、
オーダリングはヒューリスティックスオンリーだし、ProbCutもしていないです。分割により
評価値ゼロとなる末端が多くてβカットが減っているのかなと思っています。間違っていて
も値が入っていればβカットはされますから。
棋譜作成にランダム要素加えて、悪手変化後の局面もたくさん学習させないといかんのかな。
570: 310 2021/11/06(土)21:44 ID:zi779w0E(1) AAS
なんか評価値がおかしかったのでチェックしていたら、末端ノードでの評価値の差分計算
がおかしくなっていた。もともとちゃんと動いていた箇所なので、何故変わっていたのか謎。
これも激遅の原因の一つではあると思うけど、まだ遅いんだよなぁ。
575: 310 2021/11/15(月)00:36 ID:hveDHfQn(1) AAS
藤井先生はAIだと思うようになりました（汗
新人王とった伊藤匠４段もかなり強いね。これから期待です。
評価関数学習し始めたら、オプティマイザーでSMORMS3は学習開始直後の集束は
滅茶苦茶早いんだけど、汎化が上手く行かないので、momentumと併用していたのを
思い出して、今はｍｏｍｅｎｔｕｍで毎晩６エポックづつ学習させてます。結構よくなって
きたけど、まだまだかなぁ。このまま続けたら速さは戻りそうですが…
それならステージ分割してまた学習やり直しても良いのではないかと思ってみても
良いのかなという気がし始めています（汗
途中、棋譜をほぼ全部飛ばしそうなバグ出してました。
たまたま戻せましたが、危ない危ない。
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.034s