象歩将棋

315 shu 2005/11/19 01:39 id: 3BVR6NRi4pQ prob: 1.9%: >>314 インデクスとはオブジェクトにおけるシリアライズのことでは
そうそう、最近の言語で実装されてる。
ただ一般的なシリアライズだと無駄が多いのも事実。
たとえば C++ クラスのデータ部がそのままインデクスになれば良いと思うし、
python あたりならお好みでシリアライズメソッドを実装できるかもしれない(試してません)。

>>かなり制約された世界でしか通用しない
既存のソフトは条件分岐の化け物のような気がするし、
ボナンザはその反対に大きなインデクス空間で勝負してるらしい。
僕はそれらとは違うものを作りたい。

>>明日は観光
どうぞ光を観て来てください。観音様拝めると良いですね^^

314 pon 2005/11/18 23:26 id: 480oHczCgMM prob: 5.0%: >>312　補足です
恐らくインデクスとはオブジェクトにおけるシリアライズのことではないですか？
シリアライズされた結果もしくはシリアライズ処理そのものにあるアルゴリズムで変換することを指していると思います。もしそうだとすれば仮に局面の数が有限としても２のN乗で収まるかどうかがポイントになるわけですが、ということはかなり制約された世界で
しか通用しない処理（性能はだせるでしょう）になりますか。
（全然的外れのときはm(__)m）
連続王手の話だけに限れば、今の仕様でも少しだけいじればオブジェクト比較できると思いますので、兎に角やってみます。
明日は観光ですので近いうちに・・・

313 pon 2005/11/18 21:51 id: 480oHczCgMM prob: 13.6%: >>312
ところでこのページ（一般になんて呼ぶのかいまだによくわかりません）も雰囲気がでてきましたね。

修ちゃんのいうDBとは概念的な話ですね。それをメモリで実装しようがディスクでやろうがかまわないという。また、そういうツールもあるのでしょうね。
考えてみると将棋ではその局面-実際はコンポーネントで構成される-がどのような経緯で出現したものであろうとお構いなく、最短手順で玉を詰ませればお役ゴメン。つまり対局とは"局面の集合である"という定義は、現在の（コンピュータ）リソースを無視すれ
ば面白い考え方かもしれません。
そして局面間でベクトル的に近いとか遠いとかのメトリクスを持たせることができればさらに面白い。
ていうかそんなことばかり考えていては日が暮れますので^^;

312 shu 2005/11/17 23:06 id: 3BVR6NRi4pQ prob: 0.2%: >>311
突き詰めれば局面データベースの話だと思います。
既存のDBから類推すれば検索やソートなどが必要な機能になると思われます。
このとき必要なのがインデクスですが、オブジェクトに対して可逆的なキーを作ればいろいろ使い回しできます。
局面を可逆的でかつ有意なインデクスにマッピングすることは、実装において一つの胆だと考えてます。

ただし *同一局面で無い* ことを判定するには少し冗長です。
インデクスをハッシュ値に変換すれば、(ヒットしない == 同一局面で無い)ことが光速＆高確率で得られます。
千日手の判定で少し得するんでは無いかい、とか云う話。それだけです。

魔法の杖は探してますが、残念ながらまだ見付かりません。

311 pon 2005/11/17 00:09 id: 480oHczCgMM prob: 0.5%: >310
全然勘違いでした。
局面のハッシュ値を生成するのも、オブジェクト比較と処理的に変わりがありません。
Javaではうまく設計すればオブジェクト比較だけで済みそうなので、コードが楽です。
ハッシュ値だと計算時に多分回さないとだめではないですか？
処理時間は少し上がるかもしれませんね。
魔法の杖かと一瞬喜んだのですが・・・；；
それともパイソンでは魔法の杖があるのでしょうか？
その局面が同一であるかの判断は、どうしてもその中身を見るしか方法はないはずでしょう。
等しいかどうかの判断に事前に処理済みの結果（ハッシュ値）を使うかだけの違いしか
ないように思うのですが・・・

