象歩将棋

427 shu 2008/02/22 22:10 id: 3BVR6NRi4pQ prob: 3.2%: 線と面
詰将棋の場合、たとえば PyZume は線を一筆書きにたどって行くのだけど、
現実的には途中で打ち切ることが必要なので麺になる。
スパゲッティじゃ長すぎるとすると、どの程度の長さが適切なのだろう。

たとえば三手とか、あるいは七手。その理由は?
三手: 故) 原田先生の有名なお言葉。
七手: 米長先生「とりあえずこのくらいは一瞬で読む」と言われた。
可変: ボナンザ先生?

ちなみに我が家はディ・チェコ No.11 のバジリコ味が好み。
http://www.nisshin.com/product/de_cecco/

426 shu 2008/02/21 22:35 id: 3BVR6NRi4pQ prob: 0.3%: 何も解らん
今作ってるのは "425> DBエンジン" 的な部分なのかな。
まあルールを含めそのようなものを作ってます。
このレイアはループや分岐の少ない単純なロジックを心がけて居ります。
どんどん速くなる期待感がありますね。たとえば、
http://www.sgi.co.jp/newsroom/press_releases/2008/feb/asteri...
http://developer.amd.com/tools/apl/Pages/default.aspx

> コアな部分だけCPUリソースでロジックを走らせる戦術
こっちは扉の向こう。構想を夢想するのみで何もしてません。
レイアを分ける必要性だけは解ります。
自分で作るつもりなので、何も見てません。
他の人のアイディアがあっても、今は私に教えないでください m(.".)m
でもポンちゃんの話は参考になります。

425 pon 2008/02/21 12:36 id: ou/hhkgTDac prob: 41.1%: ■思考エンジンについて
考えてみれば、簿何座は次のポリシーで実装したものと思われます。
　１．DBエンジンに抽出を任せる
　２．選択ロジックを実装する（CPU使用）
　３．DB情報にフィードバックする
　４．将棋ルール等は某氏のソースをそのまま使用
ポイントは、DBのリソースのフル活用により、（実際はDBではありませんが）
　・機能間の疎結合化
　・CPUの負荷の軽減化
を図り、コアな部分だけCPUリソースでロジックを走らせる戦術により
高速化を図っている事だと思います。
・・・To Be continued

424 shu 2008/02/21 00:13 id: 3BVR6NRi4pQ prob: 0.2%: > ルール（ロジック）はどのクラスに実装されていますか
駒の動きは128ビットクラスで実装する。
驚くほどシンプルに実装できる。駒の機能は本質的にグラフィカルなためかな?
汎用駒クラスのインスタンスに関数ポインタを一個持たせるだけ。
ループとか条件分岐をあまり使わずに実装できそう。

> 思考エンジン以外はインターフェースを作れば、実装は誰が行っても速ければよい
そう思います。2015年までには128ビットデータ処理マシンが誕生してると思うので、
そうなれば今の128ビットクラスは不要になり、性能も二桁くらい向上するかも。
IPv4 枯渇とか、暗号化問題とかあるので、そのからみでたぶん実現されると思ってますが?...

> インターフェースが綺麗なら思考エンジンの作成がより楽
水平思考や垂直思考、私はどう考えたら良いか解りません。
とりあえず詰将棋やりながら考えてみます。
逆に序盤戦を考えるのが一つのヒントになるのかもしれません。

423 shu 2008/02/15 22:08 id: 3BVR6NRi4pQ prob: 0.0%: > ルール（ロジック）はどのクラスに実装されていますか
将棋盤でも駒クラスでもありません
盤と駒の配置を元に、次の手イテレータ CMovesIter を生成します。
CMovesIter は指手の駒単位に set を返すクラスです。
ルールは set の制約条件として実装するつもりです。

要はプログラム的に必要になった時点で判断するということですが、
"あとで指せる手はあとまわしにしましょう、という考え方"
とかと妙に符合しておもしろい。
http://d.hatena.ne.jp/umedamochio/20080210

> インターフェースが綺麗なら思考エンジンの作成がより楽
小山に登ってみたら、まずその辺を見渡すのが良いのでしょう。
好みのインタープリタが欲しいなと少し思ってます。

追記:
ルールへのポインタは駒クラスに置いてあります。

422 pon 2008/02/15 12:43 id: ou/hhkgTDac prob: 0.6%: >↓ C++で普通に9x9ボードクラスを作り、駒の移動はポインタで実装 ← 今ここ
抽象化の話しですが、駒の移動（移動可否の判断）はボードクラスが持つのでしょうか。
移動可否を判断するためには、ルールに判断を委譲することになります。
現在、ルール（ロジック）はどのクラスに実装されていますか。

恐らく、思考エンジン以外はインターフェースを作れば、実装は誰が行っても速ければよい
ということになると思います。
インターフェースが綺麗なら思考エンジンの作成がより楽になるのでしょう。
思考エンジンこそ抽象化の出番なんでしょうが、扉が見えてきません。
半年ほどやってませんし、この先もなかなか・・・　修ちゃんに期待してます。

421 shu 2008/02/14 22:06 id: 3BVR6NRi4pQ prob: 0.1%: 駒の移動方法
↓ Cで関数ポインタ使って、その場その場でいろいろ (煩雑で失敗作かも)
↓ Python で駒クラスを作り、そのオブジェクトにルールを持たせた (PyZume)
↓ Cで静的なテーブルにルールをすべて持たせた (まあ速い)
↓ Cでビットテーブルとビット演算で処理 (少し速い)
↓ C++で普通に9x9ボードクラスを作り、駒の移動はポインタで実装 ← 今ここ

さて、いよいよ局面探索の「第一の扉」を開けそうです^^
「扉の向こうに待ち受けるのは奇跡か、それとも破滅か!?」 ... なんて

420 shu 2008/02/14 21:25 id: 3BVR6NRi4pQ prob: 4.6%: 第33期棋王戦サイト
棋譜ブラウザで見られました。感謝^^
http://www.kyoto-np.co.jp/shogi2008/kiousen33-1.kif
107手目▲23飛成で佐藤の玉が詰んでるように見えたんだけど、
▽22角で逆王手でした;;

419 shu 2008/02/13 23:00 id: 3BVR6NRi4pQ prob: 1.7%: >たった千行に
小高い丘に立って見ましょう
そこに私は居ません;;
まず PyZume に rush かけてます。
Do not stand at my codes and weep.

ところで第33期棋王戦サイト
http://www.kyoto-np.co.jp/shogi2008/
Java と JavaScript 併用なので見られません。
ラッシュ佐藤と羽生、観戦出来ないのは残念。