象歩将棋

450 shu 2008/04/10 21:03 id: 3BVR6NRi4pQ prob: 1.4%: 作戦を継続するには一筆書きでは困難。
ノードをばらし評価関数導入することが必要になります。
処理速度は一億手/100秒くらい出てるので計算する手数を減らす戦略。

ひとつのノード {手、評価値、上位へのポインタ、局面コンテキスト} で 24byte 必要。
とすると直線的には一億手で約 2GB くらいのメモリが必要ですが。Φ

449 shu 2008/04/08 21:47 id: 3BVR6NRi4pQ prob: 0.9%: プロローグ
詰将棋も平手将棋と同じく無限性を考慮すれば、
詰む確率、詰まない確率の評価が重要なのでしょう。

今回はビット演算を利用して実装してみましたけれど、
ロジックは C++ ソースコードの中に直書きされて居るので、発展性がありません。
とはいえ内部処理は集合演算そのものなので汎用化する道はあります。
たとえば必要な要素をプリミティブなオブジェクトなり演算子として実装し直すとか。

サンプルとして、詰みが成立する局面のことを考えてみると、
--
1) 攻め駒が一枚だけで詰みとなる場合は、
  必要条件: K ⊆ *Br
    (玉 K には攻め方の駒 Br が利いてること)
  十分条件: ?K == φ AND (K...Br] ⊄ Σ*Wi
    (玉 K は移動できない、かつ攻め方の駒 Br までの範囲に玉方の駒が利かないこと)

2) 攻め駒が二枚以上で詰みとなる場合は (1) に加え
  必要条件: K ⊆ *Bx AND Bx ⊆ *By
    (玉 K には攻め方の駒 Bx が利いてる、かつ Bx に味方の駒 By が利いていること)
  十分条件: ?K == φ AND (K...Bx] ⊄ Σ*Wi (ただし Wi は K を含まない)
    (玉 K は移動できない、かつ攻め方の駒 Bx までの範囲に玉以外の玉方の駒が利かないこと)

# K は位置、*K は利き位置の集合、?K は移動可能位置の集合を意味します。
# 正確でも厳密な記述でもありませんので、余計なことで悩まないでください。(空き王手ははぶいてるし)

448 shu 2008/04/07 21:42 id: 3BVR6NRi4pQ prob: 3.0%: 速度の比較
参考までに詰パラ二月の懸賞問題で実行してみた。
Pentium4 2.8EG: 5.30 秒
Athlon64x2 3800: 1.05 秒
Athlon64 3700+: 0.95 秒
(1,095,025 局面)
残念ながら、現在のWEB鯖 (Pen3 800EB) に乗せるのは無理みたい。
ならば当面 Athlon64 3700+ を将棋鯖に改造するしかないかの。

447 shu 2008/04/06 22:32 id: 3BVR6NRi4pQ prob: 0.7%: たどり着いてやはり麓
先手は"詰むや"の評価が必要。
後手は"詰まざるや"の評価が必要。
今はほとんど使って無いメモリの有効利用が扉を開く鍵となるのであろうか?
たとえば、先後の候補手が 1/3 の範囲に収まるだけで極めて効率が良くなるのは想像できる。

http://www.geocities.jp/k_7ro/
http://www005.upp.so-net.ne.jp/tsumepara/contents/4appre/mc/...
その過程でミクロコスモスが解ければ嬉しいとは思うけど、
本当の敵はポン能寺なので、うまく立回らないといけない。

446 shu 2008/04/06 21:28 id: 3BVR6NRi4pQ prob: 0.1%: 二歩と打歩詰ルールを追加。
千日手や無駄な合駒は探索中に考えれば良いことだし、
そもそも正解手順には現れない(ように設定できる)。
また持将棋ルールは詰将棋に関係ない。
と云うことで必要なルールはすべて実装できたみたい。
ソースは C++ で 3,840 行。

445 shu 2008/04/05 21:36 id: 3BVR6NRi4pQ prob: 0.7%: 無双第一番が解けない。
カンニングして正解手順を６手進めたところから探索。

