From 44a54b63f1ef637a2d35c75b7db2a6559fb34208 Mon Sep 17 00:00:00 2001 From: Joseph Ellis Date: Tue, 11 Aug 2020 13:35:47 -0500 Subject: [PATCH] Don't allow LMP on PvNodes I mentioned this a while back in discord, but nothing seems to have ever come from it. Anyway, to the best of my knowledge most current training data gen is being done at relatively low fixed depths. With this in mind, the change to not allow LMP in PvNodes should result in a fairly significant increase in strength and reliability of the PV. --- src/search.cpp | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/search.cpp b/src/search.cpp index fe1771a3..267672ff 100644 --- a/src/search.cpp +++ b/src/search.cpp @@ -1012,7 +1012,7 @@ moves_loop: // When in check, search starts from here newDepth = depth - 1; // Step 13. Pruning at shallow depth (~200 Elo) - if ( !rootNode + if ( !PvNode && pos.non_pawn_material(us) && bestValue > VALUE_TB_LOSS_IN_MAX_PLY) { @@ -2070,10 +2070,10 @@ namespace Learner // Increase the generation of the substitution table for this thread because it is a new search. //TT.new_search(th->thread_id()); - // If you call new_search here, it may be a loss because you can't use the previous search result. + // ª If you call new_search here, it may be a loss because you can't use the previous search result. // Do not do this here, but caller should do TT.new_search(th->thread_id()) for each station ... - // Because we want to avoid reaching the same final diagram, use the substitution table commonly for all threads when generating teachers. + // ¨Because we want to avoid reaching the same final diagram, use the substitution table commonly for all threads when generating teachers. //#endif } } @@ -2263,7 +2263,7 @@ namespace Learner } // Pass PV_is(ok) to eliminate this PV, there may be NULL_MOVE in the middle. - // PV should not be NULL_MOVE because it is PV + // ¨ PV should not be NULL_MOVE because it is PV // MOVE_WIN has never been thrust. (For now) for (Move move : rootMoves[0].pv) {