象歩将棋
Webと将棋で何か具体的なもの作って行こうとしてます。
このまま記事を入力し[投稿する]ボタンを押せば当サイトに送信されます。
以下の文章は注意書きです。
名前はかならず記入してください。ハンドルネームでも構いません。
またパスワードを入力することをお勧めします。
その場合他人による *なりすまし* と区別出来るかもしれません。
さらにブラウザでクッキーを有効に設定してある場合あなたの記事は後で修正可能になります。
コメントスパム防止のため記事の内容を機械的にモデレート
(スパムである確率を計算)
する処理を通します。
どのような投稿であれ、たまたま計算誤差によりスパムとみなされ
秘密の場所
に収納される可能性があります。
その場合、管理人が手作業で正規の場所に移動しますのでお待ちください。
-
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: 480oHczCgMM
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
でもポンちゃんの話は参考になります。
-
425
pon
2008/02/21 12:36
id: 480oHczCgMM
prob: 41.1%
-
-
■思考エンジンについて
考えてみれば、簿何座は次のポリシーで実装したものと思われます。
1.DBエンジンに抽出を任せる
2.選択ロジックを実装する(CPU使用)
3.DB情報にフィードバックする
4.将棋ルール等は某氏のソースをそのまま使用
ポイントは、DBのリソースのフル活用により、(実際はDBではありませんが)
・機能間の疎結合化
・CPUの負荷の軽減化
を図り、コアな部分だけCPUリソースでロジックを走らせる戦術により
高速化を図っている事だと思います。
・・・To Be continued
-
424
shu
2008/02/21 00:13
id: 3BVR6NRi4pQ
prob: 0.2%
-
-
> ルール(ロジック)はどのクラスに実装されていますか
駒の動きは128ビットクラスで実装する。
驚くほどシンプルに実装できる。駒の機能は本質的にグラフィカルなためかな?
汎用駒クラスのインスタンスに関数ポインタを一個持たせるだけ。
ループとか条件分岐をあまり使わずに実装できそう。
> 思考エンジン以外はインターフェースを作れば、実装は誰が行っても速ければよい
そう思います。2015年までには128ビットデータ処理マシンが誕生してると思うので、
そうなれば今の128ビットクラスは不要になり、性能も二桁くらい向上するかも。
IPv4 枯渇とか、暗号化問題とかあるので、そのからみでたぶん実現されると思ってますが?...
> インターフェースが綺麗なら思考エンジンの作成がより楽
水平思考や垂直思考、私はどう考えたら良いか解りません。
とりあえず詰将棋やりながら考えてみます。
逆に序盤戦を考えるのが一つのヒントになるのかもしれません。
-
423
shu
2008/02/15 22:08
id: 3BVR6NRi4pQ
prob: 0.0%
-
-
> ルール(ロジック)はどのクラスに実装されていますか
将棋盤でも駒クラスでもありません
盤と駒の配置を元に、次の手イテレータ CMovesIter を生成します。
CMovesIter は指手の駒単位に set を返すクラスです。
ルールは set の制約条件として実装するつもりです。
要はプログラム的に必要になった時点で判断するということですが、
"あとで指せる手はあとまわしにしましょう、という考え方"
とかと妙に符合しておもしろい。
http://d.hatena.ne.jp/umedamochio/20080210
> インターフェースが綺麗なら思考エンジンの作成がより楽
小山に登ってみたら、まずその辺を見渡すのが良いのでしょう。
好みのインタープリタが欲しいなと少し思ってます。
追記:
ルールへのポインタは駒クラスに置いてあります。
|