Fix zugzwang pruning issues

By adding pos.non_pawn_material(pos.side_to_move()) as a precondition in step 13,
which is already in use in Futility Pruning (child node) and Null Move Pruning for similar reasons.

Pawn endgames, especially those with only 1 or 2 pawns, are simply heavily influenced by zugzwang situations.

Since we are using a bitbase for KPK endgames, I see no reason to accept buggy evals as shown in #760

Patch looks neutral at STC
LLR: 2.32 (-2.94,2.94) [-3.00,1.00]
Total: 79580 W: 10789 L: 10780 D: 58011

and LTC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 27071 W: 3502 L: 3390 D: 20179

Bench: 6259071

Closes #1051
Closes #760

diff --git a/src/search.cpp b/src/search.cpp
index 85817cd16f36c98183e57503a685215ded87feab..a9e76c452d9ae958603d7bc3efa7ca7dac8ce05c 100644 (file)
--- a/src/search.cpp
+++ b/src/search.cpp
@@ -898,6 +898,7 @@ moves_loop: // When in check search starts from here
 
       // Step 13. Pruning at shallow depth
       if (  !rootNode
+          && pos.non_pawn_material(pos.side_to_move())
           && bestValue > VALUE_MATED_IN_MAX_PLY)
       {
           if (   !captureOrPromotion