Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: When to do a null move search - an experiment

Author: Robert Hyatt

Date: 10:54:28 04/26/04

Go up one level in this thread


On April 26, 2004 at 11:32:26, Tord Romstad wrote:

>On April 26, 2004 at 10:39:42, Josť Carlos wrote:
>
>>  An interesting experiment, of course. But I think your conditions are rather
>>different from 'most' programs. I mean:
>>  - You allow any number of null moves in a row (most programs don't do even
>>two)
>
>This has no importance, I think.  My experience is that I almost always get the
>same score and PV when I enable/disable several null moves in a row, and that
>the difference in number of moves searched is *very* tiny.
>
>>  - You do pruning and reductions that are not public domain
>>  This is important because your results mean: 'in a non-standard null move
>>implementation (where you try more null move searches than most others) and with
>>a lot of heavy pruning and reductions (I assume they're heavy according to your
>>posts here and the high depths Gothmog gets) and in a MTD(f) root search,
>>limiting null move application seems to benefit". This conclusion is, apart from
>>interesting of course, very intuitive.
>
>This is a very good point.  During our discussion last week, several people
>claimed that checking the static eval before doing a null move search wasn't
>really necessary, because the cost of a null move search would be tiny
>compared to the cost of searching the moves anyway.  This isn't really
>true for Gothmog, because most of the moves are usually not searched to
>full depth.
>
>I am not sure it is fair to describe my pruning and reductions as "not
>public domain", though.  It is true that I haven't published any paper
>and that my engine is not open source (at least not yet), but I am happy
>to describe the tricks I use to anybody who wants to listen.  :-)

We all listen. :)


>
>Whether the use of MTD(f) is important is hard to say, but my guess is
>that it isn't.

Mine is that it is a _big_ issue.  I played with mtd(f) for quite a while, and I
found that it changed most everything.  Needed 2 hash bounds.  Needed fail-soft.
 Needed to accelerate the convergence.  It really was a different animal from
normal PVS-type approaches.

>
>>  Thanks for the data. You sure inspired many others to do similar tests (I'll
>>do when I have time).
>
>Yes, it would be interesting to see the results of similar experiments for
>other engines.  It seems like a sure bet that this is a YMMV issue.  :-)
>
>Tord


I agree.  I did it one way, Bruce (see my other post in this thread) had
conflicting data, turned out his data was better and I changed. :)




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