Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: null-move

Author: Robert Hyatt

Date: 18:41:38 08/30/04

Go up one level in this thread


On August 30, 2004 at 20:29:08, J. Wesley Cleveland wrote:

>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.


No.  The definition is simply wrong.  Forward pruning means throwing things out
without searching them.  Some "search" can be replaced by perfect knowledge, and
using that is not the same thing as "forward pruning"....

If you know the result, that isn't pruning.  That is simply applying perfect
knowledge.   Otherwise recognizing a mate in the tree would be a form of forward
pruning because the search stops there...



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.