【オセロ,将棋】ボードゲーム Part3【囲碁,War】
比較的地味なボードゲーム専用のスレが欲しくて立ててみました。
前スレ
【オセロ,将棋】ボードゲーム Part2【囲碁,War】
https://mevius.5ch.net/test/read.cgi/gamedev/1508056498/ うーん、もしかしたらCPUはあんま必要なくてGPUに金使ったほうがいいのかもしれないな。これは。 層増やしたけどあんまうまく行ってないのかなぁ。
それともまだまだ学習が足りないだけなのか… 棋譜作成触りすぎるとなかなかはかどらなくなるので、しばし回しっぱなし。
そろそろBookが巨大化しすぎているので、メモリーからSDDに移せないか検討中。
concurrent_unordered_mapを自作した経緯があるので、同じような感じでランダム
アクセスなDB化をしてます。確定分は探索で使うのでメモリーにおいて、速度を
必要としないアクセスをDBにしようかなと。
巨大Bookの作成処理の類を並列処理にしているので、何とか並列にできないかと
色々やっていますが、色々と罠がある。複数プロセスからの並列更新はあきらめた
けど、単一プロセスからの並列更新でロック範囲がまだいまいち。
専門書買ってコード見て勉強した方が早いんだろうけど、まあ、しばらく楽しみます。 いままで新旧のAIを比較するとき10戦中6勝以上でAI更新にしてたのを50戦中30勝以上で更新にしてみます。
もしかしたら試行回数が少なすぎて弱くなっていてもAI更新してたかもしれないので。 うぬぬ。DB化は並列諦めてみたけど、やはり更新が遅すぎる。
もうちょっと工夫してみるけど。 ただ待ってるだけってのもつらいな。
結果も出ないし。 自己対局みてると結構強そうに見えるだけどな。
公式AIと対局すると勝てねんだよな。 AlphaGoは計算資源をコスト度外視で使って1000年分対局してるから…… IT掲示板群 ttp://x0000.net/forum.aspx?id=15
学術の巨大掲示板群 - アルファ・ラボ ttp://x0000.net
数学 物理学 化学 生物学 天文学 地理地学
IT 電子 工学 言語学 国語 方言 など
simulationライブラリで純粋な関数式プログラミングをする
ttp://x0000.net/topic.aspx?id=3631-0
UIライブラリ (C#, 2D) を作ったよ
ttp://x0000.net/topic.aspx?id=3688-0
連続と離散を統一した!
ttp://x0000.net/topic.aspx?id=3709-0
4Dエンジン
ttp://x0000.net/topic.aspx?id=3677-0
matrixのライブラリ
ttp://x0000.net/topic.aspx?id=3711-0
ある強力なFor関数
ttp://x0000.net/topic.aspx?id=3630-0
SQLライブラリ
ttp://x0000.net/topic.aspx?id=3675-0 >>292
/ ̄⌒⌒ヽ
| / ̄ ̄ ̄ヽ
| | / \|
.| | ´ ` |
(6 つ / ちくしょう・・・
.| / /⌒⌒ヽ
| \  ̄ ノ
| / ̄
,冖 ,、 冖 / // ,. - ―- 、
`,-. -、'ヽ' └ァ --'、 〔/ / _/ ヽ
ヽ_'_ノ)_ノ `r=_ノ / / ,.フ^ー- j
,冖 ,、 ,へ / ,ィ / \
`,-. -、'ヽ' く <´ 7_// / _/^ 、`、
ヽ_'_ノ)_ノ \> / / / _ 、,.;j ヽ|
n 「 | /. | -'''" =-{_ヽ{
ll || .,ヘ / ,-、 | ,r' / ̄‐-..,フ!
ll ヽ二ノ__ { / ハ `l/ i' i _ `ヽ
l| _| ゙っ  ̄フ.rソ i' l r' ,..二''ァ ,ノ
|l (,・_,゙> / { ' ノ l /''"´ 〈/ /
ll ,冖 ,、 > >-' ;: | ! i {
l| `,-. -、'ヽ' \ l l ;. l | | !
|l ヽ_'_ノ)_ノ トー-. !. ; |. | ,. -、,...、| :l
ll ,冖 ,、 |\/ l ; l i i | l
ll `,-. -、'ヽ' iヾ l l ;: l | { j {
|l ヽ_'_ノ)_ノ { |. ゝ ;:i' `ー‐-' }
. n. n. n l | ::. \ ヽ、__ ノ
|! |! |! l | ::. `ー-`ニ''ブ
o o o ,へ l :. | Hash関数変更
DBのハッシュキーの効率が悪かったので、ちょっと考えてみた。
今まではshuffle_epi8でバイト単位シャッフルしていたのを、BMIのpextでビット単位の
シャッフルと、rotateしたものを、xorでまとめていく方法。以前よりは、ちょっと良くなった
気がする。
何をもってよくなったかの指標が欲しくなり、ネットを探索したけど、数値指標みたいなの
は見つからない。確率論の誕生日問題の反対みたいな状況なのでしばらく考えてみる。
要するに、1万人くらいの生徒がいる学校で、誰一人誕生日ではない日が何%くらい存在
するのかという類の問題です。
また、そう考えてみると、現状では直観よりかなり未使用キーが多い気がしています。
xorを繰り返してビットのオンオフをすると、いずれ立っているビット数が32個を平均と
した正規分布(二項分布)になって、一様分布にならないのではないかという疑念が。
正規分布だと、中央に近いところは重複しやすく、立っているビット数が0とか64とか
の出現確率が下がる事になります。xor繰り返すと正規分布に本当に近づいていくのか、
ちょっと検証してみたい。 DBの件
たぶんあるだろうとネットで検索してみたら、Kyoto Cabinetなるキーバリュー型の
簡易DBライブラリがある事が判明。ほかにもLevelDBとか、何種類かあるみたい。
RDB使うまでもないけど、データ量が多いとメモリーだとリソース勿体ないみたいな。
やはりみんな考える事は一緒だなと。せっかくなので導入の方向で検討。
DBの速度問題
また、おそらく1棋譜単位でのBook更新は速度的に問題ないのですが、DAG(合流)
時に、棋譜外の合流元の方の更新がされないという問題があり、学習前に一括で
再構築しています。この一括更新が件数の関係ですごく時間がかかる事が問題です。
一応、1棋譜単位で更新した時に、DAG分もちゃんと処理するロジックを検討中です。
バグさえなければ速度問題はかなり解消できるはず。とはいえ、何回もループを回す
処理となるため、速度に自信なし。 DBの件…
確定探索の時にはメモリーに確定分だけおいとくと考えていましたが、
今件数確認したらおよそ2/3は確定分として確保しなきゃならない
事に気づきました(汗
棋譜作成時はメモリーでやるしかないかも。
1棋譜更新でのDAG問題回避はやりたいかな。
Book再構築にだいたい20分くらいかかる。
DAG回避で1棋譜分更新するのが1秒として1000棋譜追加でおよそ16分。
これ以下の時間で済むならやる価値ありそう。 久々に完全読み切りでバグ発生。
ProbCutを広げながらmtd(f)している時に、どうもパス絡みで発生しているっぽい。
ProbCutによるIterative Wideningを止めたらちゃんと読み切る。
まあ、置換表絡みなんだとは思うけど、事例が少なすぎて(数か月に1回程度)、
前の記録消しちゃったので、とりあえず記録を残し、絆創膏当てて続行。
気が向いたらデバッグしてみる。可能性があるところはなんとなくわかっている
つもりだけど。
Book更新時のDAG回避は、かなり悩ましい。というか頭がこんがらがる。
未使用Hashの期待値計算も頭が未だにこんがらがってます。。 お姉さん問題で有名な、北大の湊教授のZDD を使えないの?
本も出てる katagoを使った9路囲碁の巨大Book作成、やってみようかなぁ。
難しそうだけど。 Hash関数の効率判断基準できました。
同じキーにデータが8つくらい入っているようなものもあり、それが適正かどうか
判断できなくてゴチャゴチャしていましたが、昨夜しれっと書いたように未使用キー
の数の期待値に着目したら簡単でした。
キーサイズと、データ件数からExcelなどで簡単に計算できます。
3件程度調べてみましたが、理想的な一様ランダム値で生じる未使用キー数の
期待値との差は0.1%未満で、このHash関数も一様ランダム化するものと言って
良いレベルでした。
逆に言えば、自分の典型的な使用方法だと20〜30%のキーが未使用になる
という事のようです。これはこれで…。 やっぱライフゲーム囲碁やりてぇなぁ。
ウーム悩ましい。 Hash値、1件2件…と期待値出そうと思ったら、なんとなく昔の記憶が戻ってきて、
0件の時は不要だけど、こちらではPとかCとかが必要になるような気がしてきた。
確率の勉強するかな。
ZDDちらっと見てみたけど、ちょっと目的と違うような感じがしている。
本買ってみるけど。
脱線はこれくらいにして、DAG考慮したBook更新に戻ろう。 自己流でライフゲーム囲碁に取り組むべきか。
なぜalpha zeroがうまく行かなかったのかを調査すべきか。
まあしばらくさぼりモードだけど。 ・19路盤での定石の発見とかを可視化して、強さを判断する
・まず5〜9路盤で最強目指す
俺なら後者を選択する
バグが出なくなったら前者に取り組む >>306
実際に自分で手を動かす人なら歓迎するぞ?
口先だけならいらない。 DAG時のBook更新の件、めっちゃ悩み中。
普通にやったら1件更新に14秒とかかかって使い物にならない。
逆引きDBを作ろうかと思うのだけど、結構なサイズになるので、それこそメモリーに
置きたくない。形としてはunordered_multimapになるんだけど、Kyoto Cabinetが重複
キーを許すのか英文読まなきゃならないので止まってる。
そうこうするうちに完全読み切りのバグがまた発生して、事例が3件になったので、
調査開始。2か所間違いを発見。一つ目はケアレスミス。
2つ目は最善手の直後にパスが来るケース。置換表登録はパス後、オーダリングなどで
読む時はパス前の盤面になっていた。これで値が狂う理由がいまいち理解できないの
だけど、修正したら正しい答えが出るようになった。パスの処理は本当に鬼門。
たぶんバグは取れたけど、50%くらい速度低下。どこかにまだバグがありそう。 速度低下は50%どころではなかった…150〜200%だorz orderingの中でパス処理をしていたのでmobility関数を呼びまくっているのが遅い原因
ではないかと思い、パスの処理の仕方を変えて、パスも1手とするように変更したところ、
15〜20%の速度低下まで戻りました。他にも、つられてバグが発覚したので修正。
かなりのレアケースでしか発生しないバグですが、今まで自信満々で完全読み切りは
間違っていないと思っていましたが、なんか自信なくなった。
中盤探索も同様に修正したら、浅い探索の読み筋が変わったみたいで、少しは精度が
良くなるのかなぁと期待しています。 以前もちょろっと触れたけど囲碁ディープラーニングプログラミングという本の12章にあるactor-critic法というのがまた気になり始めた。
自分なりに解釈して実装してみようかな。 またエラーが…
なんとなく記憶をたどっていくと、初段で並列処理してMap-Reduceすると、βカットの関係で
評価値は合っていても、ordering次第で間違った手を返す事を思い出しました。
で、たまたま回避策となっていた処理を>>201で外してしまったのではないかと。
並列探索だと本質的に回避できない気がするので、初段を順次処理に変更。残り空きマス
26での平均処理時間。一時は20〜25秒くらいまで来ていたのが、30秒程度に悪化orz 藤井7段凄かったね。今年中に8段行っちゃうんじゃないかと思った。
エラーの原因を冷静に見直したところ、どこをどう変えたか覚えていないレベルの
ちょっとした修正を加えたところからドツボって、修正するたびに更にバグを仕込んで
いたような。結局、元々のプログラムに戻して、速度も復旧しました。むむむ。
こういうのがあるからから、終盤探索に手を入れたくないorz
Bookの遡り修正ですが…行き詰っています。
Kyoto Cabinetはやはり単一キーしか扱えず。
メモリー上に逆引きDBを作ると、たぶんBookよりサイズが大きくなるためメモリーにおけない。
しばし悩み中。
息抜きで、棋譜作成のロジックをちょこっと修正。
同じような評価値が並んでいたり、最善手より評価値が良くなる分岐について、今までは
見つけて気になったところだけ手で追加していましたが、適度なペースで見つけて自動的
に追加する様にしました。 長期サボりモードに突入
なんか本で読んだけどモンテカルロ木探索の訪問回数をdnnの教師データとして使うようなやり方もあるらしい DB化、未だに方法が見いだせずストップしてます。
パブリックドロー臭いのにそうじゃない筋を手動で修正して、20件ほどもとに戻った。
その間に、棋譜が100万件突破しました。
が、Book眺めていると、まだまだ間違い多い。
Zebraも結構間違えているけどね。 2020/05/11 グロービス、囲碁AI「GLOBIS-AQZ」のプログラムをオープンソース化 プロジェクトの集大成としてソースコードを公開
https://www.globis.co.jp/news/release/20200511_globis.html
知らなかった。
ちょっと見てみようかなぁ なお、公開しているソースコードは対局・解析のみの実装で、学習に関する機能は含まれていません。
駄目じゃんorz ライフゲーム囲碁でモンテカルロ木探索の訪問回数をdnnの教師データにするのやり始めました。
今教師データを収集してるところです。 教師データを学習させてみましたがあんまり強くなりませんでした。orz そもそもモンテカルロ木探索を教師にしてる時点で、モンテカルロ木探索の強さを大きくは超えられないわけで。
根本的に駄目な気はしてきたorz 結局、現状、良い教師データがないと厳しい。
アルファゼロ方式の自己対局で強くなるのは1000年かかりそうだし。
むうぅ ライフゲーム囲碁で打った石が最終的に取られるかどうかを学習させてみようかと考え中 相変わらず棋譜作成しながら評価関数学習を続けています。ようやく100万件突破。
推定パブリックドローは大体700件くらいで増えたり減ったりしています。
対称形や合流も重複させていますので、重複除くと400件くらいかなぁ。
終盤は比較的多数の分岐を試しているのですが、序中盤の分岐が不足していて、
棋譜が偏っているような気がしてきたので、棋譜作成のロジックを大幅に変更して
序中盤の分岐が多くなるように。また、評価値とBook値が大きく違う分岐を再検証
するようにしてみました。これで、抜けている筋がだいぶ拾えるようになると期待。
棋譜作成中に暇な時間が多いので、試しにZebraと対戦。Zebraはランダムに
パブリックドロー筋から外れる様にできているようですが、外れたら勝てるはずが、
なかなか勝てない。Zebra26手読み、こちらは時間の都合で20手読みくらいなので
仕方が無いのですが、それにしてもBook外れた時の評価関数の精度が悪いという事に。
あと、やはり中盤探索の速度に大きな差があり、とても26手読みなどできない。
むむむ。 つか、藤井先生強すぎ。
1回勝負なら時々一発入るけど、番勝負で勝ち越せる人いないんじゃないかな。
竜王戦勝ち進んで、豊島竜王名人との番勝負が見てみたい。 そこに打ったらn手以内に反撃で取られてしまうか?を判定するルーチンを書いてAIに組み込んだら、かなり動きがよくなった。 結局、強化学習できない限り、DNNあんま意味ないんじゃ?という状態。 残念だったね<F7先生。相当疲れているんじゃないかな。まだ連戦続くので心配。
こちらは棋譜じゃんじゃか追加中。もう逆順探索で正確さを高めるなんて言ってられない。
いちいち遡りチェックするより、分岐を増やしてしまった方が早い気がしてきた。
で、Zebraと対戦させると、まだまだ穴だらけ。Zebraがわざとパブリックドローから外した
ところからが本番の対局となるのですが、そこから10〜20手の間に2回くらい間違えて
逆転される感じ。逆にZebraがほとんど間違えていない事に驚いています。評価値は怪しい
ところもあるけど、選択する手のミスが本当に少ない。Zebra24手読みに変えましたが、
こちらは17手。読む深さの差もあるのか。
デバッグ用のBookチェックプログラムを改良して、簡易対戦と棋譜訂正が外から簡単
にできるようにしました。今まではプログラム動かしていると、気が付いた訂正箇所も
いちいちプログラム止めないと追加できなかったのですが、動かしっぱなしのままで
訂正済棋譜にして適宜放り込めるようになりました。ただ、Bookが凄い勢いで増大して
いるので、メモリーがかなり危機的状況になってきました。BookチェッカーもBook全体を
読み込むので、ダブルで効いてくる。今16Gなのですが32Gは欲しい。
Zebraに負けた棋譜の手を遡って最善手順っぽいの探して訂正していくと、まだまだ
パブリックドローっぽい手順が結構見つかる。過去に間違えてパブリックドローではない
と判断している奴も結構ありそうなので、見つけられたら最終800件くらいは行くと思う。
中盤探索の速度差は、ただのProbCutとMulti-ProbCutの差かなぁ。あれ、再計算が重くて
以前は実装していたんだけど、PC壊れてソース全滅して以来手を出していないのよね。 王位戦第二局も含めて、ツエーーーーーーーーーー!って、今更ながらに思った。
人間相手ならabemaAI的40:60で不利な局面程度はひっくり返せるという事なんだろうなぁ。
あと、木村王位の体育座りが悲しかった。
棋譜作成は、自動作成で一気に大量に貪欲法かけたところ、既存の推定パブリックドロー筋
の4割くらいが、事前の分岐でパブリックドローから外れる事態に(汗
想定からズレた箇所は、見つけ次第ログに書き出して、そこから貪欲法でチェックするの
ですが、それでもパブリックドローから外れる筋については、Zebra使って徹底チェック。
自分のAIとZebraが同意見でも、読みが深まるにつれて揺れ動くZebraの評価値を見ていた
ら、なんとなくZebraが間違えていそうな着手がわかるようになってきて、その手をさらに
深堀してチェックする事で、ほぼ元の数まで戻す事ができました。たぶん、「パブリック
ドローから外れるのが正解」という筋が2系統ありまして、逆に周辺を掘って行ったら別の
パブリックドロー筋が見つかったりして、現在のところ残り30手推定パブリックドローが
780通り程度となりました。
増えたり減ったりはあるけど、今週だけで80件近く増えているので最終は1000件程度に
なってもおかしくない気がします。
もろに、人間が判断して手作業で修正みたいなのが、悲しいところ。
Zebraが無ければこんな事できないわけで。 とりあえず、>>328のAIで棋譜取り始めることにしました。
棋譜取った後の方針はまだあんまり固まってませんが。 ちょっと寄り道して4x4タイルゲームの最善手順計算してみた。
双方最善で20手で後手勝利みたい。
結構手順長いですね。 ふとやねうらおさんのサイトちょっとみてみたら、やっぱレベルたけーんだなって感じ。 一括貪欲法を何度か繰り返す事で少し落ち着いてきたみたいで、パブリックドロー候補は
850件くらいになりました。
別途、Bookの再構築を速度アップしました。今までは文字通り再構築でしたが、直したい
のはDAGから生じる矛盾の修正だったので、トップから再帰で潜って戻りながら評価値など
を更新する形にして、再構築分の手間を削減しようという目論見です。が、シングルスレッド
でしか動作しないため非常に遅い。最終的に、基本の対称形を一括処理するようにして、
2手目の分岐単位でスレッドを分割して、何とか20分から5分に短縮できました。
まだ、スレッド3つしか使えていないので、もうちょっと工夫して8スレッド全部使えるように
しようかと思っています。目論みでは2分〜3分くらいまで行けかな。 >>335
タイルゲームの最善手計算凄いですね。
5×5とか6×6にしたらどうなるんでしょうね。 bookの再構築は1分50秒台まで短縮しました。
30手読み切りのパブリックドロー候補は900件超え。
割と淡々と増えているので、ホンマかいなと不安になってきています。
過去にパブリックドローとみなした筋が、パブリックドローを外れた時に、原因となった
着手を追いかけて、間違い箇所探していて、大抵直す事ができるのですが、この新しく
棋譜にした筋の評価値が結構へんてこになっています。Zebraも時々そういう局面が
ありますが、結構遭遇します。おそらく過学習の絞り尻が、棋譜に出現していない局面
に押し込められているのだと思います。という訳で貪欲法のロジックを変更して、評価値
が怪しい局面から分岐をさせるように変更。とにかく棋譜を作りたいし、過去に間違えた
筋の訂正にもなるので、これをメインにしてみます。遡りチェックは、諦めて、棋譜の数の
暴力で正解筋を引く方向に変更。
そろそろ合流筋が増えて来たのと、FFOテストの局面が3つ棋譜から生成されたので、
手筋のカバー度は結構上がってきていると思うんだけどなぁ。
ちなみに現在118万棋譜。どこかで区切りつけたい気もしてきた。 棋譜数の暴力で130万棋譜突破。
Book確認用画面の方で手修正を掛けられるようにして、通常の棋譜作成プログラム
を動かしながら、おかしなBook値のところから後続の棋譜作成を手作業で指示して
修正がかけられるようにしました。最初は1件単位だったのが、縦深型の貪欲法で
チェック掛けられるようになり、処理時間はかかるけど効率よく修正できるようになり
ました。
となると、以前からパブリックドローの可能性が否定できないと思っている筋(Zebraで
+0〜-1程度の変化)を重点的に調べる事ができるようになりました。調査自体はドロー
ではないと確信できるまで、Zebra参考に縦深貪欲法を適用するだけですが、結構な
筋でドローが見つかりました。続いて、既存の幅優先貪欲法と30手まで遡りチェックで
ドロー筋である事を確認。幅優先貪欲法は間違いが多いので、ここで外れた筋はもう
1回縦深貪欲法でチェック。これを繰り返して、 途中で送信しちゃった。
まあ、要するに、色々棋譜作成していたら、現在ドロー候補が1000件超えました。
FJTは生きてますが、LOGISTELLOは消えました。F5d6C4g5筋がそこそこ充実。
斜め取りはF5f6E6f4G5d6からE3は消えましたが、F3とD7、もしかしたらC5も候補として浮上。
まだ、間違いがあって消える筋もあり、場合によっては200件単位でボツという事もありえ
ますが、最初は100件程度から始まった事を思えば、増えたものです。
今はとりあえずリストアップ優先ですが、最後の最後に、ガッツリとチェックの篩にかける
つもりです。どれくらい残るかなぁ。 やっちまった。操作ミスで棋譜データ飛ばした。たまたま8月20日のバックアップと、
現時点でのパブリックドローリストがあったので、現在そこから復旧中。
消えた棋譜は恐らく10万件以上orz
こういうミスが起きそうなのは認識していたし、色々プログラムも整理したいので、また
プロジェクト一から作り直しするかなぁ。 ちょっとわけあって長期で活動から離れていました。
また活動再開する予定もないのですが、このままフェードアウトするのも寂しいのでLifeGameGoのAIを公開します。
アルゴリズムはモンテカルロ木探索+>>328のヒューリスティックですね。
https://drive.google.com/file/d/1n-QaJ_Jhbb-yGMOzA993CjgVofZIKf4n/view?usp=sharing >>346のAIはそこそこ強いと思います。
vectorで公開してるやつより若干強いはず。 棋譜件数とパブリックドローリストはほぼ復活。
パブリックドロー件数は、1200件くらいのところで落ち着きそうな気が
してますが、まだしばらく増減があると思います。
ソースも整理して、気になっていたところを直しました。
これでデータ飛ばすリスクはかなり減りました。
ただ、Bookはまだまだスカスカだし、評価値もギザギザです。
棋譜が間違っていると思ったら、評価値(自作もZebraも)が間違っていた
というケースも散見され、そろそろBuroさん型の評価関数の限界が見えて
きた気がしています。
今ある棋譜を生かして、もっとフィット率が良い評価関数が作れないものか。
とはいえ、NN系は計算が重すぎるし、いまいちモチベーションがわかない。 AI作成はやってないのですがライフゲーム囲碁ってタイルゲームみたいに千日手存在するのだろうか?というのがちょっと気になってツラツラ考えています。
きちんと証明しようとすると意外と難しい ライフゲーム囲碁では千日手はなさそう。
でもうまく証明できないな。 全ての棋理を表現できる構造体作れないかな、とかちょっと妄想したけど、
もしかしてCNNでほぼ実現できてるのかな、とも思ったり。 やねうら王2019のソースを見つけてダウンロードしたけど、やっぱり他人のソースを
見るモチベーションが沸きません(汗。NNUEとかLazySMPとか興味はあるんだけど。
LazySMPは8スレッド以上だと効果が出るそうで、自分の
CNNは十分な複雑さがあれば万能近似関数になりうるので、可能性はありますが、 単純すぎる棋理で勝てちゃうゲームもつまらないし
棋理らしい棋理もなく逆転逆転ばっかりのゲームもつまらないし
理想のゲームバランスってどんなんなんだろね DeepMindのMuzeroってAtari 2600のゲームも解けるらしいけど、
冷静に考えるととんでもないことですね。 書き込み途中で送信しちゃった直後から、BBQになってます。
とりあえず仕事場からカキコ。 そろそろ書けるかな?
CNNは色の無い万能近似関数で、汎化性能なるものが幻想ならば、という前提で。
万能近似関数が正しく学習できるためには、全局面分の教師データが必要となります。
その時、万能近似関数で学習する暇があったら、全局面分の教師データでTHE BOOK
を作ってしまえば良い。これで絶対に間違えなくなる。
という事で、可能性はあるけど、それが実現できるレベルに至ったら、そもそもCNNが
必要ないという事になるのではないかと思います(汗
評価関数なるものは、そもそも全局面を列挙する事が不可能な時に、とりあえず重要そう
な局面のセットで学ばせるものではないかと思います。 >>356
どもです。
>THE BOOKを作ってしまえば良い。
最近タイルゲームでTHE BOOKをどれだけコンパクトに表現できるか?
みたいなことをツラツラ考えていたりします。
勝利局面を列挙する以上にコンパクトにできたら素敵だなと。
羽生さん100期がんばれ! cnnが汎化性能出せるかどうかはゲームによるところもあるのかな、と思ったり タイルゲームのTHE BOOKをテキストでダンプしてみました。
266MBくらいになった。
>>300のZDDで圧縮、ちょっとやってみたいかも? 藤井二冠の自作PCについて最強将棋ソフト開発者に聞いたらトンデモないことが判明した件
https://originalnews.nico/281224
コンピュータ将棋スレで拾って読んだけど、めちゃうなずいてしまった。
あと、テラショック定跡という名前でビビッて劣等感を感じていたけど100万局面とな。
今140万超の棋譜なので、局面ではその60倍になる。重複外しても1000万はあるはず。
でも、オセロの様な単純なゲームにとっても、まだ全然スカスカ。
貪欲法の効率が上がり、ついでにおかしそうな棋譜の訂正もかけるようにしたので、
以前よりは、ゴミ棋譜が減ったと思う。過去のゴミ棋譜除去にはまだ時間かかるけど。 >>361
がんばれ〜
俺はもうかなりさぼりモード入ってるからスレを盛り上げてくれると嬉しい。 ちなみにタイルゲームは盤面が小さいからしらみつぶしできるってだけで、
盤面が大きくなったら全然簡単じゃないからね。 ライフゲーム囲碁はルール上、パス機能が必須だと思ってたけど、
片方が一回合法手がなくなった時点で終局図は確定してしまうから
パス機能なしでも大丈夫だということに気づいた。
すなわちgithubからひろってきたalpha zeroで
パスを実装しなくてもライフゲーム囲碁を移植できる! パスしないと負け、パスすれば勝ちのケースはあるのでは?
ルール上、パスがオーケーなら組み込まないと別ゲームになってしまう
囲碁や将棋やオセロではパスはできないが
ルールはしらないが いや間違えた
オセロは手がなくなればパスに自動的だが
戦略上、パスもできるゲームはパスいれないと駄目だが、正確なルールは把握してない いやさらにまちがってたかも?
囲碁もいまいちで
囲碁はパスしていいルールだった気もしてきた ライフゲーム囲碁はどんな着手であってもパスより自分の不利に働くことがないゲームなのです。 羽生さん、99期で終わったら死んでも死にきれないだろ コロナではないようですね。
100期は何とか達成してほしいですね〜。 ちょっとgoogle colabに手を出し始めました。 google colab(python)上でライフゲーム囲碁のルールが大体実装できてきました。
あとはgit hubでも漁ってalpha zeroなりmuzeroなりを移植できれば。 タイルゲームの作者って絶対、完全解析、達成してるはずなんだよな。
でもしなかったってのは完全解析より成長するAIのほうがおもしろいと思ったってことかな? なんかalpha zero も muzeroも全然できそうにないな。
まるでRPGでまだフラグが立ってないからこれ以上先に進めない、みたいなのと同じ感覚に陥る。 あかん、これはGPUないと計算時間がとてつもないかも。