Computer Chess Club Archives




Subject: Re: not using nullmove?

Author: Uri Blass

Date: 13:55:45 02/15/04

Go up one level in this thread

On February 15, 2004 at 14:08:18, Christophe Theron wrote:

>On February 15, 2004 at 08:53:42, martin fierz wrote:
>>On February 14, 2004 at 13:16:15, Christophe Theron wrote:
>>>What I have always tried to do is to hide the details of what's inside Chess
>>>Tiger (in order to protect my work a little bit) but still explain what my
>>>methodology (or work philosophy) was (in order to somehow give back to the
>>>I think it's important to have strong guidelines in your work. Some of them come
>>>from your knowledge of information processing in general (be careful not to
>>>create bugs, don't waste resources, never trust Microsoft...), and some of them
>>>are specific to the domain of chess programming and took me years to figure out.
>>>For example:
>>>* don't compute something in advance if you are not sure you will use it,
>>>because chances are that you will get a cutoff before you need it (remember it's
>>>just a guideline - sometimes you can break this rule).
>>>* you need a very accurate way of measuring progress, or you will not make
>>>progress at all.
>>>* Any change can make your program significantly weaker. You need to test your
>>>changes (with the method you have built) very often.
>>>* People believe that chess is about evaluation, but actually it's all about
>>>search (I'm trying very hard to break this rule, because it must be wrong from a
>>>mathematical point of view, but it's really difficult).
>>i'm not sure i agree with this one - but then i don't quite know what you mean
>>with that sentence :-)
>From a mathematical point of view, a perfect evaluation would make search mostly
>useless: a 1-ply search would be enough to play perfectly.
>So in theory there is no reason to favor search over evaluation, and you can
>even replace search by evaluation.
>In practice, it is extremely difficult to gain the equivalent strength of just
>one more ply of search by an improvement in the evaluation.
>Once you have build a resonably simple evaluation that takes material, pawn
>structure and piece centralization into account, it's hell to make it
>significantly better.
>On the other hand, improving the search is by comparison much easier. At least
>in the first years of developpement of your chess engine.
>>my disagreement comes from the fact that improving your eval automatically
>>improves your search when you use any kind of pruning which depends on the
>>evaluation. nullmove is such an example,
>I would not say that nullmove is a pruning system that depends that much on
>evaluation. I would say that nullmove adds its share of strength to your
>program. This share is quite fixed and will not vary depending on the quality of
>your evaluation.

I did not investigate it but it is against my intuition.
The point is that with bad evaluation you may more often prune good moves when
you see no threat.

For example suppose that you can sacrifice material to generate unstoppable
passed pawns.

bad evaluation will not see that the pawns are unstoppable so it is not going to
see the threat and you may need many plies to find the queen promotion so null
move may be counter productive relative to not using null move pruning.

good evaluation may see that the pawns are unstoppable so with null move pruning
may you may see the win at the same depth as without using null move pruning.

In the first case you may need 5 minutes to find the move without null move
pruning and 10 minutes to find the move with null move pruning.

In the second case you may need 2 seconds to find the move without null move
pruning and 1 second to find the move with null move pruning.

In the first case null move was counter productive for the specific position and
in the second case it was productive.


This page took 0.05 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.