象歩将棋
Webと将棋で何か具体的なもの作って行こうとしてます。
投稿フォーム:
お名前: ニックネームでも何でもかまいません(必須)
パスワード: なりすまし防止のため利用できます(任意)
記事:
 
キャンセル
433 shu #f0c10dc 2008/03/16 00:46 prob:%
やっぱり先は長い すべてビット演算でまかなおうと思ったけど、一般化すると組み合わせ数学的になる。 詰将棋で先手の場合、詰め手の抽出とかいう俺的な検索すれば良い。 ところが後手の立場だとどの駒が効いてるの? とか一から評価しないといけない。 手の意味を付加すべきだろうか?
432 shu #f0c10dc 2008/03/11 21:19 prob:%
コツコツとした良い感じ 着実にソリッドなコードが生産されてく感覚。 駒を動かすルールはC128クラスで実装。 平手戦の一局面の実測値は30万手抽出/1秒。遅いな;; ルールは静的に持ち、駒クラスの関数が有効手のビット列を返却する。 現在 2,200 行くらいアスファルトに刻む。あぁ 詰めの条件付与もビット処理でおこなう予定。 それで単純ツリー探索は実現するはず。 そこまででライブラリとして最低必要な機能は実装される。ふぅ
431 shu #f0c10dc 2008/03/05 20:31 prob:%
life door 待ち受けるのは奇跡か、それとも破滅か!?
430 pon #d4c0f6f 2008/03/05 12:38 prob:%
>life の死活を判断 lifeクラスがlife workになってしまわないようにご注意を
429 shu #f0c10dc 2008/03/04 21:59 prob:%
着手小局 瓢箪から駒。life というオブジェクトを作ろうと企画。 局所的にあらゆる手をトレースするオブジェクトです。 絵柄的にはミトコンドリアみたいな^^; もしくは紐かも;; life の目的は短手数を網羅的かつ高速に読むこと。 最初の PyZume は、それを部分的に実現してました。 今回の life クラスはコンパクトに実装し、その結果をうまく表現できることが目的。 大神様はその結果を大局的に見て life の死活を判断してくれるはずです。 そんなこったで少しだけ有望なクラスが出来ないかなと。
428 shu #f0c10dc 2008/02/24 22:45 prob:%
CStringクラス追加 簡易文字列クラスを追加 (+200行) 最低限のインタフェースは必要。だけど libc 依存は嫌なので、 ピュアな C++ のみで実装した。
427 shu #f0c10dc 2008/02/22 22:10 prob:%
線と面 詰将棋の場合、たとえば PyZume は線を一筆書きにたどって行くのだけど、 現実的には途中で打ち切ることが必要なので麺になる。 スパゲッティじゃ長すぎるとすると、どの程度の長さが適切なのだろう。 たとえば三手とか、あるいは七手。その理由は? 三手: 故) 原田先生の有名なお言葉。 七手: 米長先生「とりあえずこのくらいは一瞬で読む」と言われた。 可変: ボナンザ先生? ちなみに我が家はディ・チェコ No.11 のバジリコ味が好み。 http://www.nisshin.com/product/de_cecco/
426 shu #f0c10dc 2008/02/21 22:35 prob:%
何も解らん 今作ってるのは "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 でもポンちゃんの話は参考になります。
425 pon #d4c0f6f 2008/02/21 12:36 prob:%
■思考エンジンについて 考えてみれば、簿何座は次のポリシーで実装したものと思われます。  1.DBエンジンに抽出を任せる  2.選択ロジックを実装する(CPU使用)  3.DB情報にフィードバックする  4.将棋ルール等は某氏のソースをそのまま使用 ポイントは、DBのリソースのフル活用により、(実際はDBではありませんが)  ・機能間の疎結合化  ・CPUの負荷の軽減化 を図り、コアな部分だけCPUリソースでロジックを走らせる戦術により 高速化を図っている事だと思います。 ・・・To Be continued
424 shu #f0c10dc 2008/02/21 00:13 prob:%
> ルール(ロジック)はどのクラスに実装されていますか 駒の動きは128ビットクラスで実装する。 驚くほどシンプルに実装できる。駒の機能は本質的にグラフィカルなためかな? 汎用駒クラスのインスタンスに関数ポインタを一個持たせるだけ。 ループとか条件分岐をあまり使わずに実装できそう。 > 思考エンジン以外はインターフェースを作れば、実装は誰が行っても速ければよい そう思います。2015年までには128ビットデータ処理マシンが誕生してると思うので、 そうなれば今の128ビットクラスは不要になり、性能も二桁くらい向上するかも。 IPv4 枯渇とか、暗号化問題とかあるので、そのからみでたぶん実現されると思ってますが?... > インターフェースが綺麗なら思考エンジンの作成がより楽 水平思考や垂直思考、私はどう考えたら良いか解りません。 とりあえず詰将棋やりながら考えてみます。 逆に序盤戦を考えるのが一つのヒントになるのかもしれません。