2017年7月
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          

最近のトラックバック

無料ブログはココログ

« 自分で書いたコードが、『他人の書いたコード』になってしまっているよー… | トップページ | あれ?望みはあるのか? »

2007年5月 1日 (火)

激痛(w

隠し玉の実装&デバッグ終了。テスト中です。

とある方法で、PVじゃない枝のReductionを実現しようとしてたのですが…紙上で考えていた以上にReductionが起きるケースが少な過ぎ&Reductionに失敗しての再探索が多過ぎ、です(苦笑)。

以前、NullMoveを実装した時にも同じようなことが起きてしまい、『NullMoveを入れたらかえって遅い』現象にぶち当たったことがあるのですが、全く同じ轍を踏んでるみたいですね…。

原因は割合はっきりしていて、うさぴょんの末端の探索の関数がOddEvenEffectが激しすぎることから来ていると思うのですが。

まぁ、簡単にめげずに、もう少しReductionを行う条件を厳しく設定してみます。それで、恐らく、必要「そう」な時だけReductionを行うようになるはず、ですので。

あ、それと、今までの開発から何となく感じてることとして、

・うさぴょんの評価関数と末端の探索関数の癖?のせいか、『序盤』『終盤』はReductionが起こしにくい。
・なので、この手のReductionは、『中盤戦』に絞って行った方が良さそう。
・末端の探索関数が重過ぎて、再探索のコストが高過ぎ。

なんていうことがあります。

長い目で見ると、末端の探索関数を変えた方がいいのは前々からうすうす分かってはいたんですが…(CPUが今よりも相対的に遅かった時代は、末端の探索関数を重くして、通常探索の末端局面の評価を正確?にした方が強かったのですが、今は多分、末端の探索関数を軽くして、通常探索を深くした方が全体に強くなるのではないか、という思いを3年ほど前から思ってました。)

…れさぴょんの方が(全体として)早いのも分かっているわけですし、やはり、れさぴょんベースに乗り換えて、通常探索を深くしていった方がいいのか(苦笑)?

到底今年の選手権には間に合いませんが。

« 自分で書いたコードが、『他人の書いたコード』になってしまっているよー… | トップページ | あれ?望みはあるのか? »

「うさぴょん」開発」カテゴリの記事

コメント

コメントを書く

(ウェブ上には掲載しません)

トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/148072/14920674

この記事へのトラックバック一覧です: 激痛(w:

« 自分で書いたコードが、『他人の書いたコード』になってしまっているよー… | トップページ | あれ?望みはあるのか? »

コンピュータ将棋BOOKS