Computer Chess Club Archives




Subject: Re: Confusion on Null Move

Author: Peter McKenzie

Date: 18:11:15 02/09/99

Go up one level in this thread

On February 09, 1999 at 20:39:07, KarinsDad wrote:

>On February 09, 1999 at 20:18:20, Eugene Nalimov wrote:
>>On February 09, 1999 at 20:09:12, KarinsDad wrote:
>>>I understand the concept of Null move, but I am confused as to why it works so
>>>My confusion lies in the area of piece taking.
>>>In a lot of positions, both sides have moves which will allow a piece to be
>>>taken by the other side. Often, in an equal game, this will not matter as the
>>>side protecting the piece can gain back equal or greater material if the other
>>>side takes the piece.
>>>Since chess programs (as a general rule) play a "reasonable" game of chess (i.e.
>>>they do not hang pieces multiple ply down), then it would seem that at any given
>>>position being checked, that it is the rare case that a 1 ply null move would
>>>not drastically improve the score since regardless of the move being checked,
>>>the best null move will be a piece take that improves the score.
>>Programs plays reasonable moves, but most of the positions
>>in the game trees are not reasonable. For example, in half

This is the key point, in a full width game tree there are alot of positions
that are totally one sided.  A good way to get a feel for this is to get a
dump of an actual game tree into a text file and scroll through it with a text
editor.  Take a look at all the crazy lines in there!

If you are serious about trying to write a decent chess program, you will almost
certainly want a feature in your program that dumps the search tree to a file.
Some bugs are almost impossible to find without this.  Of course the trees can
be very big, usually you'll want to limit them to 3 or 4 ply.

>>of the nodes, program must check *every* possible move, so
>>null move will help greatly after majority of that moves.
>For someone who understand this well, your answer may be sufficient. But there
>isn't enough detail for me to get the gist of the "why of it". Sorry.
>For example, if as you state that in half of the nodes, the program must check
>every possible move, then it would seem that those nodes were acquired by one
>side or the other making a reasonable move (as opposed to a move which was
>easily refuted with a one or a few move search response). When the null move is
>applied to all of the responses to the reasonable move (giving the responder two
>consecutive moves), it would seem that the reasonable move would be blown out of
>the water quite often by at least one of the responses and you haven't
>accomplished anything.
>I would think that null move would be useful when you get a cutoff. If you can
>refute my move and even if I make two moves in a row, you can still refute it,
>then I have picked a really lousy move. But in this case, you already have a
>cutoff, so why search deeper on it. I think I must be missing something here.
>>>I can understand that in certain positions, improving the score by a single
>>>piece is not sufficient to alter the score enough to prevent a beta cutoff, but
>>>to me (not having the data on hand since my program does not do this yet), it
>>>would seem that this would be a rare case.
>>>Since null move is used by most everyone's program, this assumption would appear
>>>to be false. I was just wondering if someone could explain to me why this is so
>>>and also possibly the multiple cases (and possibly their frequency) of positions
>>>that null move works well on (where it prevents additional searching).
>>>Or is it just a case that null move infrequently helps the search, but when it
>>>does so, it cuts out major chunks of the search tree and not searching (and
>>>calculating moves within) these major chunks makes up for doing multiple
>>>evaluations (and an additional legal move generation) per node?
>>>Thanks in advance,
>>>KarinsDad :)

This page took 0.1 seconds to execute

Last modified: Thu, 07 Jul 11 08:48:38 -0700

Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.