> やっぱり先は長い
そうでも無いかも
手を抽出する処理過程に条件クラスを追加しました。リファクタリングしただけとも云う;;
1) ルール上合法な手に制限する
2) 王手のみ選択する
3) 王手を解除する手のみ選択する
などを条件クラス化。ただし(3)は今は形だけ。
シンプルになったので、思いついた時に作業できます。
手の意味についてはペンディング。
象歩将棋
Webと将棋で何か具体的なもの作って行こうとしてます。
やっぱり先は長い
すべてビット演算でまかなおうと思ったけど、一般化すると組み合わせ数学的になる。
詰将棋で先手の場合、詰め手の抽出とかいう俺的な検索すれば良い。
ところが後手の立場だとどの駒が効いてるの? とか一から評価しないといけない。
手の意味を付加すべきだろうか?
コツコツとした良い感じ
着実にソリッドなコードが生産されてく感覚。
駒を動かすルールはC128クラスで実装。
平手戦の一局面の実測値は30万手抽出/1秒。遅いな;;
ルールは静的に持ち、駒クラスの関数が有効手のビット列を返却する。
現在 2,200 行くらいアスファルトに刻む。あぁ
詰めの条件付与もビット処理でおこなう予定。
それで単純ツリー探索は実現するはず。
そこまででライブラリとして最低必要な機能は実装される。ふぅ
life door
待ち受けるのは奇跡か、それとも破滅か!?
>life の死活を判断
lifeクラスがlife workになってしまわないようにご注意を
着手小局
瓢箪から駒。life というオブジェクトを作ろうと企画。
局所的にあらゆる手をトレースするオブジェクトです。
絵柄的にはミトコンドリアみたいな^^; もしくは紐かも;;
life の目的は短手数を網羅的かつ高速に読むこと。
最初の PyZume は、それを部分的に実現してました。
今回の life クラスはコンパクトに実装し、その結果をうまく表現できることが目的。
大神様はその結果を大局的に見て life の死活を判断してくれるはずです。
そんなこったで少しだけ有望なクラスが出来ないかなと。
CStringクラス追加
簡易文字列クラスを追加 (+200行)
最低限のインタフェースは必要。だけど libc 依存は嫌なので、
ピュアな C++ のみで実装した。
線と面
詰将棋の場合、たとえば PyZume は線を一筆書きにたどって行くのだけど、
現実的には途中で打ち切ることが必要なので麺になる。
スパゲッティじゃ長すぎるとすると、どの程度の長さが適切なのだろう。
たとえば三手とか、あるいは七手。その理由は?
三手: 故) 原田先生の有名なお言葉。
七手: 米長先生「とりあえずこのくらいは一瞬で読む」と言われた。
可変: ボナンザ先生?
ちなみに我が家はディ・チェコ No.11 のバジリコ味が好み。
http://www.nisshin.com/product/de_cecco/
何も解らん
今作ってるのは "425> DBエンジン" 的な部分なのかな。
まあルールを含めそのようなものを作ってます。
このレイアはループや分岐の少ない単純なロジックを心がけて居ります。
どんどん速くなる期待感がありますね。たとえば、
http://www.sgi.co.jp/newsroom/press_releases/2008/feb/asterism.html
http://developer.amd.com/tools/apl/Pages/default.aspx
> コアな部分だけCPUリソースでロジックを走らせる戦術
こっちは扉の向こう。構想を夢想するのみで何もしてません。
レイアを分ける必要性だけは解ります。
自分で作るつもりなので、何も見てません。
他の人のアイディアがあっても、今は私に教えないでください m(.".)m
でもポンちゃんの話は参考になります。
■思考エンジンについて
考えてみれば、簿何座は次のポリシーで実装したものと思われます。
１．DBエンジンに抽出を任せる
２．選択ロジックを実装する（CPU使用）
３．DB情報にフィードバックする
４．将棋ルール等は某氏のソースをそのまま使用
ポイントは、DBのリソースのフル活用により、（実際はDBではありませんが）
・機能間の疎結合化
・CPUの負荷の軽減化
を図り、コアな部分だけCPUリソースでロジックを走らせる戦術により
高速化を図っている事だと思います。
・・・To Be continued