Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: is this nullmove? problems in pulsar algorithm

Author: Dieter Buerssner

Date: 04:24:36 09/20/00

Go up one level in this thread


On September 20, 2000 at 06:36:13, Mike Adams wrote:

>    I'm having some trouble realizine the gain ive heard i should from nullmove
>in Pulsar on icc.  So i wanted to show you the alorithm that i'm using. its not
>exactly the code my own code is unique to my program and might confuse but its
>essentially the code that i use.
>
>variables:
>endgames: is it endgame 1 or 0
>null: has there been a previous null call

I don't see that this is set or reset in the code snippet you posted.
Maybe this is your problem? Perhaps the easiest is to spend a new argument
to your search.

  search(alpha, beta, depth, side, myenpassant, passhash, do_null)

When calling inside the null move snippet, call with 0 as the last argument,
otherwise with 1.

>side: side to move counts up from 1. odd for pulsar even for opponent
>depth: counts down always 0 on first call of qsearch
>beta: could be 10,000 or -10,000 if evaluate hasn't been called
>
>if(endgames==0 && null==1 && side>1 && beta!=10000 && beta!=-10000)

You certainly need to avoid the null move, when you're in check as well.

>{
>    if(depth-2<=0)
>    value=-qsearch(-beta, -alpha, 0, (side+1), myenpassant);
>    else
>{               /* you can ignore the hash it just changes side to move and
>       I only use hashing for move ordering anyway so shouldnt have big impact
>*/
>        passhash=computecurrenthash(currenthash, 0, 0,0, 1);
>	value=-search(-beta, -alpha, depth-2, (side+1), myenpassant, passhash);

You can savely use a search window of -beta, -beta+1 here, because you only
want to prove, that value >= beta. The depth-2 seems very calm. I think
most people use depth-3 or even greater reduction of depth.

Also, the myenpassant seems suspicious, but probably won't make a difference,
because the opponent certainly can not capture on that square.

>}
>    if(value>=beta)
>	return beta;
>
>}

One idea I use is, that (depending on depth) I search before the null_move
at even more reduced depth for the side to move. Only when this call fails
high, I try the null move. The cost of this is very little, but it will avoid
typical null move blunders (of course higher depth is needed to see the threat).

-- Dieter



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