Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: null move efficiency

Author: José Carlos

Date: 02:19:54 04/21/04

Go up one level in this thread


On April 21, 2004 at 04:12:31, Daniel Shawul wrote:

>On April 21, 2004 at 03:57:50, Daniel Shawul wrote:
>
>>On April 21, 2004 at 03:32:14, José Carlos wrote:
>>
>>>On April 21, 2004 at 02:52:12, Daniel Shawul wrote:
>>>
>>>>On April 19, 2004 at 20:38:47, Mike Siler wrote:
>>>>
>>>>>My program tries a null move search if
>>>>>
>>>>>1. it's not the endgame
>>>>>2. it's not a PV node
>>>>>3. it didn't just make a null move
>>>>>4. it's not in check and wasn't in check on the previous ply
>>>>>5. the remaining depth isn't so small that the reduced depth would take it into
>>>>>the qsearch
>>>>>
>>>>>In general, only around 65% of the null move searches my program performs result
>>>>>in a cut-off. Is this normal or do other programs tend to do better (and how)?
>>>>>According to Ed Schröder's page, Rebel gets around 93-95%. I've tried the
>>>>
>>>>I am sure it does get that %. I just did a similar implementation like rebel's
>>>>    evaluate internal nodes
>>>>    if(score - our maximum hanging piece > beta)
>>>>       don't do null move
>>>>  This gives me usually >93% effectiveness! Thanks Ed.
>>>
>>>  I don't know if Ed does only that, but in my experience it doesn't work. You
>>>must also take into account your own threats or you'll do unnecesary full
>>>searches. For example, eval is 0 and you have a hanging pawn, while beta is also
>>>0. The opponent has its queen and rook attaked by your pieces. A null move will
>>>save a lot of nodes there. The raise in % effectiveness is not enough to
>>>compensate for that, in my experience.
>>>
>>>  José C.
>>
>>        sorry i made a typing error above
>>            if(score - our maximum hanging < beta)
>>               don't do null move
>>        Or
>>
>>        if(score - our maximum hanging + opponent's maximum hanging < beta)
>>               don't do null move
>
>         I just tried this and it drops the effectiveness from 94 to 83%!
>    And then i checked the nodes searched to search a fixed depth of 9
>[hashtable turned off] at the starting position.
>        nodes searched with the first  one     1869125
>        nodes searched with the second one     1777845
>   that is roughly a 5% reduction.
>
>I think you are right. I should use the second one
>
>thanks
>daniel

  You can also experiment with several other things that might be interesting
for the matter, which I'm trying now but don't have conclusive data so far. For
example, number of opponent pieces attacked (not only value), own king safety
(if our king is already dangerous, two consecutive moves will probably kill us,
so not worth trying), opponent king safety (we're behind in material but
opponent king is exposed -> maybe two moves is not enough to drive it safe)...
  Remember that, as has been mentioned somewhere else in this thread, a null
move is pretty cheap compared to a full depth search, so you need to avoid
_many_ useless null moves to break even if you don't null move when it would
have failed high.

  José C.



>>   The second one may solve the problem you mentioned.
>>>
>>>
>>>>>recommendations listed there but they didn't help much.
>>>>>
>>>>>Michael



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.