ツリー探索を試してみた。
題材はいつもの「流鏑馬一番」七手詰めです。
局面生成、{局面コピー、ツリー探索} を繰り返して、約 1,000 回 / 秒。
一回の探索で 1,600 局面くらい現れるので、推定 160 万局面 / 秒。
詰将棋なのでやや不満な数値ですが、初回としてはまずまずですかね;;
消費メモリ 1〜2MB、ソースコード 3,789 行。
パラレルワールドに少し期待してる。
象歩将棋
Webと将棋で何か具体的なもの作って行こうとしてます。
リファクタリング
今は一局面をいろいろ静的に400ビットくらいで持ってます。
それとは別にツリー探索処理の途中、動的に200ビット/局面くらい消費しています。
無駄をはぶいて、なんとか100ビット以下にしてみたのだけど、なぜか不安な気がします。
別に余計なことしてるとは思わないけど、
ほんとうの私は、実はプログラマに向いて無いんじゃないかと思う?;;
空き王手
手の抽出はビット演算を利用するとロジックがとても簡単になる。
実装したところパラレルワールドなのでループ制御文がほとんど無い。
今夜あたりツリー探索を作れば、うんと速い詰将棋マシンができるだろう^^
と思ったところで、また悪魔の囁きが聞こえてきた。
やはり抽象的なモデルが必要なのではないのかな。
心の中で誰かがそう叫んでる。でんでん;;
いろんな見方を得たい時にはなるべくシンプルなモデルの方が便利。
それはまたクロスでデバッグやテストするにも都合が良いのだ。
後手番
まだツリー探索すら考えて無くて、今は地道に手の抽出処理をしてます。
図は▲６四角の局面
後手番で△４二歩打、△５三歩打、または△４二金を抽出できました。
盤面以下むりやり △４二金、▲４一銀成と進め、
その局面で探索すると無事に △４一銀のみ抽出できました。
もしかして空き王手関連はうまく処理できてるのかもしれません。
後手番の処理は以前 (PyZumeのころ) は先手の処理より一桁多くなっていましたが、
今回は先手の倍くらいですみそうな気がしてます。
空き王手の処理完了
現在2500行、次は後手番。
葛湯溶いてるみたい。始め粘って、あとはさらさら。
脳内実験は終了
空き王手の目途はついたと思う。単純木探査でたぶん3800行、100万手/秒くらい。
不思議と云うか自然なのか解らんけど、副作用で後手番の問題も解けたみたい。
二歩、打ち歩詰、無駄な合駒、千日手などは後付け。
メモもとって無いので明日が怖い。
> 答えがでていると
もう答えは出ているかもしれませんね。
今回は単純なプログラミング技術のみ追求しています。
仕様は決まっているのに、うまいコードが描けない。
そこにこだわりたくなるのがプログラマだと思います。
まあドンキーなのはバレているのでしょうが;;
>435
答えがでていると物事を鵜呑みにする人で
幸せになれた人はいません。
>すべてビット演算でまかなおう
＝数式で近似しよう
≒数式を勉強し直そう
＝線形代数を勉強し直そう
＞寿命＝呑み直そう＾＾
知りあいに、5手詰めの切り抜きを机の額に飾っていた人がいました。
どうしてそんな一目の詰め将棋を飾っているのか、最初はどうしても
意味がわからなかったのですが、
今から思うと、将棋を知らない人がどう思うかを重視していたようにも
思えます。
人生楽しんだ方が得ですね。
> やっぱり先は長い
そうでも無いかも
手を抽出する処理過程に条件クラスを追加しました。リファクタリングしただけとも云う;;
1) ルール上合法な手に制限する
2) 王手のみ選択する
3) 王手を解除する手のみ選択する
などを条件クラス化。ただし(3)は今は形だけ。
シンプルになったので、思いついた時に作業できます。
手の意味についてはペンディング。