From 72a501c6fe5e4e7b61291e9603d0c6cc0902e618 Mon Sep 17 00:00:00 2001 From: joergoster Date: Fri, 7 Apr 2017 17:07:40 -0700 Subject: [PATCH 1/1] 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 --- src/search.cpp | 1 + 1 file changed, 1 insertion(+) diff --git a/src/search.cpp b/src/search.cpp index 85817cd1..a9e76c45 100644 --- 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 -- 2.39.2