310 pon 2005/11/16 20:51 id: 480oHczCgMM prob: 1.0%: >309局面のハッシュ値を保存して無いってことですか?
あっ、知らない内に必要性があってやってました。^^;
その方がもっと簡単ですね。
ラベルひくーい、シェシェm(__)m

309 shu 2005/11/16 01:14 id: 3BVR6NRi4pQ prob: 0.1%: >>308 ルールは全部教えたつもり
すんごいね^^
負けそうです_(.".)_

>>単純なオブジェクト比較でできない
局面のハッシュ値を保存して無いってことですか?
# うちもしてないけど;;

JAVA なら適当にでっちあげれば良さそうな気もする。。。
リファクタリングする前に一応の形を作った方が楽かも。
# 釈迦になんとか;;

308 pon 2005/11/16 00:15 id: 480oHczCgMM prob: 1.2%: >307
"同一局面連続王手4回"は仕様は簡単ですが、今の仕様では単純なオブジェクト比較で
できないので手間がかかることがわかりました。全体のコードが乱れそうなので、また
どこかでリファクタかけてからやることにします。
これでルールは全部教えたつもりです。（もっとスリムにした～い）

307 anonymous 2005/11/16 00:03 id: ulI1lBqN6AQ prob: 16.7%: 5.合駒利かず

第009手目: 手番=先手, X=2,Y=2,駒=馬,　(王手!)X=3,Y=2,駒=王
第017手目: 手番=先手, X=2,Y=4,駒=飛,　(王手!)X=2,Y=2,駒=王
第031手目: 手番=先手, X=1,Y=4,駒=飛,　(王手!)X=1,Y=2,駒=王
★★★★★★★★★★★★★★★★★
★　詰み!!：X=1,Y=2,駒=王
★★★★★★★★★★★★★★★★★

処理時間：131ミリ秒

手合割：平手
第031手目: 手番=先手, X=1,Y=4,駒=飛

   9    8    7    6    5    4    3    2    1
+----+----+----+----+----+----+----+----+----+
|香↓|桂↓|銀↓|    |    |    |    |銀↓|香↓| 一
+----+----+----+----+----+----+----+----+----+
|    |    |    |金↓|    |    |金↓|飛↓|王↓| 二
+----+----+----+----+----+----+----+----+----+
|歩↓|歩↓|歩↓|歩↓|歩↓|歩↓|桂↓|歩↓|    | 三
+----+----+----+----+----+----+----+----+----+
|    |    |    |    |    |    |    |    |飛↑| 四
+----+----+----+----+----+----+----+----+----+
|    |    |    |    |    |    |    |桂↑|歩↓| 五
+----+----+----+----+----+----+----+----+----+
|    |    |歩↑|    |    |    |    |    |    | 六
+----+----+----+----+----+----+----+----+----+
|歩↑|歩↑|銀↑|歩↑|歩↑|歩↑|歩↑|    |    | 七
+----+----+----+----+----+----+----+----+----+
|    |    |金↑|    |    |    |金↑|    |    | 八
+----+----+----+----+----+----+----+----+----+
|香↑|桂↑|    |    |王↑|    |銀↑|    |香↑| 九
+----+----+----+----+----+----+----+----+----+

----------- 駒台：先手 () ----------
角歩x2
----------- 駒台：後手 () ----------
角歩

306 shu 2005/11/14 23:29 id: 3BVR6NRi4pQ prob: 1.8%: >>305 Windows系はやはりだめですか
でしょうね;;
>>304 性能を見ます
面白くなって来ました^^

ポンちゃんは双玉で試してるみたいなので期待してます。
こちらも詰将棋専科じゃなくて実戦向きにしたいと考えてます。
終盤をうまく作れれば、半ばできあがりなのかもしれませんね。