【オセロ,将棋】ボードゲーム Part3【囲碁,War】
比較的地味なボードゲーム専用のスレが欲しくて立ててみました。
前スレ
【オセロ,将棋】ボードゲーム Part2【囲碁,War】
https://mevius.5ch.net/test/read.cgi/gamedev/1508056498/ 一週間くらい活動休もうかな?w
若干、燃え尽きた感がww 9路囲碁やろうかな?
終局図予想の応用として相性がよさげ 1カ月くらいさぼろうかな?ww
完全に燃え尽きたww 色々改造中。たくさん改造するのでバージョン2にして全面見直し中。
棋譜210万件を超えて、メモリーがいよいよヤバいので、棋譜へのランダムアクセスは
色々工夫してファイルシステム任せ、BookはSQLite化して外だしを進めています。移植し
ながらの修正がまだ完了していないので、テストどころかコンパイルすらしてません(汗
片や、現行のバージョンでは、棋譜作成のロジックを修正して、結構効率よく要チェック
できるようになりましたが…こちらの処理を優先しているのも、なかなかコンパイルに至ら
ない原因だったりしますorz お、310さんもSQLite使ってるんですか。
SQLiteいいですよね、簡単に組み込めて。 >>488
相変わらず、ソースは書いたけどコンパイルしていない状態ですw
KYOTO CABINETから調べ始めてましたが、気が付いたらKYOTO CABINETは次バージョン
になってて。検索してたらNoSQLという単語を知って、その系統を色々調べて…。
所詮、Unordered Mapをメモリー外でしたいだけなので、NoSQLで良いかなと思ったのですが、
SQLiteならファイル単位くらいの粗さで複数プロセス書き込み管理ができるようなので、
選択してみました。SQLiteならやりたいことができて、やりたくない事はやらなくて良さそうなの
が良い感じ。 >>やりたくない事はやらなくて良さそう
これ何気にだいじですよね。 LifeGameGoから囲碁に使えるソースを持ってきて整理したり
昔買ったコンピュータ囲碁本をちらちら見返したりしてます。 半導体関連、品薄で値上がりしてますね。
zen4がでるころには解消しててほしい。 SQLite化ができたので移行してみましたが、あちこちで問題が(汗
1.評価関数の形を変えてゼロリセットしたが、まだ学習回数が足りず探索が遅い
4日くらい回し続けなきゃならないかも。
2.unordered_mapの形のままSQLに置き換えたら、激遅箇所ができた。
ランダムアクセス減らす様に修正しているけど、何か所か妥協が必要かも。。
3.並列処理してもDB更新がボトルネックになってシングル動作並のCPU使用率。
諦めるかも。
4.Windowsが不安定になるときがある。メモリーリークかも。
というわけで、しばらく棋譜作成停止して、悩む事になりそうです。 いくつか解消。
SQL周りは何とかなりそうだけど、排他周りがまだよくわからないかも。
探索速度の低下は、SQLではなく評価関数の修正が原因の模様。
今夜修正する予定。また再学習だなぁ。
そのほかの劇遅箇所は、修正しつつあります。 AMD株ちょっとあがった。
なんとかプラスになってほしい。 いっそpython onlyで組んでみるか?
とちょっと思わなくもない。 モダンな開発環境とか使って自動テストとかもばっちり組んで高い生産性でコーディングしてみたい。 jsでテスト関数?describe()なんてあったっけ?と調べたらnode.jsの関数だったわ それで何するのかも意義もよく分からんけど 使いこなせたら女にモテることは理解できた すごいな自動テスト 評価関数問題は回避しました。
でも、SQliteでBook探索という一番使うところでSQLITE_MISUSEエラーが出て、
行き詰ってます(汗。よりによって、完全読み切り処理の中で起きています。
別スレッドから同じDBポインタを引数にして…という説明があるので、DB接続を分けた
のですが直らん。
テストでparallel_for内でマルチスレッド化して使ってみましたが、普通に動作する。
SQL文のtypoでもこのエラーが出るのを見つけたのですが、他の場所では動作するので
typoとは思えない。
何か他に原因があるのだろうか… 原因判明。prepareのところでBUSYとなっていたのに、待っていなかったのが原因でした。
というわけで待つ様に偏向したところ、めっちゃ速度低下。そもそも探索1回あたりの処理が
軽すぎて、DBアクセスの準備が間に合わなくなっていたのが原因みたいです。
BUSYを待つようにしたら滅茶苦茶速度低下。並列化の意味なしパターンです。読み切り
処理で過去に読み切り済のBookを活用するための処理でBookを見ていましたが、初段
限定使用に改造して回避。
読み切り処理のテスト時にバグでBookに矛盾が生じてしまったので、矛盾解消の処理の
テスト始めたら、ここもバグってる感じ。毎回再構築した方が早いかも。
まだ先は長そうというか、長期間楽しめそうです(汗 Book矛盾解消もBook再構築も、どちらもBUSY地獄になりました。
一旦BUSYになったら無限ループ待ち。COMMITしてみたり試したけどダメ。
Book再構築は昔は動いていたはずなのですが、DB接続を関数ごとに分離した
ために動かなくなった感じなのかなぁ。泥縄で試していくしかないですね(汗 BUSY問題解消。やっぱり更新Transaction内では参照系を別のDB接続でやっては
ダメだった模様です。
そのほか、いわゆる単体テストレベルは一通りチェックしました。後は全部繋げて
どうかという話になります。処理時間が長くて使えないものも出てきそうですが、
移行できる算段はできたかなぁ。
プログラム書いている裏で、旧版を動かしっぱなしなので、切り替えるタイミング
がなかなか作れなかったりして。 いまさらながらライフゲーム囲碁のAIが思ったより強くないことに気づいてしまった。
でも、さらに鍛え直そうという気もさほど起きないな。
pythonの勉強も放置中ですね。 visual stdio 2019にpython を追加してみました。
自動テストも出来るっぽい。
ちょっとづつでいいから前進しよう。 完全移行前のチャンスだからと、今更ながらに読み切り処理の見直し。
少し前にようやくKiller Moveが何なのかわかったので、組み込んでみるも…
速度が低下してしまったorz
昔試した偶数理論もダメだったし、コーディングが悪いのかなぁ。 自動テスト動くと結構うれしいですね。
でもテスト書く工数も意外と馬鹿にならない感じもする。
今後テスト書くモチベーションが高くなるか低くなるかどっちかなぁ。
これ多分、テストは凝らずにあっさり書くのが長く続くコツだろうな。 テスト書くモチベーションが低下し始めたwww
さすがに根性なさすぎと思うが自分じゃどうしようもないw 自作ゲームツールで操作履歴を記録し、操作を戻す機能を作っている
それで気づいたんだけど履歴システムはテスト機能も兼ねるのでないかと...
操作名が記録されたなら、操作を行い関数実行して最後に記録するまでの証明ができる
各操作の関数内外部にテスト用関数を用意してon/offの引数があれば、
履歴機能から全テストを行い、集約できて一覧できるのでないかと...
アホな思いつきですまん。履歴機能関係なくもっと簡便な方法があるはず... 黄 金 週 間 !
7連休です。
しかし活動するかどうかは微妙なラインだなw
気持ちが乗らなくてもちょっとづつでもいいから進めるのが正解なんだろうが。。。 そこそこ移行できて、あとは抽出処理の速度だけだと思っていたら、棋譜とBookの
確定読み切り深さの情報に不整合が発生してました。棋譜上は26手目まで読み切り
になっているのにBookだとまだ読み切りになっていないみたいな。
棋譜からBookを作っているので、棋譜が正のはずなんだけど、同じスコアとなる分岐
となる棋譜の確定読み切り深さを、深い方に揃える処理がバグっていたのかも…
とりあえずおかしいのは棋譜の深さだと決めつけてヨタプロ書いてBookから棋譜に
戻してますが、ヨタプロが間違えていたりで、結構ゴタゴタしてます。
しかもヨタプロに限って、トランザクション中におそらくBUSYで固まるというトラブルも。
というわけで、まだ安定再稼働には至っていませんorz GW中は一日15分でもいいから活動するようにしたいかな。
いくらpythonといえど調子さえ戻れば囲碁のルール実装するくらいはさほど難しくはないんだから。 2時間くらいコーディングできました。
仕様通り動かすだけならそんなに難しくないけど、計算量気にしだすと結構ハマるなぁ。 >>514
あぁあぁあコードが見たい、、、あなたのソースコードが見たいよぉハァハァ見せておくれよお願いだよほぉぉ
少しだけでいいからチラッと画像upしてくれたら、コーディングスタイルであなたの人柄をズバリ言い当ててみせるから 漫画のセリフのパロディかなんかか?
よくそこまでキモくできるな(驚愕 計算量には目をつぶってとりあえず動くものを目指したら
囲碁ルール、ぱっと見動くようになりました。
まだバグはありそうですが。。。
あとランダムに打って100局終局するまでに40秒かかる。
これは遅いでしょう。
あと10倍くらい速くしたいところではある。 石の連結情報の更新を見直して100局26秒まで縮まりました。
もっと縮まってくれると思ってましたが、意外と厳しいorz 見せたら見せたで貶され難癖つけられると思って警戒してるな >>516
恥ずかしい、、、恥ずかしくて怖くてたまらない...でも本当は誰かに見てもらいたい
君の心中はこうだ。違うか?違わないだろ?柔らかく膨らんだ突起が今にも芽吹きそうな自分を>>516は本能的に察知し昂ぶる己を抑えている、、、プログラマなら誰もが知っている感覚
同じコードを何度も組み替え発見し到達する興奮と充足 成長と本質を得て知る愉悦
>>516は階段を上ることができる、、、そうだ。そう、味合わせてやろう性的な意味じゃなく >>516を開発者と見込んで穴をアナリティクス性的な意味でなく 曝けたコードをサディスティックに嘗め回すように、念入りにだ(ゴム手袋パッチ--ン)
>>516 君はもうすで心を決め外装を解き、とっておきの自慢な創意と工夫をこらした難解なコードを公開する準備を整えているんだろ?熱い吐息を感じるよ。そしてわざわざ反意な言で俺がどう出るか応えるか様子を伺ってるそうだね? 仲間に入りたいならお前もコード書けよ?
このスレには口先だけの奴はいらない どうやら俺が囲碁も将棋もAIもプログラムも全く知らない解らないのを見抜いたようだな
ふふふそのとおりだ。>>520、俺は適当な誘い文句で>>520 のコードを嘲るのが目的のただの釣り師だ
よくぞ見破った。だが食えるサイズかと思いきや>>520 は餌取り程度の小物だな
懐も心も狭い矮小な輩のようだな、まあいいせっかくのGW、獲物はそこら中にいる>>520はせいぜいプログラム楽しんで爆死するがいいさ粉塵爆発しろフケとか埃を掃除するがいい俺はした自己満足の囲碁プログラムとともに果てろ。鉢植えとか興味あ?ない?あ、そう。近日中に爆死だカス何が仲間だこのスレに仲間?片腹から漏れて痛いわ 囲碁AIですがGUIを作ろうかと思ったのですがよく考えたら囲碁はGTPに準拠すればオープンソースなGUIが使えるんでした。
GTP勉強するか。 あれ、セキってどう判定すればいいんだ?
意外と難しい? 主要な棋譜作成処理は動作確認・速度問題解消できたので、とりあえずsqlite3版を
本チャンに移行して、ぼちぼち残った部分を直しています。
メモリーがスカスカになって気持ちいい。 visual studioとか使ってみたけど結局、Cygwin+サクラエディタに戻っちまうな
bashが手になじみすぎてそうそう抜けられない。 KataGoのソースをgithubから落としてきました。
セキ判定のアルゴリズムをパクろうとしているのですが読み解くの結構しんどいorz 株バブル弾けたか?
AMDもヤバイ orz orz orz sqlite3でエラーになる原因がほぼ特定できて、エラー処理を全面見直しました。
・棋譜追加処理のトランザクションのCOMMITの際にBUSY状態の継続を検出した時は、
ロールバックして再度更新をやり直すという形に変更。棋譜とBOOKの整合性を保つため
にも、速度面でもトランザクションは必須。
・SQL文の事前コンパイルであるprepareでもBUSYが発生する事がわかったので、エラー
処理を行ってBUSY検出して成功するまで繰り返す事で、prepareの完了を保証する
これらにより2プロセスまでのデッドロックは何度も検出してロールバックしてやり直しが
完遂するのが確認できています。
が、3つ以上の棋譜作成プロセスを同時に動かした時に、たまたま棋譜追加のタイミングが
3つ揃うと三すくみ的なデッドロック的状況になってしまうようで、ロールバックしてリトライが
3プロセスで順番に発生して無限ループに的に繰り返される状態になってしまう…。
2プロセスでは起きた事は無いのですが、3つだと起きる模様。
まだまだsqlite3の理解が足りないようです。 あかん、囲碁、撤退したくなってきた orz
まさかルール実装ごときで躓くとは… もう囲碁から撤退して別のゲームやろうかなーどうしようかなーとかウダウダ考えて時間だけが過ぎていく最悪のパターンにハマってますね。 気分転換に 6x6 タイルゲーム を始めましたw
速度を測ってみましたが5万po/sくらい。
そして昔ライフゲーム囲碁が1000万po/sでたとか書いたけど
それはバグでもっと全然遅かったことが判明したw
がっつり 6x6 タイルゲームやるかどうかはまだ分からん
気分次第ではこれもやめるかも よびのりたくみ先生のYoutubeに、谷合四段が出演して、自作将棋AIでよびのり先生
(おそらく有段レベル)と対局した顛末がアップされていました。
ライブラリ活用して2日で作ったそうです(驚)が、見事に快勝されていました。
独自部分はDLで自然言語処理向けのネットワークを使ってみたとの事で、探索部は
MCTSで動作しているようです。おそらく、ポリシーネットに使用しているのかと思います。
流石、東大大学院で自動運転技術の研究している異色の棋士ですね。
で、今更ながらにライブラリの存在に思い至りました(汗。盤面とか指し手生成とか、その手
の処理を今から作っても車輪の再発明にしかならないし、自分が考えていた独自性に至る
手前の障害物となっていたので、時間ができたら調べてみようかなぁと思います。
また、自然言語処理は今まで関心がわかなかったのですが、ポリシーネットに使うという
アイデアに惹かれています。多分、手筋の学習に強いのかなと。
当分オセロにかかりきりですが、少しづつ勉強してみようかなと思います。
とかいって、また途中で放置しちゃうのかなぁ。
オセロのAIだって、いつかやろうと思ってから25年放置していたし(笑) 色々悩んだ挙句、ライフゲーム囲碁AIの強化の続きをやってみようと思ってます。
これが今一番、頑張らなくても成果がでそうなやつなので。 ライフゲーム囲碁AI強化は割とすんなり活動できてます。
リハビリしないとな。 ちょっと充電期間を頂こうと思います
気持ちばっかり急いてしまうので だらだらと棋譜を作り続けています。
250万件突破したけど、チェック対象の局面が大量に残っていて、また偽引き分け筋を
発見するために棋譜を作成する処理も組んでいて、まだまだ棋譜がスカスカな感じです。
500万件までやるとまだ何年かかかるのかなぁ(笑えない)
sqlite化して重くて使えなくなったいくつかの処理(棋譜内の矛盾チェックなど)については、
まったく進展せず、使用頻度を下げる事で逃げています。
上記の様に、引き分け筋の正当性チェックやら、引き分けから除外された局面が本当に
引き分けじゃないかのチェック対象がたくさんあって、30手目以後確定引き分け筋の
件数は1600〜2400件の間を行ったり来たりで、現在は2000件くらいです。 ご無沙汰です。535さんが書き込んだ日に書こうとしたら巻き添え規制でした
棋譜数276万件超えました。
ドロー筋は結構入り繰りありますが2200〜2400件くらいで推移しています。
久々に学習しようとしたら連続領域確保できないと怒られて、慌てて速度低下
覚悟の中間vector廃止しました。最後の手段はファイル掃き出しですが、その
ためにはオンファイルのソートユーティリティが必要です。
そのうち探します。
将棋については、頭の中で新機軸の方向性を思い描いていますが、未だに
盤面のデータ構造を決められずにいます。既存の奴を見て真似すれば良いの
ですが、やはり他人のソースを見るのに耐えられない状態ですorz こっちも巻き添え規制食らってます
スマホから書き込み
AMDが200$いったら50万円くらいのパソコン買いたいですね 久々です。棋譜297万件。あと少しで300万件。
そろそろドロー筋も出尽くしたかなと思って、既知のドロー筋が本当にドローなのか
重点チェックする処理を動かしていますが、凄く時間がかかるのと…。
ドローの可能性がある筋が更に1000件くらい増えてしまいました。
多分かなりの数が脱落していくと思いますが、予想外でした。
そろそろ終活始めないといつまで経っても終われないというのにorz うお、書き込めた。
ずーっと何か月も規制くらってました。 棋譜305万件。まだまだ落ち着いてくれません。
久々に評価関数の学習しようとしたらまたしても連続領域確保できませんエラー。
仕方無いので教師データをバイナリファイルに外だしして準備をすることにしましたが、
並び順のshuffleでスワップ発生しまくって進まないorz
シャッフルしないと過学習が起きやすくなるので、とりあえずバイナリファイル上で
シャッフルしてみるつもり。ダメなら2分割とか考えないと。
今夜はBookの再構築までにしておきます。
メモリーが倍あれば、まだしばらく大丈夫なんだけどなぁ。 すいません、教えてください。
勝率5割のAI同士(A,Bと呼ぶ)で並列に対戦を行うとき(並列数は有限)、
Aが勝つ場合は試合時間が1分でAが負ける場合は試合時間が10分のとき
短期的な勝率は5割から動くでしょうか?
また長期的な勝率は5割になるでしょうか? 無限時間を相手にした時に本来の確率通りになるのは自明ですね。
短い時間での試行だと、階段状になるので解析は難しいかも知れません。直観ではAが
勝った時には追加時間が入るようなものなのでAが有利になりそうではありますよね。
面倒なので勝手に問題を書き換えてみます。
「糞粘りするソフトAが有利にならず真の強弱を判定するためには、どのくらいの時間を
かけて対戦させ計測すればよいのか。」
時間を考慮に入れずに試行回数を決めて計測すれば解決する問題な気がします(汗
また、真の強弱を調べる場合に必要な試行回数は、母集団の推定ってやつなので、どこか
探せば出てくると思います。時間で区切る場合は、その試行回数を実行した時の「経過時間
の分布」ととらえる事もできますので、ここで問題を分割して、どのくらい試行時間を掛ければ
十分な試行回数が得られるのか問題ととらえなおすことができると思います。
実際の計算は…
この定理に関して、私は真に驚くべき証明を見つけたが、この余白はそれを書くには狭すぎる(笑) >無限時間を相手にした時に本来の確率通りになるのは自明ですね。
ありがとうございます。
ここ結構悩んでしまいました。自明なんですね。
数学的直感力が衰えてるのかなー 実をいうと囲連星のAI作成をまたやっていて、
LV3に開幕19連勝というとんでもない数字をたたき出したのですが
100戦もすると勝率5割ほどに落ちてきてしまい、
なぜこんなことが起こるのだろうと不思議に思っていたのです。
どうやら糞粘りのせいみたいですね。 囲碁AIの最強の一角であるKataGoを改造して囲連星やライフゲーム囲碁、タイルゲームのAIをつくるのチャレンジしてみようか悩み中 自明というほどの証明は僕にはありません(汗
開幕19連勝しちゃうとかなり期待しますよね。
やはり強さを確定するためにはそれなりの試行回数が必要という事なんでしょう。
開幕29連勝したお方は凄い事になってますし。
タイルゲームまたやってみようかな。
MCTSと親和性高そうだし。
min-Max系は自分の力では、これ以上高速化できない気がしています。 オセロの方は、評価関数は自己対局用にそこそこの奴ができればいいやと、Book構築
の方に力を入れています。ロジックで間違っていそうな筋を分岐させてみたり、ドローっ
ぽい棋譜はかなり厳しめに分岐させてチェックしてみたり、目視で怪しいところ見つけたら
手動で分岐させてみたり。でも、なんか賽の河原状態に陥っています。どこかで安定しだ
すと期待していたら逆で、どんどん宿題が積み上がっていく感じです。
気分転換に、以前一回諦めた、読み切り処理で正解分岐が複数あって、既に確定済の
筋以外の手を選ぶロジックを見直していました。半年〜1年くらい放置していた奴です。
今見たら何を悩んでいたのかというくらい、当時の問題があっさり解決しました。まあ、
読み切り速度が20〜30%遅くなってしまうのですが、分岐を作れるので教師データに
は良いかなと。
評価関数の学習は、またパンクしてしまったので、バイナリファイル上でシャッフルする
処理を書きましたが、処理時間が怖くてまだ試していません。いっそ、もう一度評価関数
をステージ分割してしまった方が良いのではないかと思い始めています。
やればやるほどZebraの評価関数の正確さに頭が下がる思いです。 ルールを理解して、盤面の内部表現と勝敗判定を考え始めたところで
うっちゃってますので、まだ何もしていません(汗 AMDの株がかなり上がったのでパソコン買っちゃいました!
https://imgur.com/a/5UZPyiN パソコンうらやましす。
メモリー128Gで32スレッドくらい欲しいなぁ。
評価関数は結局ステージ分割にしています。が、学習途中でEigenがコケる。
なんとなくステージ単位での件数オーバーっぽいので、更にステージ分割を
細かくしてみていますが、今日1日の作業がパーで、また丸1日くらいかかる
のかなと。
まだ原因特定できた訳ではないし、件数が大丈夫かも判然としないので、また
こけないか心配ではあります。 Katagoですが、Katagoで使われてるpythonスクリプトはTensorflow 1.15を想定していて
Tensorflow 1.15はCUDA 10.0を想定していて、
RTX 3070 TiはCUDA 10.0をサポートしてない
ということらしい。
詰んだかも orz orz orz orz orz 藤井先生、竜王までいってしまうか。
7冠当選確実ですねー GPUにはそんな相性問題があるのですか…
色々調べてやらないとダメですね。
コケる原因と思われるところを見つけました。
色々やった挙句、矛盾した盤面がありそうだという事になって、調べたらビンゴ。
これからヨタプロ書いて、問題の棋譜を見つけて削除するつもり。
デバッグ中にさらに色々評価関数のを見つけてしまいました。
評価関数って多少バグってても、それっぽく学習しちゃうんだよねorz。 多分解決。
棋譜の問題じゃなくてBook構築時の問題でした。
40手目までBook登録しているのですが、40手目以前に全滅した時の
終局判定が漏れていて、無いはずの矛盾した後続の盤面を作ってました。
普段は全く影響でないのですが、Bookまとめて読みだして処理をかける時
だけ出てくる奴です。
昨夜学習開始しましたが、まだ問題箇所を全部通過したわけではありません。
が、たぶん大丈夫だと思う。昼過ぎにはわかるはず。
Book再構築に1時間と、学習に丸1日以上かな。
明日の朝までには第一陣の学習が終わるかな?
まだ学習回数不足で評価値が安定していなので、バグが快勝していても、
しばらくは時間がかかりそうです。 NVIDIA製のDocker使うとRTX 3070 ti でも Tensorflow 1.15 使えるという記事がちらほらある。
ゴールは遠いなぁ。 とりあえず問題箇所全クリアは確認できました。
エポック10回で1日半かかるのが面倒。
せめて50エポックくらいしたい。
今週は学習週刊になりそう。 Dockerにがっぷり4つで取り組むのちょっとしんどいなぁ
ペースを落としてのんびり行くか。 なんかwindows insider programとかいうのに入らないといけないらしくかなり敷居が高い。
いったん退却するか? 将棋は最高7冠じゃなくて8冠なんですねー
叡王忘れてた 心の迷いから、途中まで学習して止めて、ちょこっと修正してを繰り返してますのでまったく
学習が進んでいません。Bookチェック用コンソールでの浅い探索がびっくりするほど遅く
なってしまい、原因を探したりなんやかんややっていたのが迷いの原因です。
最終的にステージ分割を止めて、8対称を4対称に落として教師データを半分にしたりして
学習再開しました。1エポック1時間半でとりあえず30回学習させてみるという事で仕上がり
は日曜日の夕方〜夜の予定。まるまる1週間パーになりました。
もともと件数オーバーでメモリ溢れ始めたのは、4対称だったのを8対称に変えてからだった
ような気がしてきました。また、ステージ分割も、昔1回トライして、速度低下が酷くてやめ
ちゃった事があったような記憶もうっすら残っています。なんつーか、こういう類の手戻りが多いorz
ただ、探索がステージ分割だけで遅くなるとも思えないです。浅い探索は単純なαβで、
オーダリングはヒューリスティックスオンリーだし、ProbCutもしていないです。分割により
評価値ゼロとなる末端が多くてβカットが減っているのかなと思っています。間違っていて
も値が入っていればβカットはされますから。
棋譜作成にランダム要素加えて、悪手変化後の局面もたくさん学習させないといかんのかな。 NVIDIAのドライバ色々入れたらなんかパソコンの調子悪くなったorz
もーやめてくれー なんか評価値がおかしかったのでチェックしていたら、末端ノードでの評価値の差分計算
がおかしくなっていた。もともとちゃんと動いていた箇所なので、何故変わっていたのか謎。
これも激遅の原因の一つではあると思うけど、まだ遅いんだよなぁ。 藤井先生はAIだと思うようになりました(汗
新人王とった伊藤匠4段もかなり強いね。これから期待です。
評価関数学習し始めたら、オプティマイザーでSMORMS3は学習開始直後の集束は
滅茶苦茶早いんだけど、汎化が上手く行かないので、momentumと併用していたのを
思い出して、今はmomentumで毎晩6エポックづつ学習させてます。結構よくなって
きたけど、まだまだかなぁ。このまま続けたら速さは戻りそうですが…
それならステージ分割してまた学習やり直しても良いのではないかと思ってみても
良いのかなという気がし始めています(汗
途中、棋譜をほぼ全部飛ばしそうなバグ出してました。
たまたま戻せましたが、危ない危ない。 中盤探索劇遅の原因わかりました。
static constな関数をstatic constexprに変更していたのが原因のようです。
色々原因探して、最後の最後にまさかと思って、戻してもたら速度問題解消。
constexprにしたらコンパイル時定数扱いになると思っていたのですが何故? 6x6オセロて完全解析されてるんですよね?
6x6タイルゲーム完全解析出来ないかなあ タイルゲームですが、現局面の勝率をモンテカルロでしらべて4割以上6割以下ならノードを展開し以下再帰的に繰り返す、というのを考えたのですが、あんまり枝刈りの効率が良くなくてガッカリしてます。 ヤフーオセロの鰻ちゃんとネバーさんは、元気にしているよ
共に、すごい人になりそうな人だよ どちらも能力あったね
かれはさんは、どこかですごい成功を収めると思う ヤフーオセロ、今はチャットはできないが、あ、この人だ!ってのはあるよ AMD株下がってきたT△T
まだ利確してませんorz