jplchess wrote:I noticed that Stockfish DD is doing one extra ply in efficiency on blitz games (against Houdini 1.5 or Stockfish 4). Would that be called null move or is it something else?
Your most humble chess player with pattern recognition,
Jonathan Lee
"Would be null move pruning" is not such a bad term actually
That is actually a difference in code with Stockfish 4, it is an idea from Lucas. Stockfish 4 and all the older Stockfishes already did much the same, but only in the last 4 plies. It was called "static null move pruning" but there was no null move involved and the engine did not even do a search, or a reduced search for it. It just looked at the eval and if static evaluation of the node was sufficiently good above alpha, futility margin above alpha, it just returned the eval minus the futility margin.
old Stockfish code:
Code: Select all
// Step 7. Static null move pruning (skipped when in check)
// We're betting that the opponent doesn't have a move that will reduce
// the score by more than futility_margin(depth) if we do a null move.
if ( !PvNode
&& !ss->skipNullMove
&& depth < 4 * ONE_PLY
&& eval - futility_margin(depth, false, (ss-1)->futilityMoveCount) >= beta
&& abs(beta) < VALUE_MATE_IN_MAX_PLY
&& abs(eval) < VALUE_KNOWN_WIN
&& pos.non_pawn_material(pos.side_to_move()))
return eval - futility_margin(depth, false, (ss-1)->futilityMoveCount);
However the engine also did much the same thing one ply before this, but there it did not have an eval yet. An engine first has to make a move before it can evalate the position after the move. But apart from that, it was much the same, but just had to use the evaluation of the ply before , -the evaluation before the move-, so that was much less accurate. Lucas' idea was to bring all that over to the next ply, when you had done an evaluation, that costs something extra but it makes the pruning more accurate. And the name static null move pruning disappeared also, because it did not have much to do with null move. It is done in the last six plies and this you might call your "would be null move pruning"
In Stockfish DD, the above code block is now:
Code: Select all
// Step 7. Futility pruning: child node (skipped when in check)
if ( !PvNode
&& !ss->skipNullMove
&& depth < 7 * ONE_PLY
&& eval - futility_margin(depth) >= beta
&& abs(beta) < VALUE_MATE_IN_MAX_PLY
&& abs(eval) < VALUE_KNOWN_WIN
&& pos.non_pawn_material(pos.side_to_move()))
return eval - futility_margin(depth);
If a node is pruned in this stage, it could also have been pruned by null move later, so there is some overlap near the leaves with null move and I am not sure, it may be a little less null move is done now (you would have to measure that with a profiler). This can help a very little bit, in theory, against Zugzwang and it also might mean a little less threatmoves were found, but the very latest development Stockfish of the last two weeks or so, does not even use threatmoves anymore... The speed up in code compensates.
In Scid Serpent, I now do "would be null move pruning" not in six but in the last eight plies, but I try to be a little more careful doing that than Stockfish DD, because threatmoves have also disappeared. I do not always outright prune but sometimes a reduced search. This I called a ProbCut search because I don't search against alpha, but against alpha + the futility margin.
The short answer would be "Yes, SF DD greater efficiency: would be null move pruning!"
Regards Eelco