象歩将棋

Webと将棋で何か具体的なもの作って行こうとしてます。

317  shu  2005/11/30 23:16 id: 3BVR6NRi4pQ  prob: 9.7%

見知らぬ方から11手詰め頂きました。

自然でエレガントで、しかも面白うございます。
ありがとうございました。

実はしばらく前に投稿されていたのですが、
もったいないので、こちらにも載せることに。

316  pon  2005/11/24 23:40 id: ou/hhkgTDac  prob: 0.0%

今日暇で２ちゃん見てたら、どっかのサイトでパクったソースがC#でもGUI抜きで１Kとのことでした。やっぱ自分のは無駄が多すぎるので書き直すことにします。
今さら人まねは嫌なので、大体イメージもつかめたし。
でもしばらくやる気しないので修ちゃんみたいにアイデアだけ考えるモードに入ろうと思います。年っすかね??
ちなみにボナの評価関数は1個だそーです。序盤、中盤、終盤で分けてないらしいっす。

315  shu  2005/11/19 01:39 id: 3BVR6NRi4pQ  prob: 1.9%

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

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

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

314  pon  2005/11/18 23:26 id: ou/hhkgTDac  prob: 5.0%

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

313  pon  2005/11/18 21:51 id: ou/hhkgTDac  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: ou/hhkgTDac  prob: 0.5%

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

310  pon  2005/11/16 20:51 id: ou/hhkgTDac  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: ou/hhkgTDac  prob: 1.2%

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