【オセロ,将棋】ボードゲーム Part3【囲碁,War】 (636レス)
1-
抽出解除 レス栞

310
(126): 310 [sage] 2020/05/29(金) 20:25:58.86 ID:wYh6jGrP(3/3) AAS
orderingの中でパス処理をしていたのでmobility関数を呼びまくっているのが遅い原因
ではないかと思い、パスの処理の仕方を変えて、パスも1手とするように変更したところ、
15〜20%の速度低下まで戻りました。他にも、つられてバグが発覚したので修正。

かなりのレアケースでしか発生しないバグですが、今まで自信満々で完全読み切りは
間違っていないと思っていましたが、なんか自信なくなった。

中盤探索も同様に修正したら、浅い探索の読み筋が変わったみたいで、少しは精度が
良くなるのかなぁと期待しています。
296: 310 [sage] 2020/05/18(月) 21:57:15.59 ID:lyHQ6R5E(1/3) AAS
Hash関数変更
DBのハッシュキーの効率が悪かったので、ちょっと考えてみた。
今まではshuffle_epi8でバイト単位シャッフルしていたのを、BMIのpextでビット単位の
シャッフルと、rotateしたものを、xorでまとめていく方法。以前よりは、ちょっと良くなった
気がする。

何をもってよくなったかの指標が欲しくなり、ネットを探索したけど、数値指標みたいなの
は見つからない。確率論の誕生日問題の反対みたいな状況なのでしばらく考えてみる。
要するに、1万人くらいの生徒がいる学校で、誰一人誕生日ではない日が何%くらい存在
するのかという類の問題です。

また、そう考えてみると、現状では直観よりかなり未使用キーが多い気がしています。
xorを繰り返してビットのオンオフをすると、いずれ立っているビット数が32個を平均と
した正規分布(二項分布)になって、一様分布にならないのではないかという疑念が。
正規分布だと、中央に近いところは重複しやすく、立っているビット数が0とか64とか
の出現確率が下がる事になります。xor繰り返すと正規分布に本当に近づいていくのか、
ちょっと検証してみたい。
297: 310 [sage] 2020/05/18(月) 22:17:24.43 ID:lyHQ6R5E(2/3) AAS
DBの件
たぶんあるだろうとネットで検索してみたら、Kyoto Cabinetなるキーバリュー型の
簡易DBライブラリがある事が判明。ほかにもLevelDBとか、何種類かあるみたい。
RDB使うまでもないけど、データ量が多いとメモリーだとリソース勿体ないみたいな。
やはりみんな考える事は一緒だなと。せっかくなので導入の方向で検討。

DBの速度問題
また、おそらく1棋譜単位でのBook更新は速度的に問題ないのですが、DAG(合流)
時に、棋譜外の合流元の方の更新がされないという問題があり、学習前に一括で
再構築しています。この一括更新が件数の関係ですごく時間がかかる事が問題です。

