亀の歩み 再帰探索処理をデータ保存クラスと探索処理クラスに分離、 ツリーの三色塗り分け問題にまでは到達できた。 反復深化法での処理を組み込み中。 4,716行

盤面の圧縮値 今回のプログラムは盤面のビットマップを常に保持してるので、安直にそれを再利用。 手順のハッシュと局面のハッシュは交差するのではないかと云う願望です。 # 実はそれらは同じものだったなんて結論。ってことはなかった。 駒の配置は9x9x2ビット空間に収めてあるので、OR演算で四つ折りに畳み込んで5x5=25ビット。 今のところ良く働いてるみたい。だけど下位8ビットだけ取り出しても結果に変化は無いようです;; Zobrist ハッシュキーの方が良くできてるので、盤面値の出来はあまり関係無いのかも。 わたしゃ数学的評価はできめるせんぬ;; Zobrist キーを利用した探索では異なる局面を同一と判断する可能性が(わずかでも)常にあるので、 詰め手順を求めた後に検算するとか、うまい方法を考えないといけないのであろう。 ここにも「手の発見」と「手の評価」と云うテーマが現れる。

> 459 なんかハッシュの効率悪そう。 Zobrist キーは高効率でした;; 単純な同一局面判定処理を追加して試したところ判明。 嘘ついてごめんなさい m(.".)m たとえば、以下は「無双一番」を13手まで馬鹿読みした結果。 探索局面総数: 28,483,070 未解決局面数: 12,088,478 ハッシュ配列のサイズ: 16,777,216 ハッシュ配列の利用数: 7,585,301 (45.21%) 同一索引・同一局面数: 20,896,372 同一索引・相違局面数: 1,397 ハッシュキーの配列が50%近く埋まってきてもコンフリクトする確率は小さい。 そして重複局面が多いのは千日手模様の繰り返しからなる局面が原因らしい。 とすると、そろそろノードの判定値を保存して反復深化処理を試してみても良さそう。 現在のソースは 4,496 行。

局面ハッシュも必要かな 指し手のハッシュキーはかなり重複があります。 11手詰めくらいでも約半分重なっています。 本当の恩恵を授かるのはまだ先のことなのでしょう。 局面ハッシュ併用した場合、キーの重複はかなり減るか? それならば残ったものは探索処理を利用して同一局面判定すれば良いと思う。 心配なのは本来同一局面は頻発するものではないかと云うこと。 この辺は試してみないと私には解りません。 無駄な合駒処理のためには、持ち駒情報も必要になりそうです。 とりあえず正攻法で考えてるつもり。

なんかハッシュの効率悪そう。 ツリー探索自体はまあ高速にできるので、注目すべきは同一局面の判定かなー あーだこーだと夜もふける。 考え処ですね;; 長考宣言...

だんだん解って来たかも 乱数は駒移動じゃなく、ある位置の駒の追加/消滅で作るのだろう。 それなら同一局面で同じハッシュキーになりそう。 {局面が同じ=>ハッシュ値が同じ} ならロジックを作れる。 一方、局面のインデクスは情報を落とさないで45バイトで実装した。 局面←→索引の変換は、とりあえずそれで良しとしよう。 この辺は性能に影響するので下手な圧縮はできない。(アイディアが無いとも云う) しばらくはハッシュ値の評価をしてみようと思う。

> 充分コストするはず とりあえず局面情報作成からかな。 普通のhashクラスを作り、試しに局面を文字列化したものを登録してみた。 "無双第一番"で11手目まで探索すると、 探索局面数: 4,057,922 重複登録数: 2,173,987 やはり探索の途中でも半分は重複局面。 てことで、 1) 局面→索引→圧縮キー 2) 探索ノード→ノード空間管理クラス 3) ノード探索処理 まで実装すれば全幅探索ができる。後はその結果を見て考えることにしよう。 また、この辺は丁寧にこしらえて損は無いところ。 > あと20年もあれば、美しさを堪能できるのですが かの大国の大統領は現世で美を堪能なされてるようです;;

>454 いえ、そうだと思ってました。 人類がまだパイの計算にてまどっていることを考えれば 性能の制約は充分コストするはずです。＾＾ >455 メルセンヌは確か素数で有名な人ですよね。 修ちゃんが数学を知っているとは知りませんでした。m(__)m 時間があと20年もあれば、美しさを堪能できるのですが・・・

メルセンヌ・ツイスタ http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/mt.html http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/mt64.html http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/index-jp.html 良い乱数・悪い乱数 http://www001.upp.so-net.ne.jp/isaku/rand.html XorShift http://www.jstatsoft.org/v08/i14/ unsigned long xor128(){ static unsigned long x=123456789,y=362436069,z=521288629,w=88675123; unsigned long t; t=(x^(x<<11));x=y;y=z;z=w; return( w=(w^(w>>19))^(t^(t>>8)) ); } #備忘録

性能だけ考えてます(爆 申し訳無い。(>>451, >>452) の記事は人を惑わすだけだと思いました;; 実際、今私の脳内が混乱してます(笑 [モデル-1] 局面集合を辞書 S{キー値、局面情報} で持ち、局面探索機能は一個のオブジェクトが持ちます。 XOR 演算を利用すると、ある局面 Si から次の局面に遷移するには乱数 Ri を用いて、 Si+1 = Si ^ Ri で済みます。乱数 Ri はあらかじめ計算して置くことができるので、 うまく値を設定すれば S1,2,....n が広く分散し、辞書のキーに使えるのではないかと云うこと。 つまり、Ri の選択と Si ^ Ri 演算だけで高速にノード間を渡り歩くことができると云うことらしい。 この場合、たとえばキーを 64bit 局面情報を 64bit とすると、一億局面を収めるには、 (64 + 64) * 100,000,000 = 12,800,000,000 = 12.8Gbit = 1.6GB 必要になる。 そして同一局面であることを判断するには局面情報の比較が必要となる。 [モデル-2] ひょっとしてキーで局面も表現できるのではないかと考えました。 そうすれば局面集合は S[キー値] の配列で表現できます。 例えば玉を K11→K22 と移動するとき、K11→K12→K22 と K11→K22 を考えてみます。 ここで R(11,22) = R(11,12) ^ R(12,22) とすれば K22 = K11 ^ R(11,12) ^ R(12,22) と K22 = K11 ^ R(11,22) は同じことです。 てことで乱数をうまく設定できるのならばキー値は局面を表すことになり、 1) 配列要素に局面情報は入れずノードの状態のみ2bitで表すとすれば一億局面25MBですむ。 2) 同一局面であることを判断するにはキー値を直接比較すれば良い。 なんて都合の良いことを妄想していました。てことで、あくまで妄想です。。。(孟宗竹は美味い^^)