象歩将棋Webと将棋で何か具体的なもの作って行こうとしてます。探索モジュールをじっと見るすると脳内で再帰処理のシミュレーションが始まる。しだいに脳が再帰処理と同化して行くのが分かる。処理の一部を変更しただけですべてが変わる。フェルンデクライス・メソッドとかに通じるものがあったりするのだろうか。今回は紙と鉛筆を禁止してるので、しばらくは脳内で遊ぶことにしよう。0.4%亀の歩み再帰探索処理をデータ保存クラスと探索処理クラスに分離、ツリーの三色塗り分け問題にまでは到達できた。反復深化法での処理を組み込み中。今回のプログラムは盤面のビットマップを常に保持してるので、安直にそれを再利用。手順のハッシュと局面のハッシュは交差するのではないかと云う願望です。実はそれらは同じものだったなんて結論。駒の配置は9x9x2ビット空間に収めてあるので、OR演算で四つ折りに畳み込んで5x5=25ビット。今のところ良く働いてるみたい。ハッシュキーの方が良くできてるので、盤面値の出来はあまり関係無いのかも。詰め手順を求めた後に検算するとか、うまい方法を考えないといけないのであろう。ここにも「手の発見」と「手の評価」と云うテーマが現れる。なんかハッシュの効率悪そう。キーは高効率でした;;単純な同一局面判定処理を追加して試したところ判明。1,397ハッシュキーの配列が50%近く埋まってきてもコンフリクトする確率は小さい。重複局面が多いのは千日手模様の繰り返しからなる局面が原因らしい。すると、そろそろノードの判定値を保存して反復深化処理を試してみても良さそう。0.0%局面ハッシュも必要かな指し手のハッシュキーはかなり重複があります。11手詰めくらいでも約半分重なっています。本当の恩恵を授かるのはまだ先のことなのでしょう。局面ハッシュ併用した場合、キーの重複はかなり減るか?それならば残ったものは探索処理を利用して同一局面判定すれば良いと思う。心配なのは本来同一局面は頻発するものではないかと云うこと。この辺は試してみないと私には解りません。無駄な合駒処理のためには、持ち駒情報も必要になりそうです。正攻法で考えてるつもり。7.3%なんかハッシュの効率悪そう。ツリー探索自体はまあ高速にできるので、注目すべきは同一局面の判定かなーあーだこーだと夜もふける。0.0%だんだん解って来たかも乱数は駒移動じゃなく、ある位置の駒の追加/消滅で作るのだろう。それなら同一局面で同じハッシュキーになりそう。局面のインデクスは情報を落とさないで45バイトで実装した。局面←→索引の変換は、とりあえずそれで良しとしよう。この辺は性能に影響するので下手な圧縮はできない。(アイディアが無いとも云う)しばらくはハッシュ値の評価をしてみようと思う。コストするはずとりあえず局面情報作成からかな。普通のhashクラスを作り、試しに局面を文字列化したものを登録してみた。2,173,987やはり探索の途中でも半分は重複局面。ノード探索処理まで実装すれば全幅探索ができる。後はその結果を見て考えることにしよう。この辺は丁寧にこしらえて損は無いところ。0.4%>454いえ、そうだと思ってました。人類がまだパイの計算にてまどっていることを考えれば性能の制約は充分コストするはずです。^^>455メルセンヌは確か素数で有名な人ですよね。修ちゃんが数学を知っているとは知りませんでした。2002/10/26.。