>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

> ルール（ロジック）はどのクラスに実装されていますか 駒の動きは128ビットクラスで実装する。 驚くほどシンプルに実装できる。駒の機能は本質的にグラフィカルなためかな? 汎用駒クラスのインスタンスに関数ポインタを一個持たせるだけ。 ループとか条件分岐をあまり使わずに実装できそう。 > 思考エンジン以外はインターフェースを作れば、実装は誰が行っても速ければよい そう思います。2015年までには128ビットデータ処理マシンが誕生してると思うので、 そうなれば今の128ビットクラスは不要になり、性能も二桁くらい向上するかも。 IPv4 枯渇とか、暗号化問題とかあるので、そのからみでたぶん実現されると思ってますが?... > インターフェースが綺麗なら思考エンジンの作成がより楽 水平思考や垂直思考、私はどう考えたら良いか解りません。 とりあえず詰将棋やりながら考えてみます。 逆に序盤戦を考えるのが一つのヒントになるのかもしれません。

> ルール（ロジック）はどのクラスに実装されていますか 将棋盤でも駒クラスでもありません 盤と駒の配置を元に、次の手イテレータ CMovesIter を生成します。 CMovesIter は指手の駒単位に set を返すクラスです。 ルールは set の制約条件として実装するつもりです。 要はプログラム的に必要になった時点で判断するということですが、 "あとで指せる手はあとまわしにしましょう、という考え方" とかと妙に符合しておもしろい。 http://d.hatena.ne.jp/umedamochio/20080210 > インターフェースが綺麗なら思考エンジンの作成がより楽 小山に登ってみたら、まずその辺を見渡すのが良いのでしょう。 好みのインタープリタが欲しいなと少し思ってます。 追記: ルールへのポインタは駒クラスに置いてあります。

>↓ C++で普通に9x9ボードクラスを作り、駒の移動はポインタで実装 ← 今ここ 抽象化の話しですが、駒の移動（移動可否の判断）はボードクラスが持つのでしょうか。 移動可否を判断するためには、ルールに判断を委譲することになります。 現在、ルール（ロジック）はどのクラスに実装されていますか。 恐らく、思考エンジン以外はインターフェースを作れば、実装は誰が行っても速ければよい ということになると思います。 インターフェースが綺麗なら思考エンジンの作成がより楽になるのでしょう。 思考エンジンこそ抽象化の出番なんでしょうが、扉が見えてきません。 半年ほどやってませんし、この先もなかなか・・・　修ちゃんに期待してます。

駒の移動方法 ↓ Cで関数ポインタ使って、その場その場でいろいろ (煩雑で失敗作かも) ↓ Python で駒クラスを作り、そのオブジェクトにルールを持たせた (PyZume) ↓ Cで静的なテーブルにルールをすべて持たせた (まあ速い) ↓ Cでビットテーブルとビット演算で処理 (少し速い) ↓ C++で普通に9x9ボードクラスを作り、駒の移動はポインタで実装 ← 今ここ さて、いよいよ局面探索の「第一の扉」を開けそうです^^ 「扉の向こうに待ち受けるのは奇跡か、それとも破滅か!?」 ... なんて