Author: J. Wesley Cleveland
Date: 09:28:04 08/30/04
Go up one level in this thread
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.. How about endgame rules, e.g. KBK is a draw, or KQK is always a win if the side with the Q is on move ?
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.