From 3a3ca6af0390d74427c218f29cb5fe1a913efb42 Mon Sep 17 00:00:00 2001 From: 31m059 <37052095+31m059@users.noreply.github.com> Date: Fri, 27 Sep 2019 02:45:28 -0400 Subject: [PATCH] Extend castling independently of singular extension A curious feature of Stockfish's current extension code is its repeated use of "else if." In most cases, this makes no functional difference, because no more than one extension is applied; once one extension has been applied, the remaining ones can be safely ignored. However, if most singular extension search conditions are true, except "value < singularBeta", no non-singular extensions (e.g., castling) can be performed! Three tests were submitted, for three of Stockfish's four non-singular extensions. I excluded the shuffle extension, because historically there have been concerns about the fragility of its conditions, and I did not want to risk causing any serious search problems. - Modifying the passed pawn extension appeared roughly neutral at STC. At best, it appeared to be an improvement of less than 1 Elo. - Modifying check extension performed very poorly at STC - Modifying castling extension (this patch) produced a long "yellow" run at STC (insufficient to pass, but positive score) and a strong LTC. In simple terms, prior to this patch castling extension was occasionally not applied during search--on castling moves. The effect of this patch is to perform castling extension on more castling moves. It does so without adding any code complexity, simply by replacing an "else if" with "if" and reordering some existing code. STC: LLR: -2.96 (-2.94,2.94) [0.00,4.00] Total: 108114 W: 23877 L: 23615 D: 60622 http://tests.stockfishchess.org/tests/view/5d8d86bd0ebc590f3beb0c88 LTC: LLR: 2.96 (-2.94,2.94) [0.00,4.00] Total: 20862 W: 3517 L: 3298 D: 14047 http://tests.stockfishchess.org/tests/view/5d8d99cd0ebc590f3beb1899 Bench: 3728191 -------- Where do we go from here? - It seems strange to me that check extension performed so poorly -- clearly some of the singular extension conditions are also very important for check extension. I am not an expert in search, and I do not have any intuition about which of the eight conditions is/are the culprit. I will try a succession of eight STC tests to identify the relevant conditions, then try to replicate this PR for check extension. - Recent tests interacting with the castle extension may deserve retesting. I will shortly resubmit a few of my recent castling extension tweaks, rebased on this PR/commit. My deepest thanks to @noobpwnftw for the extraordinary CPU donation, and to all our other fishtest volunteers, who made it possible for a speculative LTC to pass in 70 minutes! Closes https://github.com/official-stockfish/Stockfish/pull/2331 --- src/search.cpp | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/search.cpp b/src/search.cpp index 2d5fb630..01de12a4 100644 --- a/src/search.cpp +++ b/src/search.cpp @@ -997,10 +997,6 @@ moves_loop: // When in check, search starts from here && (pos.is_discovery_check_on_king(~us, move) || pos.see_ge(move))) extension = ONE_PLY; - // Castling extension - else if (type_of(move) == CASTLING) - extension = ONE_PLY; - // Shuffle extension else if ( PvNode && pos.rule50_count() > 18 @@ -1013,6 +1009,10 @@ moves_loop: // When in check, search starts from here && pos.advanced_pawn_push(move) && pos.pawn_passed(us, to_sq(move))) extension = ONE_PLY; + + // Castling extension + if (type_of(move) == CASTLING) + extension = ONE_PLY; // Calculate new depth for this move newDepth = depth - ONE_PLY + extension; -- 2.39.5