Author: Peter Kappler
Date: 10:31:21 11/11/03
Go up one level in this thread
On November 11, 2003 at 11:25:59, Robert Hyatt wrote: >On November 11, 2003 at 11:09:40, José Carlos wrote: > >>On November 11, 2003 at 10:52:20, Robert Hyatt wrote: >> >>>On November 11, 2003 at 10:42:10, José Carlos wrote: >>> >>>> So far, when I cutoff due to null move, I do BetaCutoffs++ but not >>>>BetaCutoffsAtFirst++ so my 100 * BCAF / BC statistic gets lowered. Is there an >>>>standard for this for I can compare with other people numbers? Should I count a >>>>null move cutoff as a beta cutoff at first? Should I not do BetaCutoffs++? >>>> >>>> José C. >>> >>>Don't do anything in that case. You only care about the ratio of >>>[cutoffs on first move] : [cutoffs on any but first move]. >>> >>>The higher that ratio the better. >> >> So you mean not to count null move cutoffs as cutoffs at all, right? >> >> José C. > > >Right. or you might count null-move searches done, and null-move searches >that failed high, if you want to know how effective null-move search is. But >it is clearly independent of the idea of base move ordering where the first move >should cause a cutoff if one is going to happen. This first-move-beta-cutoff metric is something that has always bothered me. In previous discussions, people have reported an average of ~90%. For my program, it's more like 80%, and I'd like to understand why. I don't use a SEE to eliminate bad captures, and also don't use internal iterative deepening. Perhaps that's enough to explain the difference? If either of you have time to run a quick test with one or both of these features disabled in your program, I'd be interested to hear how it affects the FMBC %. -Peter
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.