Null Move concern

[smcracraft]

Hi, with the following code in my main search, after the hash probe
and before the attempt to use the hash move / pv move prior to
a move gen, I have this null move attempt:

#ifdef NULLMV
#define R 2
r = R;
// If we are beyond the first 2 ply (0 and 1) of the search
// and the last move was not null move
// and we are above the frontier
// and there is at least one piece for either side
// and we are not in check
// then try null move.
if (ply > 1 && hist[histptr-1].flag != NULLMOVE && depth > 1 && bb_pieces && !incheck(bd)) {
makenullmv();
val = -search(bd,depth - 1 - r, ply, -beta, -beta + 1);
unmakenullmv();
if (val >= beta)
return beta;
}
#endif

But in testing, 250 quiescent positions at 60 seconds each first without
nullmove and next with nullmove, the result is a wash - equality for
nullmove and non-nullmove result.

The average search depth is about 2/3-3/4 ply deeper with null move
but the solution count is only a single position better for null move.

Obviously there is a flaw in the above implementation but I have
not been able to find it.

If anyone sees an improvement, please reply.

Thanks -- Stuart

P.S. Sorry about the left-flush code above. I do not know how to tell
this bulletin-board to take the text exactly as-is.

[David Weller]

Hi Stuart,

Some of the root moves are still pretty dumb, so why not try null move at root+1 ?

I also noticed you do not increase ply in your call to search(). Is this right?

-David

[smcracraft]

Hi Stuart,

Some of the root moves are still pretty dumb, so why not try null move at root+1 ?

I also noticed you do not increase ply in your call to search(). Is this right?

-David

[quote]

I tried changing the code to:

Code: Select all


#ifdef NULLMV
    // Get all non-king pieces in a single bitmap
    bb_pieces=b[white][knight]|b[white][bishop]|b[white][rook]|b[white][queen]|
      b[black][knight]|b[black][bishop]|b[black][rook]|b[black][queen];

    // Set default for null move reduced search
#define R 2
    r = R;

    // To do null move, can't be at top, can't have just done it, be above horizon, have at least one piece
    // and not in check.

    if (nulldone == 0 && ply > 0 && hist[histptr-1].flag != NULLMOVE && bb_pieces && !incheck(bd)) {
      makenullmv();
      val = -search(bd,depth - 1 - r, ply + 1, -beta, -beta + 1, 1);
      unmakenullmv();
      if (val >= beta)
        return beta;
    }



and ran null move and no null move on Bratko-Kopec 22. The
result was 75% improved for null move (i.e. 75% less time to
reach the right move and variation and stay with them on
successive iterations.)

I guess my learning in this, besides your fix that ply should be
ply + 1 in the call to search() and Bob's recommendations of ply > 0
instead of ply > 1 and eliminating depth > 1, is that I simply
had forgotten that null move primarily improves tactical positions
and the positions I was using to test were deeper,
quieter positions (though with moves agreed to by Crafty,
Ryba, and I believe Shredder) - it's that set of 7500 positions.

Anyway, thanks - I guess null move is about what it needs to be
now. 75% is good enough for me.

Stuart