Computer Chess Club Archives




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

Author: Robert Hyatt

Date: 08:52:29 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.
>endgames: is it endgame 1 or 0
>null: has there been a previous null call
>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)
>    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);
>    if(value>=beta)
>	return beta;

You appear to be using R=1 for your null-move search.  IE where you call
search/quiesce with depth-1 normally, you are using depth-2.  Most of us are
using R=2 which means depth-3 rather than depth-2.  Some of us even use a
dynamic R that varies from 2 to 3, which means from depth-3 to depth-4
depending.  That will make a big difference.

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.