一応、1棋譜単位で更新した時に、DAG分もちゃんと処理するロジックを検討中です。
バグさえなければ速度問題はかなり解消できるはず。とはいえ、何回もループを回す
処理となるため、速度に自信なし。
298: 310 [sage] 2020/05/18(月) 23:50:13.18 ID:lyHQ6R5E(3/3) AAS
DBの件…
確定探索の時にはメモリーに確定分だけおいとくと考えていましたが、
今件数確認したらおよそ2/3は確定分として確保しなきゃならない
事に気づきました(汗

棋譜作成時はメモリーでやるしかないかも。

1棋譜更新でのDAG問題回避はやりたいかな。
Book再構築にだいたい20分くらいかかる。
DAG回避で1棋譜分更新するのが1秒として1000棋譜追加でおよそ16分。
これ以下の時間で済むならやる価値ありそう。
299: 310 [sage] 2020/05/20(水) 01:15:22.70 ID:Xgj8E+2H(1/2) AAS
久々に完全読み切りでバグ発生。

ProbCutを広げながらmtd(f)している時に、どうもパス絡みで発生しているっぽい。
ProbCutによるIterative Wideningを止めたらちゃんと読み切る。

まあ、置換表絡みなんだとは思うけど、事例が少なすぎて(数か月に1回程度)、
前の記録消しちゃったので、とりあえず記録を残し、絆創膏当てて続行。

気が向いたらデバッグしてみる。可能性があるところはなんとなくわかっている
つもりだけど。

Book更新時のDAG回避は、かなり悩ましい。というか頭がこんがらがる。
未使用Hashの期待値計算も頭が未だにこんがらがってます。。
302: 310 [sage] 2020/05/20(水) 17:28:20.84 ID:Xgj8E+2H(2/2) AAS
Hash関数の効率判断基準できました。

同じキーにデータが8つくらい入っているようなものもあり、それが適正かどうか
判断できなくてゴチャゴチャしていましたが、昨夜しれっと書いたように未使用キー
の数の期待値に着目したら簡単でした。

キーサイズと、データ件数からExcelなどで簡単に計算できます。

3件程度調べてみましたが、理想的な一様ランダム値で生じる未使用キー数の
期待値との差は0.1%未満で、このHash関数も一様ランダム化するものと言って
良いレベルでした。

逆に言えば、自分の典型的な使用方法だと20〜30%のキーが未使用になる
という事のようです。これはこれで…。
304: 310 [sage] 2020/05/21(木) 00:46:28.65 ID:ahADKaci(1) AAS
Hash値、1件2件…と期待値出そうと思ったら、なんとなく昔の記憶が戻ってきて、
0件の時は不要だけど、こちらではPとかCとかが必要になるような気がしてきた。
確率の勉強するかな。

ZDDちらっと見てみたけど、ちょっと目的と違うような感じがしている。
本買ってみるけど。

脱線はこれくらいにして、DAG考慮したBook更新に戻ろう。
308: 310 [sage] 2020/05/29(金) 00:49:53.42 ID:wYh6jGrP(1/3) AAS
DAG時のBook更新の件、めっちゃ悩み中。
普通にやったら1件更新に14秒とかかかって使い物にならない。
逆引きDBを作ろうかと思うのだけど、結構なサイズになるので、それこそメモリーに
置きたくない。形としてはunordered_multimapになるんだけど、Kyoto Cabinetが重複
キーを許すのか英文読まなきゃならないので止まってる。

そうこうするうちに完全読み切りのバグがまた発生して、事例が3件になったので、
調査開始。2か所間違いを発見。一つ目はケアレスミス。

2つ目は最善手の直後にパスが来るケース。置換表登録はパス後、オーダリングなどで
読む時はパス前の盤面になっていた。これで値が狂う理由がいまいち理解できないの
だけど、修正したら正しい答えが出るようになった。パスの処理は本当に鬼門。

たぶんバグは取れたけど、50%くらい速度低下。どこかにまだバグがありそう。
309: 310 [sage] 2020/05/29(金) 00:56:37.17 ID:wYh6jGrP(2/3) AAS
速度低下は50%どころではなかった…150〜200%だorz
312: 310 [sage] 2020/05/31(日) 10:02:44.30 ID:/CnVYfEH(1) AAS
またエラーが…

なんとなく記憶をたどっていくと、初段で並列処理してMap-Reduceすると、βカットの関係で
評価値は合っていても、ordering次第で間違った手を返す事を思い出しました。
で、たまたま回避策となっていた処理を>>201
201(1): 310 [sage] 2020/03/31(火) 00:30:27.16 ID:1mhY2vrp(1) AAS
見直し版で、遡りチェックで無駄な処理を見つけて直しました。
更に速度アップして、トータル50%強の速度アップとなりました。
まだ探索自体の速度は上がってませんが、まだ無駄があったとは。
で外してしまったのではないかと。

並列探索だと本質的に回避できない気がするので、初段を順次処理に変更。残り空きマス
26での平均処理時間。一時は20〜25秒くらいまで来ていたのが、30秒程度に悪化orz
314: 310 [sage] 2020/06/05(金) 22:28:59.18 ID:TnykYlJh(1) AAS
藤井7段凄かったね。今年中に8段行っちゃうんじゃないかと思った。

エラーの原因を冷静に見直したところ、どこをどう変えたか覚えていないレベルの
ちょっとした修正を加えたところからドツボって、修正するたびに更にバグを仕込んで
いたような。結局、元々のプログラムに戻して、速度も復旧しました。むむむ。
こういうのがあるからから、終盤探索に手を入れたくないorz

Bookの遡り修正ですが…行き詰っています。
Kyoto Cabinetはやはり単一キーしか扱えず。
メモリー上に逆引きDBを作ると、たぶんBookよりサイズが大きくなるためメモリーにおけない。
しばし悩み中。

息抜きで、棋譜作成のロジックをちょこっと修正。
同じような評価値が並んでいたり、最善手より評価値が良くなる分岐について、今までは
見つけて気になったところだけ手で追加していましたが、適度なペースで見つけて自動的
に追加する様にしました。
316: 310 [sage] 2020/06/15(月) 23:12:30.86 ID:r41RfhWg(1) AAS
DB化、未だに方法が見いだせずストップしてます。
パブリックドロー臭いのにそうじゃない筋を手動で修正して、20件ほどもとに戻った。

その間に、棋譜が100万件突破しました。
が、Book眺めていると、まだまだ間違い多い。
Zebraも結構間違えているけどね。
326: 310 [sage] 2020/07/03(金) 01:33:21.30 ID:ULg6SDrD(1/2) AAS
相変わらず棋譜作成しながら評価関数学習を続けています。ようやく100万件突破。
推定パブリックドローは大体700件くらいで増えたり減ったりしています。
対称形や合流も重複させていますので、重複除くと400件くらいかなぁ。

終盤は比較的多数の分岐を試しているのですが、序中盤の分岐が不足していて、
棋譜が偏っているような気がしてきたので、棋譜作成のロジックを大幅に変更して
序中盤の分岐が多くなるように。また、評価値とBook値が大きく違う分岐を再検証
するようにしてみました。これで、抜けている筋がだいぶ拾えるようになると期待。

棋譜作成中に暇な時間が多いので、試しにZebraと対戦。Zebraはランダムに
パブリックドロー筋から外れる様にできているようですが、外れたら勝てるはずが、
なかなか勝てない。Zebra26手読み、こちらは時間の都合で20手読みくらいなので
仕方が無いのですが、それにしてもBook外れた時の評価関数の精度が悪いという事に。
あと、やはり中盤探索の速度に大きな差があり、とても26手読みなどできない。

むむむ。
327: 310 [sage] 2020/07/03(金) 01:35:54.46 ID:ULg6SDrD(2/2) AAS
つか、藤井先生強すぎ。
1回勝負なら時々一発入るけど、番勝負で勝ち越せる人いないんじゃないかな。
竜王戦勝ち進んで、豊島竜王名人との番勝負が見てみたい。
331: 310 [sage] 2020/07/11(土) 00:47:07.96 ID:UjRsM2rb(1) AAS
残念だったね<F7先生。相当疲れているんじゃないかな。まだ連戦続くので心配。

こちらは棋譜じゃんじゃか追加中。もう逆順探索で正確さを高めるなんて言ってられない。
いちいち遡りチェックするより、分岐を増やしてしまった方が早い気がしてきた。

で、Zebraと対戦させると、まだまだ穴だらけ。Zebraがわざとパブリックドローから外した
ところからが本番の対局となるのですが、そこから10〜20手の間に2回くらい間違えて
逆転される感じ。逆にZebraがほとんど間違えていない事に驚いています。評価値は怪しい
ところもあるけど、選択する手のミスが本当に少ない。Zebra24手読みに変えましたが、
こちらは17手。読む深さの差もあるのか。

デバッグ用のBookチェックプログラムを改良して、簡易対戦と棋譜訂正が外から簡単
にできるようにしました。今まではプログラム動かしていると、気が付いた訂正箇所も
いちいちプログラム止めないと追加できなかったのですが、動かしっぱなしのままで
訂正済棋譜にして適宜放り込めるようになりました。ただ、Bookが凄い勢いで増大して
いるので、メモリーがかなり危機的状況になってきました。BookチェッカーもBook全体を
読み込むので、ダブルで効いてくる。今16Gなのですが32Gは欲しい。

Zebraに負けた棋譜の手を遡って最善手順っぽいの探して訂正していくと、まだまだ
パブリックドローっぽい手順が結構見つかる。過去に間違えてパブリックドローではない
と判断している奴も結構ありそうなので、見つけられたら最終800件くらいは行くと思う。

中盤探索の速度差は、ただのProbCutとMulti-ProbCutの差かなぁ。あれ、再計算が重くて
以前は実装していたんだけど、PC壊れてソース全滅して以来手を出していないのよね。
333: 310 [sage] 2020/07/17(金) 13:10:16.58 ID:wiyFtChq(1) AAS
王位戦第二局も含めて、ツエーーーーーーーーーー!って、今更ながらに思った。
人間相手ならabemaAI的40:60で不利な局面程度はひっくり返せるという事なんだろうなぁ。
あと、木村王位の体育座りが悲しかった。

棋譜作成は、自動作成で一気に大量に貪欲法かけたところ、既存の推定パブリックドロー筋
の4割くらいが、事前の分岐でパブリックドローから外れる事態に(汗

想定からズレた箇所は、見つけ次第ログに書き出して、そこから貪欲法でチェックするの
ですが、それでもパブリックドローから外れる筋については、Zebra使って徹底チェック。
自分のAIとZebraが同意見でも、読みが深まるにつれて揺れ動くZebraの評価値を見ていた
ら、なんとなくZebraが間違えていそうな着手がわかるようになってきて、その手をさらに
深堀してチェックする事で、ほぼ元の数まで戻す事ができました。たぶん、「パブリック
ドローから外れるのが正解」という筋が2系統ありまして、逆に周辺を掘って行ったら別の
パブリックドロー筋が見つかったりして、現在のところ残り30手推定パブリックドローが
780通り程度となりました。

増えたり減ったりはあるけど、今週だけで80件近く増えているので最終は1000件程度に
なってもおかしくない気がします。

もろに、人間が判断して手作業で修正みたいなのが、悲しいところ。
Zebraが無ければこんな事できないわけで。
339: 310 [sage] 2020/07/31(金) 00:20:53.97 ID:EPRjv06N(1/2) AAS
一括貪欲法を何度か繰り返す事で少し落ち着いてきたみたいで、パブリックドロー候補は
850件くらいになりました。

別途、Bookの再構築を速度アップしました。今までは文字通り再構築でしたが、直したい
のはDAGから生じる矛盾の修正だったので、トップから再帰で潜って戻りながら評価値など
を更新する形にして、再構築分の手間を削減しようという目論見です。が、シングルスレッド
でしか動作しないため非常に遅い。最終的に、基本の対称形を一括処理するようにして、
2手目の分岐単位でスレッドを分割して、何とか20分から5分に短縮できました。
まだ、スレッド3つしか使えていないので、もうちょっと工夫して8スレッド全部使えるように
しようかと思っています。目論みでは2分〜3分くらいまで行けかな。
340: 310 [sage] 2020/07/31(金) 00:22:31.35 ID:EPRjv06N(2/2) AAS
>>335
335(1): 535 [sage] 2020/07/20(月) 21:59:52.85 ID:Jx63yD56(1) AAS
ちょっと寄り道して4x4タイルゲームの最善手順計算してみた。
双方最善で20手で後手勝利みたい。
結構手順長いですね。
タイルゲームの最善手計算凄いですね。
5×5とか6×6にしたらどうなるんでしょうね。
341: 310 [sage] 2020/08/10(月) 01:12:51.32 ID:ABN1ddg2(1) AAS
bookの再構築は1分50秒台まで短縮しました。

30手読み切りのパブリックドロー候補は900件超え。
割と淡々と増えているので、ホンマかいなと不安になってきています。

過去にパブリックドローとみなした筋が、パブリックドローを外れた時に、原因となった
着手を追いかけて、間違い箇所探していて、大抵直す事ができるのですが、この新しく
棋譜にした筋の評価値が結構へんてこになっています。Zebraも時々そういう局面が
ありますが、結構遭遇します。おそらく過学習の絞り尻が、棋譜に出現していない局面
に押し込められているのだと思います。という訳で貪欲法のロジックを変更して、評価値
が怪しい局面から分岐をさせるように変更。とにかく棋譜を作りたいし、過去に間違えた
筋の訂正にもなるので、これをメインにしてみます。遡りチェックは、諦めて、棋譜の数の
暴力で正解筋を引く方向に変更。

そろそろ合流筋が増えて来たのと、FFOテストの局面が3つ棋譜から生成されたので、
手筋のカバー度は結構上がってきていると思うんだけどなぁ。

ちなみに現在118万棋譜。どこかで区切りつけたい気もしてきた。
343: 310 [sage] 2020/09/04(金) 16:05:06.49 ID:h5QFISg8(1/2) AAS
棋譜数の暴力で130万棋譜突破。

Book確認用画面の方で手修正を掛けられるようにして、通常の棋譜作成プログラム
を動かしながら、おかしなBook値のところから後続の棋譜作成を手作業で指示して
修正がかけられるようにしました。最初は1件単位だったのが、縦深型の貪欲法で
チェック掛けられるようになり、処理時間はかかるけど効率よく修正できるようになり
ました。

となると、以前からパブリックドローの可能性が否定できないと思っている筋(Zebraで
+0〜-1程度の変化)を重点的に調べる事ができるようになりました。調査自体はドロー
ではないと確信できるまで、Zebra参考に縦深貪欲法を適用するだけですが、結構な
筋でドローが見つかりました。続いて、既存の幅優先貪欲法と30手まで遡りチェックで
ドロー筋である事を確認。幅優先貪欲法は間違いが多いので、ここで外れた筋はもう
1回縦深貪欲法でチェック。これを繰り返して、
344: 310 [sage] 2020/09/04(金) 16:15:15.87 ID:h5QFISg8(2/2) AAS
途中で送信しちゃった。

まあ、要するに、色々棋譜作成していたら、現在ドロー候補が1000件超えました。
FJTは生きてますが、LOGISTELLOは消えました。F5d6C4g5筋がそこそこ充実。
斜め取りはF5f6E6f4G5d6からE3は消えましたが、F3とD7、もしかしたらC5も候補として浮上。

まだ、間違いがあって消える筋もあり、場合によっては200件単位でボツという事もありえ
ますが、最初は100件程度から始まった事を思えば、増えたものです。

今はとりあえずリストアップ優先ですが、最後の最後に、ガッツリとチェックの篩にかける
つもりです。どれくらい残るかなぁ。
345: 310 [sage] 2020/09/10(木) 17:54:29.45 ID:4Zp+kLKC(1) AAS
やっちまった。操作ミスで棋譜データ飛ばした。たまたま8月20日のバックアップと、
現時点でのパブリックドローリストがあったので、現在そこから復旧中。

消えた棋譜は恐らく10万件以上orz

こういうミスが起きそうなのは認識していたし、色々プログラムも整理したいので、また
プロジェクト一から作り直しするかなぁ。
348: 310 [sage] 2020/10/06(火) 23:13:30.11 ID:RrvANMT6(1) AAS
棋譜件数とパブリックドローリストはほぼ復活。
パブリックドロー件数は、1200件くらいのところで落ち着きそうな気が
してますが、まだしばらく増減があると思います。

ソースも整理して、気になっていたところを直しました。
これでデータ飛ばすリスクはかなり減りました。
ただ、Bookはまだまだスカスカだし、評価値もギザギザです。
棋譜が間違っていると思ったら、評価値(自作もZebraも)が間違っていた
というケースも散見され、そろそろBuroさん型の評価関数の限界が見えて
きた気がしています。

今ある棋譜を生かして、もっとフィット率が良い評価関数が作れないものか。
とはいえ、NN系は計算が重すぎるし、いまいちモチベーションがわかない。
352: 310 [sage] 2020/10/16(金) 00:09:49.89 ID:5RABX7jk(1) AAS
やねうら王2019のソースを見つけてダウンロードしたけど、やっぱり他人のソースを
見るモチベーションが沸きません(汗。NNUEとかLazySMPとか興味はあるんだけど。
LazySMPは8スレッド以上だと効果が出るそうで、自分の

CNNは十分な複雑さがあれば万能近似関数になりうるので、可能性はありますが、
355: 310 [sage] 2020/10/19(月) 14:10:40.58 ID:pQ38Gazt(1) AAS
書き込み途中で送信しちゃった直後から、BBQになってます。
とりあえず仕事場からカキコ。
1-
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ AAサムネイル

ぬこの手 ぬこTOP 1.177s*