NULL Move code question
Posted: Fri Jan 27, 2017 5:49 pm
Consider the CPW code for NULL Move...
I'm questioning the first condition (depth > 2)....
When the call to Search is made, the depth passed to the search will have the following values, based on the original depth.
Org Depth Search Depth
0 n/a
1 n/a
2 n/a
3 0
4 1
5 2
6 3
7 3
Consider org depth of 3. search() will be called with an effective depth of 0 and will drop into QSearch() (in my implementation unless there is a depth extension) and won't do any further search. is that really part of the idea of the Null Move ? Seems to me the threshold for dropping into search() should only occur if a another recursive call to search() can be made.
Is this how others implement it?
Code: Select all
if (depth > 2
&& can_null
&& !is_pv
&& eval(alpha, beta, 1) > beta
&& b.piece_material[b.stm] > e.ENDGAME_MAT
&& !flagInCheck)
{
char ep_old = b.ep;
move_makeNull();
/**********************************************************************
* We use so-called adaptative null move pruning. Size of reduction *
* depends on remaining depth. *
**********************************************************************/
char R = 2;
if (depth > 6) R = 3;
val = -Search(depth - R - 1, ply + 1, -beta, -beta + 1, NO_NULL, NO_PV);
move_unmakeNull(ep_old);
if (time_over) return 0;
if (val >= beta) return beta;
} // end of null move code
When the call to Search is made, the depth passed to the search will have the following values, based on the original depth.
Org Depth Search Depth
0 n/a
1 n/a
2 n/a
3 0
4 1
5 2
6 3
7 3
Consider org depth of 3. search() will be called with an effective depth of 0 and will drop into QSearch() (in my implementation unless there is a depth extension) and won't do any further search. is that really part of the idea of the Null Move ? Seems to me the threshold for dropping into search() should only occur if a another recursive call to search() can be made.
Is this how others implement it?