【オセロ,将棋】ボードゲーム Part3【囲碁,War】 (636ﾚｽ)
【オセロ,将棋】ボードゲーム Part3【囲碁,War】 http://mevius.5ch.net/test/read.cgi/gamedev/1574503798/
上
下
前次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
抽出解除
必死ﾁｪｯｶｰ(本家)
(べ)
自ID
ﾚｽ栞
あぼーん
ﾘﾛｰﾄﾞ規制
です｡10分ほどで解除するので､
他のﾌﾞﾗｳｻﾞ
へ避難してください｡
296: 310 [sage] 2020/05/18(月) 21:57:15.59 ID:lyHQ6R5E Hash関数変更 DBのハッシュキーの効率が悪かったので、ちょっと考えてみた。 今まではshuffle_epi8でバイト単位シャッフルしていたのを、BMIのpextでビット単位の シャッフルと、rotateしたものを、xorでまとめていく方法。以前よりは、ちょっと良くなった 気がする。 何をもってよくなったかの指標が欲しくなり、ネットを探索したけど、数値指標みたいなの は見つからない。確率論の誕生日問題の反対みたいな状況なのでしばらく考えてみる。 要するに、１万人くらいの生徒がいる学校で、誰一人誕生日ではない日が何％くらい存在 するのかという類の問題です。 また、そう考えてみると、現状では直観よりかなり未使用キーが多い気がしています。 xorを繰り返してビットのオンオフをすると、いずれ立っているビット数が３２個を平均と した正規分布（二項分布）になって、一様分布にならないのではないかという疑念が。 正規分布だと、中央に近いところは重複しやすく、立っているビット数が０とか６４とか の出現確率が下がる事になります。xor繰り返すと正規分布に本当に近づいていくのか、 ちょっと検証してみたい。 http://mevius.5ch.net/test/read.cgi/gamedev/1574503798/296
297: 310 [sage] 2020/05/18(月) 22:17:24.43 ID:lyHQ6R5E DBの件 たぶんあるだろうとネットで検索してみたら、Kyoto Cabinetなるキーバリュー型の 簡易DBライブラリがある事が判明。ほかにもLevelDBとか、何種類かあるみたい。 RDB使うまでもないけど、データ量が多いとメモリーだとリソース勿体ないみたいな。 やはりみんな考える事は一緒だなと。せっかくなので導入の方向で検討。 DBの速度問題 また、おそらく１棋譜単位でのBook更新は速度的に問題ないのですが、DAG（合流） 時に、棋譜外の合流元の方の更新がされないという問題があり、学習前に一括で 再構築しています。この一括更新が件数の関係ですごく時間がかかる事が問題です。 一応、１棋譜単位で更新した時に、DAG分もちゃんと処理するロジックを検討中です。 バグさえなければ速度問題はかなり解消できるはず。とはいえ、何回もループを回す 処理となるため、速度に自信なし。 http://mevius.5ch.net/test/read.cgi/gamedev/1574503798/297
298: 310 [sage] 2020/05/18(月) 23:50:13.18 ID:lyHQ6R5E DBの件… 確定探索の時にはメモリーに確定分だけおいとくと考えていましたが、 今件数確認したらおよそ２／３は確定分として確保しなきゃならない 事に気づきました（汗 棋譜作成時はメモリーでやるしかないかも。 １棋譜更新でのDAG問題回避はやりたいかな。 Book再構築にだいたい２０分くらいかかる。 DAG回避で１棋譜分更新するのが１秒として１０００棋譜追加でおよそ１６分。 これ以下の時間で済むならやる価値ありそう。 http://mevius.5ch.net/test/read.cgi/gamedev/1574503798/298
ﾒﾓ帳
(0/65535文字)
上
下
前次
1-
新
書
関
写
板
覧
索
設
栞
歴
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.022s