Author: Stuart Cracraft
Date: 22:12:45 08/28/04
Go up one level in this thread
On August 28, 2004 at 05:48:34, Uri Blass wrote: >On August 27, 2004 at 23:26:23, Robert Hyatt wrote: > >>On August 27, 2004 at 11:17:35, J. Wesley Cleveland wrote: >> >>>On August 26, 2004 at 21:00:10, Robert Hyatt wrote: >>> >>>>On August 26, 2004 at 14:09:06, Bert van den Bosch wrote: >>>> >>>>>On August 26, 2004 at 11:33:48, Robert Hyatt wrote: >>>>> >>>>>>On August 25, 2004 at 17:37:59, Bert van den Bosch wrote: >>>>>> >>>>>>>First of all, I hope the forum will continue in some way! >>>>>>> >>>>>>>Before it is gone, I have a question. >>>>>>> >>>>>>>I wanted to check my null move so I tested if the null move would create a >>>>>>>cutoff, and after that I did the normal stuff. So if you have a cutoff with null >>>>>>>moving you are almost sure you will also get a cutoff with the normal proces, >>>>>>>except for zugzwangs of course. But this wasn't happening all the time when I >>>>>>>tested it, and usually the values involved from what I got back from nullmove >>>>>>>and from the normal process were just a few centipawns in difference. Could this >>>>>>>be because of search instabillity? If it isn't a bug in my program I had the >>>>>>>idea to search nullmove with beta-MARGIN in order for the value returned by null >>>>>>>move to bridge the few centipawns gap. And taking MARGIN the few centipawns. But >>>>>>>I'm not sure if that is correct. Can someone shine a light on this? >>>>>>> >>>>>>>Thanks, greetings Bert >>>>>> >>>>>>This isn't what null-move is about. It will fail high in positions where a >>>>>>normal search won't, but that doesn't make it wrong. The point is that if your >>>>>>opponent can move twice in a row and you fail high after "passing" then your >>>>>>position is very good and it is safe to avoid searching to the normal depth to >>>>>>see if it is even better. >>>>>> >>>>>>As a general rule, if null-move fails high, a normal search should also fail >>>>>>high, of course, as that is the point in that the null-move search is easier to >>>>>>do since it searches to a reduced depth. But there is nothing to say that if >>>>>>the null-move search fails high that the regular search will not, that is part >>>>>>of the risk you take, since null-move is not 100% accurate. Reduce the depth >>>>>>and you obviously will miss some tactical shots that the deeper depth would not >>>>>>miss. >>>>>> >>>>>>If you want an "error-free" pruning algorithm, good luck. Logic says no such >>>>>>thing exists. :) >>>>> >>>>>alphabeta :) >>>> >>>> >>>>OK. >>>> >>>>If you want an error-free _forward-pruning_ algorithm, good luck. Logic says no >>>>such thing exists. :) >>> >>>EGTBs ;) >> >>That's not forward pruning. :) Those probes access a perfect tree search all >>the way to the mate position. Otherwise hash tables would be in the same >>category.. > >hash tables are not error-free because there can be hash collision. > >Uri This seems purely a matter of semantics. Remember Bob spent a LOT of time on forward-pruning before most of us were born. Stuart
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.