象歩将棋

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

435  pon  2008/03/19 00:37 id: 9r4Opr9Vay6  prob: 5.0%

>すべてビット演算でまかなおう
＝数式で近似しよう
≒数式を勉強し直そう
＝線形代数を勉強し直そう
＞寿命＝呑み直そう＾＾

知りあいに、5手詰めの切り抜きを机の額に飾っていた人がいました。
どうしてそんな一目の詰め将棋を飾っているのか、最初はどうしても
意味がわからなかったのですが、
今から思うと、将棋を知らない人がどう思うかを重視していたようにも
思えます。
人生楽しんだ方が得ですね。

434  shu  2008/03/17 23:51 id: 3BVR6NRi4pQ  prob: 1.5%

> やっぱり先は長い
そうでも無いかも

手を抽出する処理過程に条件クラスを追加しました。リファクタリングしただけとも云う;;
1) ルール上合法な手に制限する
2) 王手のみ選択する
3) 王手を解除する手のみ選択する
などを条件クラス化。ただし(3)は今は形だけ。
シンプルになったので、思いついた時に作業できます。
手の意味についてはペンディング。

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
でもポンちゃんの話は参考になります。