象歩将棋

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

このまま記事を入力し[投稿する]ボタンを押せば当サイトに送信されます。 以下の文章は注意書きです。

名前はかならず記入してください。ハンドルネームでも構いません。 またパスワードを入力することをお勧めします。 その場合他人による *なりすまし* と区別出来るかもしれません。 さらにブラウザでクッキーを有効に設定してある場合あなたの記事は後で修正可能になります。

コメントスパム防止のため記事の内容を機械的にモデレート (スパムである確率を計算) する処理を通します。 どのような投稿であれ、たまたま計算誤差によりスパムとみなされ 秘密の場所 に収納される可能性があります。 その場合、管理人が手作業で正規の場所に移動しますのでお待ちください。

320  pon  2005/12/03 03:23 id: ou/hhkgTDac  prob: 7.3%

>>異国の地で正月ですか? 
いえいえ迷惑でしょうがもうすぐ帰ります
>>仕事の事情で、今はそれ以上は望めません。
商売繁盛で結構なことで

319  shu  2005/12/01 23:32 id: 3BVR6NRi4pQ  prob: 0.0%

今年は七手詰めで終わりそうです。
でも馬鹿詰め問題の予想解答が七手と云うことで少し安心してます。
理想を言わしてもらうと、プログラムで証明できれば嬉しい。

でも最近は一手詰めの理解を優先してます。
仕事の事情で、今はそれ以上は望めません。
これなら紙や鉛筆が無くても、たとえ電車の中でも考えられますので。

>>一度試してみなければ??
異国の地で正月ですか?

318  pon  2005/12/01 22:56 id: ou/hhkgTDac  prob: 1.6%

残念ながらこの形、中学生のときに本でみますた。
そこがshuさんとの技術の差となって
今日に至ります。
でも今ではきっと逆転しているのでしょう。
一度試してみなければ??

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