▲３三竜 △５二玉 (正解は同玉) ▲５三金 △同桂 ▲同角成 △４一玉
▲３二竜 △同玉 ▲３一飛 △２三玉 ▲２一飛 △３二玉
▲２四桂 △２一玉 ▲３三桂 △１一玉 ▲１二香までの１７手詰め (+６手)。

100,147,641局面 / 110秒 (消費メモリは約1MB)

やはり手の優先順位の影響が大きいようです。たとえば攻め方は成る手を優先するとかはあたりまえですね;;
案の定、喜びの次の日には厚い壁が立ちはだかってましたが、これでやっと扉をさがす旅に出られます。

実装として一億手余りまでは馬鹿読みながら可能なことは確認できました (いや驚いたね;;)。
数年後には一秒で一億と四手を読むことが現実になるのだろうなぁー

444 shu 2008/04/04 21:25 id: 3BVR6NRi4pQ prob: 0.1%: 詰将棋パラダイスの作品で試してみた
三月の懸賞詰将棋 (江部健氏作)
http://www005.upp.so-net.ne.jp/tsumepara/
11手詰め: 357,723局面/0.408秒
左に逃して詰めたのはご愛嬌;;

二月の懸賞詰将棋 (岡部雄二氏作)
http://www005.upp.so-net.ne.jp/tsumepara/contents/3problem/p...
11手詰め: 3,697,597局面/4.412秒

サンプルコード:
...
    GShogiApp g("P43P31G33p35K12P14~RBS3N4L4Pd/R42S32P23~BG3");
    const CDiagram& d = g.getDiag();
    GPuzzle z(d);
    z.solve(11);
...
出力結果:
P2223+ K2212 G12 K1222 B34 R23 G22 K2212 S2332+ K1122 G12
合駒の優先順序が高いので;;

処理の不備は今のところ多いけど、基本的に使えると思う。
いろんな作品で試したくてワクワクしてきました。こらえ切れずに＼(^o^)／ヤッター
http://toybox.tea-nifty.com/memo/2005/05/post_3535.html#nank...
http://www.ne.jp/asahi/tetsu/toybox/kenkyu/cho1999-9.htm

443 shu 2008/04/03 23:10 id: 3BVR6NRi4pQ prob: 4.4%: ツリー探索を試してみた。
題材はいつもの「流鏑馬一番」七手詰めです。
局面生成、{局面コピー、ツリー探索} を繰り返して、約 1,000 回 / 秒。

一回の探索で 1,600 局面くらい現れるので、推定 160 万局面 / 秒。
詰将棋なのでやや不満な数値ですが、初回としてはまずまずですかね;;
消費メモリ 1〜2MB、ソースコード 3,789 行。
パラレルワールドに少し期待してる。

442 shu 2008/03/30 23:29 id: 3BVR6NRi4pQ prob: 4.4%: リファクタリング
今は一局面をいろいろ静的に400ビットくらいで持ってます。
それとは別にツリー探索処理の途中、動的に200ビット/局面くらい消費しています。

無駄をはぶいて、なんとか100ビット以下にしてみたのだけど、なぜか不安な気がします。
別に余計なことしてるとは思わないけど、
ほんとうの私は、実はプログラマに向いて無いんじゃないかと思う?;;

441 shu 2008/03/29 22:59 id: 3BVR6NRi4pQ prob: 1.7%: 空き王手

手の抽出はビット演算を利用するとロジックがとても簡単になる。
実装したところパラレルワールドなのでループ制御文がほとんど無い。
今夜あたりツリー探索を作れば、うんと速い詰将棋マシンができるだろう^^
と思ったところで、また悪魔の囁きが聞こえてきた。

やはり抽象的なモデルが必要なのではないのかな。
心の中で誰かがそう叫んでる。でんでん;;
いろんな見方を得たい時にはなるべくシンプルなモデルの方が便利。
それはまたクロスでデバッグやテストするにも都合が良いのだ。