Author: J. Wesley Cleveland
Date: 17:29:08 08/30/04
Go up one level in this thread
On August 30, 2004 at 15:47:47, Robert Hyatt wrote: >On August 30, 2004 at 12:28:04, J. Wesley Cleveland 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.. >> >>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 ? > >Some of those might well be perfect knowledge. IE kp vs k can be statically >evaluated perfectly. Many have exceptions that cause problems. IE not _all_ >knn vs k are drawn as you can be mated when you reach that position. Perfect >rules don't come into the domain of "forward pruning" generally. Forward >pruning is about statically tossing out some moves without searching them. And >they have an ovious risk. Some forward pruning rules might be near 100% >accurate. Others less accurate. Applying "perfect knowledge" is not considered >forward pruning in AI... Because with perfect knowledge there is no need to do >any searching at all. IE kp vs k. So your statment that there is no error-free forward pruning is true by definition, i.e. if it is error-free, it is not forward pruning.
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.