Author: Antonio Dieguez
Date: 21:49:37 08/18/01
Go up one level in this thread
Hmmn... not good.
Here is my stats: :)
Amyan, normal version(with nullmove as the principal prunning when pos>=beta):
ply score nodes pv:
4 0 1700 e2e4 g8f6 b1c3 e7e5
5 32 4998 e2e4 d7d5 e4d5 d8d5 b1c3 d5d8
6 11 14871 e2e4 g8f6 e4e5 f6d5 d2d4 e7e6
7 30 68143 g1f3 d7d5 d2d3 g8f6 b1c3 c8g4 c1f4
8 7 238917 d2d4 d7d5 e2e3 g8f6 g1f3 c8g4 f1b5 c7c6 b5e2
9 30 748533 g1f3 d7d5 e2e3 c8g4 f1e2 g4f3 e2f3 e7e5 d2d4 f8b4
Amyan, only with null-move:
4 0 2222 e2e4 g8f6 b1c3 e7e5 [317 nps]
5 32 6282 e2e4 d7d5 e4d5 d8d5 b1c3 d5d8 [261 nps]
6 11 19136 e2e4 g8f6 e4e5 f6d5 d2d4 e7e6 [736 nps]
7 30 92129 g1f3 d7d5 d2d3 g8f6 b1c3 c8g4 c1f4 [2879 nps]
8 7 343131 d2d4 d7d5 e2e3 g8f6 g1f3 c8g4 f1b5 c7c6 b5e2 [6728 nps]
9 30 1057900 g1f3 d7d5 e2e3 c8g4 f1e2 g4f3 e2f3 e7e5 d2d4 f8b4 [10172 nps]
Amyan, without any prunning when pos>=beta
4 0 2534 e2e4 g8f6 b1c3 e7e5
5 32 10226 e2e4 d7d5 e4d5 d8d5 b1c3 d5d8
6 11 39898 e2e4 g8f6 e4e5 f6d5 d2d4 e7e6
7 30 208012 g1f3 d7d5 d2d3 g8f6 b1c3 c8g4 c1f4
8 7 1051428 d2d4 d7d5 e2e3 g8f6 g1f3 c8g4 f1b5
9 30 4565175 g1f3 d7d5 e2e3 c8g4 f1e2 g4f3 e2f3 e7e5 d2d4
Same pv, same scores. And it is often this way.
The nullmove is R=3 but I use a small margin when falling into the qsearch.
The condition is something like this:
if ((depth>3 && eval>=beta) || (depth<=3 && eval>=beta+margin))
with margin =0.1 pawn.
If lower, the pvs and scores begin to differ too much more, but I have not done
any serious test about this to measure my perfect value in this. Very necessary
*IN AMYAN*. You have to see what you do in your program, may be you are using
r=3 and r=2 work better for you etc etc.
Good luck.
>So I've been dinkering with null move. Or it's been dinkering
>with me.
>
>Without using null move, an 8-ply search in the opening
>position looked like:
>
>ply time nodes score pv
> 1 0.00 21 28 d2d4
> 2 0.00 97 -20 d2d4 d7d5
> 3 0.06 842 16 d2d4 d7d5 g1f3
> 4 0.06 3423 -15 e2e4 g8f6 e4e5 f6e4
> 5 0.17 22430 1 e2e4 e7e5 g1f3 g8f6 b1c3
> 6 0.77 87605 0 e2e4 e7e5 g1f3 g8f6 f3e5 f6e4
> 7 3.90 502473 11 e2e4 e7e5 g1f3 b8c6 d2d4 e5d4 f3d4 c6d4 d1d4
> 8 25.27 2944173 -6 e2e4 e7e5 g1e2 g8f6 b1c3 c7c5 f2f4 b8c6 f4e5
> c6e5
>
>After null move is enabled (a few extra lines of code -- see below), all hell
>breaks loose with the pv after the 4th iteration.
>
>ply time nodes score pv
> 1 0.00 21 28 d2d4
> 2 0.00 97 -20 d2d4 d7d5
> 3 0.00 469 16 d2d4 d7d5 g1f3
> 4 0.06 1943 -20 d2d4 d7d5 g1f3 g8f6
> 5 0.11 13981 -2 c2c3 b8c6 g1f3 e7e5 d2d4
> 6 0.39 48418 -1 e2e3 b8c6 g1f3 d7d5 d2d4 g8f6
> 7 1.21 147016 20 e2e3 b8c6 g1f3 d7d6 d2d4 e7e5 c1d2
> 8 14.17 1598546 -9 e2e3 b8c6 d2d4 e7e5 d4d5 c6e7 g1f3 g8f6 f3e5
> e7d5
>
>I like the times and node-count but hate the variations even more
>(pieces en prise, etc.)
>
>The related code:
>
> :
> :
> /* No null move if any of the following is true:
> * at a pv node
> * at frontier
> * having made a null move in this variation
> * side to move's king is in check
> * previous move is null move
> * material difference between sides + pawn is still below beta
> * piece material of side to move less than a bishop
> * too deep in the tree
> */
> if (
> !pv_node &&
> depth > 1 &&
> !innull &&
> !c &&
> MATERIAL+ValueP[pawn] > beta &&
> piece_material[side] > ValueP[bishop] &&
> ply < 5
> ) {
> index[ply+1] = index[ply];
> nm.from = 0;
> MakeMove(nm);
> nullscore = -search(-beta, -beta+1, depth-3, 1); /* 1 -> innull */
> UnMakeMove();
> if (nullscore >= beta)
> return(nullscore);
> }
> }
> :
> :
>
>I've tried dropping a variety of the above conditions, to no avail.
>
>Anyone else see lousy pv's upon use of a null move?
>
>--Stuart
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.