象歩将棋

Webと将棋で何か具体的なもの作って行こうとしてます。

このまま記事を入力し[投稿する]ボタンを押せば当サイトに送信されます。 以下の文章は注意書きです。

名前はかならず記入してください。ハンドルネームでも構いません。 またパスワードを入力することをお勧めします。 その場合他人による *なりすまし* と区別出来るかもしれません。 さらにブラウザでクッキーを有効に設定してある場合あなたの記事は後で修正可能になります。

コメントスパム防止のため記事の内容を機械的にモデレート (スパムである確率を計算) する処理を通します。 どのような投稿であれ、たまたま計算誤差によりスパムとみなされ 秘密の場所 に収納される可能性があります。 その場合、管理人が手作業で正規の場所に移動しますのでお待ちください。

434  shu  2008/03/17 23:51 id: 3BVR6NRi4pQ  prob: 1.5%

> やっぱり先は長い
そうでも無いかも

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

433  shu  2008/03/16 00:46 id: 3BVR6NRi4pQ  prob: 2.0%

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

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%

■思考エンジンについて
考えてみれば、簿何座は次のポリシーで実装したものと思われます。
　１．DBエンジンに抽出を任せる
　２．選択ロジックを実装する（CPU使用）
　３．DB情報にフィードバックする
　４．将棋ルール等は某氏のソースをそのまま使用
ポイントは、DBのリソースのフル活用により、（実際はDBではありませんが）
　・機能間の疎結合化
　・CPUの負荷の軽減化
を図り、コアな部分だけCPUリソースでロジックを走らせる戦術により
高速化を図っている事だと思います。
・・・To Be continued