倶楽部入口倶楽部活動検索累計訪問者数Live Stats For Website 一年目 約９万３千 ２００９－０２－２７ １０万人 ２００９－０９－１７ ２０万人 ２０１０－０４－２７ ３０万人 ２０１０－１１－１５ ４０万人 ２０１１－０６－２２ ５０万人 ２０１２－０２－２６ ６０万人 ２０１２－１１－０９ ７０万人 ２０１３－１０－２４ ８０万人 ２０１５－０８－２７ ９０万人 |
王手の判断合法手生成時に必ずチェックしなければならない事の一つに「生成された手が自玉の王手にならない」があります。人間にとっては馬鹿らしいほど基本中の基本ですがソフトを書く身としては避けては通れない道ですね。 その方法としては、「候補手」を指した後... ①敵側の駒を全部動かして自玉を取れる手が存在するかを調べる ⇒ 一番単純 ②自玉の位置に（玉以外の）他の駒が有ると仮定して、そこから駒を動かす。その到達地点に同じ敵の駒が有れば王手が存在する。 ⇒ これは①を反転した見方です。 （例）自玉の位置に飛車が有ると仮定し、そこから到達できる升を全てチェック。敵の飛車がその中に有るならば（敵の飛車も自玉の位置まで到達できるので）王手の存在が確認されました。 ③敵の駒が利いている全ての升をマークします。王がマークされた升に乗っているなら王手確認です。 ⇒ ①と似ているがチョッと違う。更には「利き」の情報は（評価関数での）二次的使用ができます。 「王手チェック」は合法手候補全てに繰り返さないといけませんので。 （A）可能な限り速く がルールです。（将棋ソフト書くには何でも「速く、速く、より速く」なのね） 現在の所、無明君は（こうなることは想定内なのですが...以下参照）２８％の検索時間を「王手チェック」に取られているので改良なのです。 無明君は現在の所「③敵の駒が利いている全ての升をマークします」を使用しています。ところが一手生成する毎にマーキングを始めからやり直すのですこぶる効率悪しです。駒を動かした差分だけをアップデートすればより速く成ります。（と思う） （補足） 更には「王手が掛かっていた場合、応手はそれを解消しなければならない」も同じ場所でチェックしています。解消できない場合は「詰み」ですね。
投稿者： 紫外線 投稿日時： 日, 10/04/2009 - 14:17 categories [ ]
|
掲示板更新状況 |
検索エンジンいじり
...は今週で打ち切り、本格的に評価関数に手を入れないといつまで経っても完成しませんね。うぅぅぅ。
評価関数と言えば最近妙だと感じたこと...
「持ち駒の歩が一定数以上だと（例・三枚）点数の増加は飽和する」
...との考えを目にしましたが、なんか違和感があるような。
盤上の歩は当然ストレートに計算しますので一定数の歩を持ったら歩を打つ手が不当に過大評価される...のかな？となればそれを防ぐ方法は？？？
閃き その２
...ちと待てよ。局面評価の際に一度訪れた局面の点数は記憶することにより検索速度を上げられます。
同様に「この局面には王手が掛かっているか？」は同様のテクが流用できるのかな？？？
新・評価関数
...の下地はできましたが、細かいパラメターの振り分けを考慮中ですう。
コンセプトは「sphere of influence」...勢力圏です。
実験結果
競技用マシン（i7 920）でテストして８手読みの際
５秒 ⇒ ３．８秒
...と成果が出ています。追試してパスすれば採用です。
（追記）
おっと、考慮しなければならない例外が有りましたね。読みの最深時点で玉を動かしたとき敵駒の利きに進入するのは駄目（反則）なので...「玉を動かしたときはもう一手検索して自分から王手にしない」を実装しなければなりませんね。
（追記２）
ちと待てよ...玉を動かさなくても王手になるケースも有りました。
（例）空き王手
考え直しか？？？ がっくんです。
ん？閃いたかしら？
第４の選択がありました。
プログラム高速化のルールその一は「しなければ計算時間はゼロ」を適用して、
④「王手チェック」をしない。但し、検索時に「玉を取れる手」に遭遇したら無視する。
...実験してみます。
改造したけど
...速くなりませんでした。くやし。