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

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

コツコツとした良い感じ 着実にソリッドなコードが生産されてく感覚。 駒を動かすルールは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