Author: Vincent Diepeveen
Date: 09:24:17 03/01/01
Go up one level in this thread
On February 28, 2001 at 05:56:36, Leen Ammeraal wrote:
Obviously when being in check you can't nullmove because you lose
king then. Also in pawn endgames there is a pretty good chance
that zugzwangs are important and you search deeply anyway so i
would turn it off there too.
Some people also prefer to turn off nullmove when there is only 1
light piece left at either side or both.
Personally i'm ONLY turning off nullmove in pawnendgame.
As there are so many testsets where just 1 lightpiece wins,
it is very tempting to turn off nullmove there.
For example a nightmare position is position in lctii.fen
where Bxe4 wins. Diep happily nullmoves with white there
all the time after Bxe4 so it doesn't find it. Not because
of zugzwangs, but because of the reduced depth you have
after nullmove.... ...sometimes even reducing depth from 20
ply to 17 is not enough.
Yet the chance you get a similar position on the board where the
reduction of the nullmove is going to hurt you is very small.
More likely it is that in nearly every game where the struggle is
big and where pieces slowly get exchanged (or quick as most
compu's do it), that in all kind of leafs you see positions
with little pieces. So i would find it pretty smart to
nullmove in those positions as you skip big crap from getting
evaluated.
My nullmove in pseudo code is very easy implemented.
A move gets stored on the stack always. Even if it's a nullmove.
A nullmove is value 0 in the pseudo code.
if moves get saved in a pointer called move, then my previous move
is *(move-1).
As we always have a king i do not count this in the totpiece count.
In DIEP R=3. Here some pseudo-C code...
Search(alfa,beta,depth,realdepth) {
where depth = depthleft
where realdepth is the actual real search depth from the root,
not a single relationship between depth and realdepth usually
as depth is getting hurted by extensions...
..
.. trying nullmove
..
if( !Attacked[side][king]
&& OwnsPawn[white]+OwnsPawn[black] < TotPieceCnt[white]+TotPieceCnt[black]
&& (realdepth <= 2
|| *(move-1)
|| *(move-2)) {
// now make a nullmove
Makemove(nullmove); ==> it's doing basically: *move++ = 0;
scoreback = -Search(-(beta),-(beta-1),depth-R-1,realdepth+1);
Unmakemove(nullmove);
..
..
if( scoreback >= beta ) {
Storehashtable(..
return scoreback;
}
..
..
}
So basically the only addition for
double nullmove is also avoiding nullmoves when the
last 2 moves were a nullmove.
Vincent
>I am not sure about when to avoid nullmoves.
>I omit it:
>a. when in check
>b. when there are less than 5 pieces (including pawns) on the board
>c. when the last move was a nullmove
>d. at the root node
>Should I also omit it in some other cases,
>for example, when any hashmove (even with a low draft) was found,
>or when beta = alpha + 1?
>Thanks in advance for any help.
>Leen
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.