Author: Peter Kappler
Date: 15:40:32 11/12/03
Go up one level in this thread
On November 12, 2003 at 04:44:28, scott farrell wrote: >On November 11, 2003 at 14:22:53, Robert Hyatt wrote: > >>On November 11, 2003 at 13:31:21, Peter Kappler wrote: >> >>>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? >> >>Very possibly. SEE makes sure you look at the "right" capture first each >>time a capture is the best move. Without SEE, you might have to try a couple >>before you find the good one. Breaking your fail-high-on-first-move count. >> >>> >>>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 %. > >I dont have SEE, but have a function isWeaklyDefended .. which guesses .. it >helps some. > I have a simple test that identifies some obviously stupid captures of weaker pieces that are defended by pawns. I also have a full-fledged SEE that is apparently too slow to work well. :( > >IID mainly helps when a new move becomes bests, and gets searched deeper than >normal. Normal iterative deepening does pretty well if the best stays best. > >I get an average of better than 90%. It takes tuning. Work on killers and >history pays off. Make sure you search bad captures before other moves also. >Taking capture out of killers gave me a boost also. > Hmmm, I think I do bad captures at the end, and as I recall it was a clear win. > >Move ordering is all about tuning and fiddling. > I've yet to find an aspect of chess programming that isn't. :) By the way, it's nice to see another engine written in Java. -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.