象歩将棋

433 shu 2008/03/16 00:46 id: 3BVR6NRi4pQ prob: 2.0%: やっぱり先は長い
すべてビット演算でまかなおうと思ったけど、一般化すると組み合わせ数学的になる。
詰将棋で先手の場合、詰め手の抽出とかいう俺的な検索すれば良い。
ところが後手の立場だとどの駒が効いてるの? とか一から評価しないといけない。
手の意味を付加すべきだろうか?

432 shu 2008/03/11 21:19 id: 3BVR6NRi4pQ prob: 0.0%: コツコツとした良い感じ
着実にソリッドなコードが生産されてく感覚。
駒を動かすルールはC128クラスで実装。
平手戦の一局面の実測値は30万手抽出/1秒。遅いな;;
ルールは静的に持ち、駒クラスの関数が有効手のビット列を返却する。
現在 2,200 行くらいアスファルトに刻む。あぁ

詰めの条件付与もビット処理でおこなう予定。
それで単純ツリー探索は実現するはず。
そこまででライブラリとして最低必要な機能は実装される。ふぅ

431 shu 2008/03/05 20:31 id: 3BVR6NRi4pQ prob: 19.9%: life door
待ち受けるのは奇跡か、それとも破滅か!?

430 pon 2008/03/05 12:38 id: 9r4Opr9Vay6 prob: 50.0%: >life の死活を判断
lifeクラスがlife workになってしまわないようにご注意を

429 shu 2008/03/04 21:59 id: 3BVR6NRi4pQ prob: 0.9%: 着手小局
瓢箪から駒。life というオブジェクトを作ろうと企画。
局所的にあらゆる手をトレースするオブジェクトです。
絵柄的にはミトコンドリアみたいな^^; もしくは紐かも;;

life の目的は短手数を網羅的かつ高速に読むこと。
最初の PyZume は、それを部分的に実現してました。
今回の life クラスはコンパクトに実装し、その結果をうまく表現できることが目的。
大神様はその結果を大局的に見て life の死活を判断してくれるはずです。
そんなこったで少しだけ有望なクラスが出来ないかなと。

428 shu 2008/02/24 22:45 id: 3BVR6NRi4pQ prob: 0.6%: CStringクラス追加
簡易文字列クラスを追加 (+200行)
最低限のインタフェースは必要。だけど libc 依存は嫌なので、
ピュアな C++ のみで実装した。

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: 9r4Opr9Vay6 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 枯渇とか、暗号化問題とかあるので、そのからみでたぶん実現されると思ってますが?...

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