1
0
Fork 0
stockfish/src/search.cpp

1979 lines
71 KiB
C++
Raw Normal View History

2008-08-31 23:59:13 -06:00
/*
Stockfish, a UCI chess playing engine derived from Glaurung 2.1
Copyright (C) 2004-2021 The Stockfish developers (see AUTHORS file)
2008-08-31 23:59:13 -06:00
Stockfish is free software: you can redistribute it and/or modify
2008-08-31 23:59:13 -06:00
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
Stockfish is distributed in the hope that it will be useful,
2008-08-31 23:59:13 -06:00
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
2008-08-31 23:59:13 -06:00
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
#include <algorithm>
2008-08-31 23:59:13 -06:00
#include <cassert>
#include <cmath>
#include <cstring> // For std::memset
#include <iostream>
2008-08-31 23:59:13 -06:00
#include <sstream>
#include "evaluate.h"
#include "misc.h"
#include "movegen.h"
2008-08-31 23:59:13 -06:00
#include "movepick.h"
#include "position.h"
2008-08-31 23:59:13 -06:00
#include "search.h"
#include "thread.h"
#include "timeman.h"
2008-08-31 23:59:13 -06:00
#include "tt.h"
#include "uci.h"
2015-01-18 00:05:05 -07:00
#include "syzygy/tbprobe.h"
namespace Stockfish {
namespace Search {
LimitsType Limits;
}
2015-01-18 00:05:05 -07:00
namespace Tablebases {
int Cardinality;
bool RootInTB;
bool UseRule50;
Depth ProbeDepth;
}
namespace TB = Tablebases;
using std::string;
using Eval::evaluate;
using namespace Search;
2008-08-31 23:59:13 -06:00
namespace {
// Different node types, used as a template parameter
enum NodeType { NonPV, PV, Root };
// Futility margin
Value futility_margin(Depth d, bool improving) {
return Value(214 * (d - improving));
}
2008-08-31 23:59:13 -06:00
// Reductions lookup table, initialized at startup
int Reductions[MAX_MOVES]; // [depth or moveNumber]
Depth reduction(bool i, Depth d, int mn, bool rangeReduction) {
Eliminate ONE_PLY Simplification that eliminates ONE_PLY, based on a suggestion in the forum that support for fractional plies has never been used, and @mcostalba's openness to the idea of eliminating it. We lose a little bit of type safety by making Depth an integer, but in return we simplify the code in search.cpp quite significantly. No functional change ------------------------------------------ The argument favoring eliminating ONE_PLY: * The term “ONE_PLY” comes up in a lot of forum posts (474 to date) https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:relevance * There is occasionally a commit that breaks invariance of the code with respect to ONE_PLY https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:date/fishcooking/ZIPdYj6k0fk/KdNGcPWeBgAJ * To prevent such commits, there is a Travis CI hack that doubles ONE_PLY and rechecks bench * Sustaining ONE_PLY has, alas, not resulted in any improvements to the engine, despite many individuals testing many experiments over 5 years. The strongest argument in favor of preserving ONE_PLY comes from @locutus: “If we use par example ONE_PLY=256 the parameter space is increases by the factor 256. So it seems very unlikely that the optimal setting is in the subspace of ONE_PLY=1.” There is a strong theoretical impediment to fractional depth systems: the transposition table uses depth to determine when a stored result is good enough to supply an answer for a current search. If you have fractional depths, then different pathways to the position can be at fractionally different depths. In the end, there are three separate times when a proposal to remove ONE_PLY was defeated by the suggestion to “give it a few more months.” So… it seems like time to remove this distraction from the community. See the pull request here: https://github.com/official-stockfish/Stockfish/pull/2289
2019-09-28 14:27:23 -06:00
int r = Reductions[d] * Reductions[mn];
return (r + 534) / 1024 + (!i && r > 904) + rangeReduction;
}
constexpr int futility_move_count(bool improving, Depth depth) {
return (3 + depth * depth) / (2 - improving);
}
// History and stats update bonus, based on depth
Eliminate ONE_PLY Simplification that eliminates ONE_PLY, based on a suggestion in the forum that support for fractional plies has never been used, and @mcostalba's openness to the idea of eliminating it. We lose a little bit of type safety by making Depth an integer, but in return we simplify the code in search.cpp quite significantly. No functional change ------------------------------------------ The argument favoring eliminating ONE_PLY: * The term “ONE_PLY” comes up in a lot of forum posts (474 to date) https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:relevance * There is occasionally a commit that breaks invariance of the code with respect to ONE_PLY https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:date/fishcooking/ZIPdYj6k0fk/KdNGcPWeBgAJ * To prevent such commits, there is a Travis CI hack that doubles ONE_PLY and rechecks bench * Sustaining ONE_PLY has, alas, not resulted in any improvements to the engine, despite many individuals testing many experiments over 5 years. The strongest argument in favor of preserving ONE_PLY comes from @locutus: “If we use par example ONE_PLY=256 the parameter space is increases by the factor 256. So it seems very unlikely that the optimal setting is in the subspace of ONE_PLY=1.” There is a strong theoretical impediment to fractional depth systems: the transposition table uses depth to determine when a stored result is good enough to supply an answer for a current search. If you have fractional depths, then different pathways to the position can be at fractionally different depths. In the end, there are three separate times when a proposal to remove ONE_PLY was defeated by the suggestion to “give it a few more months.” So… it seems like time to remove this distraction from the community. See the pull request here: https://github.com/official-stockfish/Stockfish/pull/2289
2019-09-28 14:27:23 -06:00
int stat_bonus(Depth d) {
return std::min((6 * d + 229) * d - 215 , 2000);
}
// Add a small random component to draw evaluations to avoid 3-fold blindness
Value value_draw(Thread* thisThread) {
return VALUE_DRAW + Value(2 * (thisThread->nodes & 1) - 1);
}
Detect search explosions This patch detects some search explosions (due to double extensions in search.cpp) which can happen in some pathological positions, and takes measures to ensure progress in search even for these pathological situations. While a small number of double extensions can be useful during search (for example to resolve a tactical sequence), a sustained regime of double extensions leads to search explosion and a non-finishing search. See the discussion in https://github.com/official-stockfish/Stockfish/pull/3544 and the issue https://github.com/official-stockfish/Stockfish/issues/3532 . The implemented algorithm is the following: a) at each node during search, store the current depth in the stack. Double extensions are by definition levels of the stack where the depth at ply N is strictly higher than depth at ply N-1. b) during search, calculate for each thread a running average of the number of double extensions in the last 4096 visited nodes. c) if one thread has more than 2% of double extensions for a sustained period of time (6 millions consecutive nodes, or about 4 seconds on my iMac), we decide that this thread is in an explosion state and we calm down this thread by preventing it to do any double extension for the next 6 millions nodes. To calculate the running averages, we also introduced a auxiliary class generalizing the computations of ttHitAverage variable we already had in code. The implementation uses an exponential moving average of period 4096 and resolution 1/1024, and all computations are done with integers for efficiency. ----------- Example where the patch solves a search explosion: ``` ./stockfish ucinewgame position fen 8/Pk6/8/1p6/8/P1K5/8/6B1 w - - 37 130 go infinite ``` This algorithm does not affect search in normal, non-pathological positions. We verified, for instance, that the usual bench is unchanged up to depth 20 at least, and that the node numbers are unchanged for a search of the starting position at depth 32. ------------- See https://github.com/official-stockfish/Stockfish/pull/3714 Bench: 5575265
2021-09-23 15:19:06 -06:00
// Check if the current thread is in a search explosion
ExplosionState search_explosion(Thread* thisThread) {
uint64_t nodesNow = thisThread->nodes;
bool explosive = thisThread->doubleExtensionAverage[WHITE].is_greater(2, 100)
|| thisThread->doubleExtensionAverage[BLACK].is_greater(2, 100);
if (explosive)
thisThread->nodesLastExplosive = nodesNow;
else
thisThread->nodesLastNormal = nodesNow;
if ( explosive
&& thisThread->state == EXPLOSION_NONE
&& nodesNow - thisThread->nodesLastNormal > 6000000)
thisThread->state = MUST_CALM_DOWN;
if ( thisThread->state == MUST_CALM_DOWN
&& nodesNow - thisThread->nodesLastExplosive > 6000000)
thisThread->state = EXPLOSION_NONE;
return thisThread->state;
}
// Skill structure is used to implement strength limit. If we have an uci_elo then
// we convert it to a suitable fractional skill level using anchoring to CCRL Elo
// (goldfish 1.13 = 2000) and a fit through Ordo derived Elo for match (TC 60+0.6)
// results spanning a wide range of k values.
struct Skill {
Skill(int skill_level, int uci_elo) {
if (uci_elo)
level = std::clamp(std::pow((uci_elo - 1346.6) / 143.4, 1 / 0.806), 0.0, 20.0);
else
level = double(skill_level);
}
bool enabled() const { return level < 20.0; }
bool time_to_pick(Depth depth) const { return depth == 1 + int(level); }
Move pick_best(size_t multiPV);
double level;
Move best = MOVE_NONE;
};
template <NodeType nodeType>
Value search(Position& pos, Stack* ss, Value alpha, Value beta, Depth depth, bool cutNode);
template <NodeType nodeType>
Eliminate ONE_PLY Simplification that eliminates ONE_PLY, based on a suggestion in the forum that support for fractional plies has never been used, and @mcostalba's openness to the idea of eliminating it. We lose a little bit of type safety by making Depth an integer, but in return we simplify the code in search.cpp quite significantly. No functional change ------------------------------------------ The argument favoring eliminating ONE_PLY: * The term “ONE_PLY” comes up in a lot of forum posts (474 to date) https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:relevance * There is occasionally a commit that breaks invariance of the code with respect to ONE_PLY https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:date/fishcooking/ZIPdYj6k0fk/KdNGcPWeBgAJ * To prevent such commits, there is a Travis CI hack that doubles ONE_PLY and rechecks bench * Sustaining ONE_PLY has, alas, not resulted in any improvements to the engine, despite many individuals testing many experiments over 5 years. The strongest argument in favor of preserving ONE_PLY comes from @locutus: “If we use par example ONE_PLY=256 the parameter space is increases by the factor 256. So it seems very unlikely that the optimal setting is in the subspace of ONE_PLY=1.” There is a strong theoretical impediment to fractional depth systems: the transposition table uses depth to determine when a stored result is good enough to supply an answer for a current search. If you have fractional depths, then different pathways to the position can be at fractionally different depths. In the end, there are three separate times when a proposal to remove ONE_PLY was defeated by the suggestion to “give it a few more months.” So… it seems like time to remove this distraction from the community. See the pull request here: https://github.com/official-stockfish/Stockfish/pull/2289
2019-09-28 14:27:23 -06:00
Value qsearch(Position& pos, Stack* ss, Value alpha, Value beta, Depth depth = 0);
Value value_to_tt(Value v, int ply);
Fix incorrect mate score. Current master 648c7ec25db2040c0af34dd846dfa3f57af5ad0a will generate an incorrect mate score for: ``` setoption name Hash value 8 setoption name Threads value 1 position fen 8/1p2KP2/1p4q1/1Pp5/2P5/N1Pp1k2/3P4/1N6 b - - 76 40 go depth 49 ``` even though the position is a draw. Generally, SF tries to display only proven mate scores, so this is a bug. This was posted http://www.talkchess.com/forum3/viewtopic.php?f=2&t=72166 by Uri Blass, with the correct analysis that this must be related to the 50 moves draw rule being ignored somewhere. Indeed, this is possible as positions and there eval are stored in the TT, without reference to the 50mr counter. Depending on the search path followed a position can thus be mate or draw in the TT (GHI or Graph history interaction). Therefore, to prove mate lines, the TT content has to be used with care. Rather than ignoring TT content in general or for mate scores (which impact search or mate finding), it is possible to be more selective. In particular, @WOnder93 suggested to only ignore the TT if the 50mr draw ply is closer than the mate ply. This patch implements this idea, by clamping the eval in the TT to +-VALUE_MATED_IN_MAX_PLY. This retains the TTmove, but causes a research of these lines (with the current 50mr counter) as needed. This patch hardly ever affects search (as indicated by the unchanged bench), but fixes the testcase. As the conditions are very specific, also mate finding will almost never be less efficient (testing welcome). It was also shown to pass STC and LTC non-regression testing, in a form using if/then/else instead of ternary operators: STC: LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 93605 W: 15346 L: 15340 D: 62919 http://tests.stockfishchess.org/tests/view/5db45bb00ebc5908127538d4 LTC: LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 33873 W: 7359 L: 7261 D: 19253 http://tests.stockfishchess.org/tests/view/5db4c8940ebc5902d6b146fc closes https://github.com/official-stockfish/Stockfish/issues/2370 Bench: 4362323
2019-10-26 08:34:19 -06:00
Value value_from_tt(Value v, int ply, int r50c);
void update_pv(Move* pv, Move move, Move* childPv);
void update_continuation_histories(Stack* ss, Piece pc, Square to, int bonus);
void update_quiet_stats(const Position& pos, Stack* ss, Move move, int bonus, int depth);
void update_all_stats(const Position& pos, Stack* ss, Move bestMove, Value bestValue, Value beta, Square prevSq,
Revert 5 recent patches Revert 5 patches which were merged, but lead to a regression test that showed negative Elo gain: http://tests.stockfishchess.org/tests/view/5e307251ab2d69d58394fdb9 This was discussed in depth in: https://github.com/official-stockfish/Stockfish/issues/2531 Each patch was removed and tested as a simplification, full list below, and the whole combo as well. After the revert the regression test showed a neutral result: http://tests.stockfishchess.org/tests/view/5e334851708b13464ceea33c As a result of this experience, the SPRT testing bounds will be made more strict. Reverted patches: 1 Dynamic Complexity 6d0eabd5fe2961551477820ab7619e2c31e01ffd : STC 10+0.1 https://tests.stockfishchess.org/tests/view/5e31fcacec661e2e6a340d08 : LLR: 2.97 (-2.94,2.94) {-1.50,0.50} Total: 38130 W: 7326 L: 7189 D: 23615 Ptnml(0-2): 677, 4346, 8843, 4545, 646 LTC 60+0.6 https://tests.stockfishchess.org/tests/view/5e32c18fec661e2e6a340d73 : LLR: 2.94 (-2.94,2.94) {-1.50,0.50} Total: 38675 W: 4941 L: 4866 D: 28868 Ptnml(0-2): 270, 3556, 11429, 3584, 291 3 More bonus for bestMoves on past PV nodes 71e0b5385e2717679a57c6b77d8c7ac5fff3b89f : STC 10+0.1 https://tests.stockfishchess.org/tests/view/5e31fe93ec661e2e6a340d10 : LLR: 2.95 (-2.94,2.94) {-1.50,0.50} Total: 46100 W: 8853 L: 8727 D: 28520 Ptnml(0-2): 796, 5297, 10749, 5387, 813 LTC 60+0.6 https://tests.stockfishchess.org/tests/view/5e32c187ec661e2e6a340d71 : LLR: 2.96 (-2.94,2.94) {-1.50,0.50} Total: 16920 W: 2161 L: 2055 D: 12704 Ptnml(0-2): 115, 1498, 5006, 1569, 130 4 Tweak Restricted Piece Bonus 0ae00454ba6928d181b46103e5c83e6d58fcebe5 : STC 10+0.1 https://tests.stockfishchess.org/tests/view/5e31fefaec661e2e6a340d15 : LLR: 2.94 (-2.94,2.94) {-1.50,0.50} Total: 88328 W: 17060 L: 16997 D: 54271 Ptnml(0-2): 1536, 10446, 20169, 10422, 1581 LTC 60+0.6 https://tests.stockfishchess.org/tests/view/5e32c17aec661e2e6a340d6f : LLR: 2.95 (-2.94,2.94) {-1.50,0.50} Total: 34784 W: 4551 L: 4466 D: 25767 Ptnml(0-2): 255, 3279, 10061, 3345, 262 5 History update for pruned captures 01b6088af39902001d2d6844561b6a2faa549282 : STC 10+0.1 https://tests.stockfishchess.org/tests/view/5e31ff5eec661e2e6a340d1a : LLR: 2.94 (-2.94,2.94) {-1.50,0.50} Total: 29541 W: 5735 L: 5588 D: 18218 Ptnml(0-2): 483, 3445, 6820, 3469, 545 LTC 60+0.6 https://tests.stockfishchess.org/tests/view/5e32c196ec661e2e6a340d75 : LLR: 2.94 (-2.94,2.94) {-1.50,0.50} Total: 22177 W: 2854 L: 2757 D: 16566 Ptnml(0-2): 143, 2005, 6555, 2055, 164 6 Tweak trapped rook penalty 18fc21eba0368fd5e3c4c4b8ee1000c9ac445425 : STC 10+0.1 https://tests.stockfishchess.org/tests/view/5e31ffb1ec661e2e6a340d1c : LLR: 2.95 (-2.94,2.94) {-1.50,0.50} Total: 24476 W: 4727 L: 4569 D: 15180 Ptnml(0-2): 390, 2834, 5659, 2933, 417 LTC 60+0.6 https://tests.stockfishchess.org/tests/view/5e32c19eec661e2e6a340d77 : LLR: 2.95 (-2.94,2.94) {-1.50,0.50} Total: 97332 W: 12492 L: 12466 D: 72374 Ptnml(0-2): 690, 9107, 28738, 9034, 720 All 5 as one simplification : LTC 60+0.6 https://tests.stockfishchess.org/tests/view/5e334098708b13464ceea330 : LLR: 2.94 (-2.94,2.94) {-1.50,0.50} Total: 7829 W: 1079 L: 964 D: 5786 Ptnml(0-2): 52, 690, 2281, 781, 65 Bench: 5153165
2020-01-30 13:44:04 -07:00
Move* quietsSearched, int quietCount, Move* capturesSearched, int captureCount, Depth depth);
2008-08-31 23:59:13 -06:00
// perft() is our utility to verify move generation. All the leaf nodes up
// to the given depth are generated and counted, and the sum is returned.
template<bool Root>
uint64_t perft(Position& pos, Depth depth) {
StateInfo st;
ASSERT_ALIGNED(&st, Eval::NNUE::CacheLineSize);
uint64_t cnt, nodes = 0;
Eliminate ONE_PLY Simplification that eliminates ONE_PLY, based on a suggestion in the forum that support for fractional plies has never been used, and @mcostalba's openness to the idea of eliminating it. We lose a little bit of type safety by making Depth an integer, but in return we simplify the code in search.cpp quite significantly. No functional change ------------------------------------------ The argument favoring eliminating ONE_PLY: * The term “ONE_PLY” comes up in a lot of forum posts (474 to date) https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:relevance * There is occasionally a commit that breaks invariance of the code with respect to ONE_PLY https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:date/fishcooking/ZIPdYj6k0fk/KdNGcPWeBgAJ * To prevent such commits, there is a Travis CI hack that doubles ONE_PLY and rechecks bench * Sustaining ONE_PLY has, alas, not resulted in any improvements to the engine, despite many individuals testing many experiments over 5 years. The strongest argument in favor of preserving ONE_PLY comes from @locutus: “If we use par example ONE_PLY=256 the parameter space is increases by the factor 256. So it seems very unlikely that the optimal setting is in the subspace of ONE_PLY=1.” There is a strong theoretical impediment to fractional depth systems: the transposition table uses depth to determine when a stored result is good enough to supply an answer for a current search. If you have fractional depths, then different pathways to the position can be at fractionally different depths. In the end, there are three separate times when a proposal to remove ONE_PLY was defeated by the suggestion to “give it a few more months.” So… it seems like time to remove this distraction from the community. See the pull request here: https://github.com/official-stockfish/Stockfish/pull/2289
2019-09-28 14:27:23 -06:00
const bool leaf = (depth == 2);
for (const auto& m : MoveList<LEGAL>(pos))
{
Eliminate ONE_PLY Simplification that eliminates ONE_PLY, based on a suggestion in the forum that support for fractional plies has never been used, and @mcostalba's openness to the idea of eliminating it. We lose a little bit of type safety by making Depth an integer, but in return we simplify the code in search.cpp quite significantly. No functional change ------------------------------------------ The argument favoring eliminating ONE_PLY: * The term “ONE_PLY” comes up in a lot of forum posts (474 to date) https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:relevance * There is occasionally a commit that breaks invariance of the code with respect to ONE_PLY https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:date/fishcooking/ZIPdYj6k0fk/KdNGcPWeBgAJ * To prevent such commits, there is a Travis CI hack that doubles ONE_PLY and rechecks bench * Sustaining ONE_PLY has, alas, not resulted in any improvements to the engine, despite many individuals testing many experiments over 5 years. The strongest argument in favor of preserving ONE_PLY comes from @locutus: “If we use par example ONE_PLY=256 the parameter space is increases by the factor 256. So it seems very unlikely that the optimal setting is in the subspace of ONE_PLY=1.” There is a strong theoretical impediment to fractional depth systems: the transposition table uses depth to determine when a stored result is good enough to supply an answer for a current search. If you have fractional depths, then different pathways to the position can be at fractionally different depths. In the end, there are three separate times when a proposal to remove ONE_PLY was defeated by the suggestion to “give it a few more months.” So… it seems like time to remove this distraction from the community. See the pull request here: https://github.com/official-stockfish/Stockfish/pull/2289
2019-09-28 14:27:23 -06:00
if (Root && depth <= 1)
cnt = 1, nodes++;
else
{
pos.do_move(m, st);
Eliminate ONE_PLY Simplification that eliminates ONE_PLY, based on a suggestion in the forum that support for fractional plies has never been used, and @mcostalba's openness to the idea of eliminating it. We lose a little bit of type safety by making Depth an integer, but in return we simplify the code in search.cpp quite significantly. No functional change ------------------------------------------ The argument favoring eliminating ONE_PLY: * The term “ONE_PLY” comes up in a lot of forum posts (474 to date) https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:relevance * There is occasionally a commit that breaks invariance of the code with respect to ONE_PLY https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:date/fishcooking/ZIPdYj6k0fk/KdNGcPWeBgAJ * To prevent such commits, there is a Travis CI hack that doubles ONE_PLY and rechecks bench * Sustaining ONE_PLY has, alas, not resulted in any improvements to the engine, despite many individuals testing many experiments over 5 years. The strongest argument in favor of preserving ONE_PLY comes from @locutus: “If we use par example ONE_PLY=256 the parameter space is increases by the factor 256. So it seems very unlikely that the optimal setting is in the subspace of ONE_PLY=1.” There is a strong theoretical impediment to fractional depth systems: the transposition table uses depth to determine when a stored result is good enough to supply an answer for a current search. If you have fractional depths, then different pathways to the position can be at fractionally different depths. In the end, there are three separate times when a proposal to remove ONE_PLY was defeated by the suggestion to “give it a few more months.” So… it seems like time to remove this distraction from the community. See the pull request here: https://github.com/official-stockfish/Stockfish/pull/2289
2019-09-28 14:27:23 -06:00
cnt = leaf ? MoveList<LEGAL>(pos).size() : perft<false>(pos, depth - 1);
nodes += cnt;
pos.undo_move(m);
}
if (Root)
sync_cout << UCI::move(m, pos.is_chess960()) << ": " << cnt << sync_endl;
}
return nodes;
}
} // namespace
2008-08-31 23:59:13 -06:00
/// Search::init() is called at startup to initialize various lookup tables
2008-08-31 23:59:13 -06:00
void Search::init() {
for (int i = 1; i < MAX_MOVES; ++i)
Reductions[i] = int((21.9 + std::log(Threads.size()) / 2) * std::log(i));
}
/// Search::clear() resets search state to its initial value
void Search::clear() {
Threads.main()->wait_for_search_finished();
Time.availableNodes = 0;
TT.clear();
Threads.clear();
Tablebases::init(Options["SyzygyPath"]); // Free mapped files
}
/// MainThread::search() is started when the program receives the UCI 'go'
/// command. It searches from the root position and outputs the "bestmove".
2008-08-31 23:59:13 -06:00
void MainThread::search() {
2008-08-31 23:59:13 -06:00
if (Limits.perft)
{
Eliminate ONE_PLY Simplification that eliminates ONE_PLY, based on a suggestion in the forum that support for fractional plies has never been used, and @mcostalba's openness to the idea of eliminating it. We lose a little bit of type safety by making Depth an integer, but in return we simplify the code in search.cpp quite significantly. No functional change ------------------------------------------ The argument favoring eliminating ONE_PLY: * The term “ONE_PLY” comes up in a lot of forum posts (474 to date) https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:relevance * There is occasionally a commit that breaks invariance of the code with respect to ONE_PLY https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:date/fishcooking/ZIPdYj6k0fk/KdNGcPWeBgAJ * To prevent such commits, there is a Travis CI hack that doubles ONE_PLY and rechecks bench * Sustaining ONE_PLY has, alas, not resulted in any improvements to the engine, despite many individuals testing many experiments over 5 years. The strongest argument in favor of preserving ONE_PLY comes from @locutus: “If we use par example ONE_PLY=256 the parameter space is increases by the factor 256. So it seems very unlikely that the optimal setting is in the subspace of ONE_PLY=1.” There is a strong theoretical impediment to fractional depth systems: the transposition table uses depth to determine when a stored result is good enough to supply an answer for a current search. If you have fractional depths, then different pathways to the position can be at fractionally different depths. In the end, there are three separate times when a proposal to remove ONE_PLY was defeated by the suggestion to “give it a few more months.” So… it seems like time to remove this distraction from the community. See the pull request here: https://github.com/official-stockfish/Stockfish/pull/2289
2019-09-28 14:27:23 -06:00
nodes = perft<true>(rootPos, Limits.perft);
sync_cout << "\nNodes searched: " << nodes << "\n" << sync_endl;
return;
}
Color us = rootPos.side_to_move();
Time.init(Limits, us, rootPos.game_ply());
TT.new_search();
Eval::NNUE::verify();
Add NNUE evaluation This patch ports the efficiently updatable neural network (NNUE) evaluation to Stockfish. Both the NNUE and the classical evaluations are available, and can be used to assign a value to a position that is later used in alpha-beta (PVS) search to find the best move. The classical evaluation computes this value as a function of various chess concepts, handcrafted by experts, tested and tuned using fishtest. The NNUE evaluation computes this value with a neural network based on basic inputs. The network is optimized and trained on the evalutions of millions of positions at moderate search depth. The NNUE evaluation was first introduced in shogi, and ported to Stockfish afterward. It can be evaluated efficiently on CPUs, and exploits the fact that only parts of the neural network need to be updated after a typical chess move. [The nodchip repository](https://github.com/nodchip/Stockfish) provides additional tools to train and develop the NNUE networks. This patch is the result of contributions of various authors, from various communities, including: nodchip, ynasu87, yaneurao (initial port and NNUE authors), domschl, FireFather, rqs, xXH4CKST3RXx, tttak, zz4032, joergoster, mstembera, nguyenpham, erbsenzaehler, dorzechowski, and vondele. This new evaluation needed various changes to fishtest and the corresponding infrastructure, for which tomtor, ppigazzini, noobpwnftw, daylen, and vondele are gratefully acknowledged. The first networks have been provided by gekkehenker and sergiovieri, with the latter net (nn-97f742aaefcd.nnue) being the current default. The evaluation function can be selected at run time with the `Use NNUE` (true/false) UCI option, provided the `EvalFile` option points the the network file (depending on the GUI, with full path). The performance of the NNUE evaluation relative to the classical evaluation depends somewhat on the hardware, and is expected to improve quickly, but is currently on > 80 Elo on fishtest: 60000 @ 10+0.1 th 1 https://tests.stockfishchess.org/tests/view/5f28fe6ea5abc164f05e4c4c ELO: 92.77 +-2.1 (95%) LOS: 100.0% Total: 60000 W: 24193 L: 8543 D: 27264 Ptnml(0-2): 609, 3850, 9708, 10948, 4885 40000 @ 20+0.2 th 8 https://tests.stockfishchess.org/tests/view/5f290229a5abc164f05e4c58 ELO: 89.47 +-2.0 (95%) LOS: 100.0% Total: 40000 W: 12756 L: 2677 D: 24567 Ptnml(0-2): 74, 1583, 8550, 7776, 2017 At the same time, the impact on the classical evaluation remains minimal, causing no significant regression: sprt @ 10+0.1 th 1 https://tests.stockfishchess.org/tests/view/5f2906a2a5abc164f05e4c5b LLR: 2.94 (-2.94,2.94) {-6.00,-4.00} Total: 34936 W: 6502 L: 6825 D: 21609 Ptnml(0-2): 571, 4082, 8434, 3861, 520 sprt @ 60+0.6 th 1 https://tests.stockfishchess.org/tests/view/5f2906cfa5abc164f05e4c5d LLR: 2.93 (-2.94,2.94) {-6.00,-4.00} Total: 10088 W: 1232 L: 1265 D: 7591 Ptnml(0-2): 49, 914, 3170, 843, 68 The needed networks can be found at https://tests.stockfishchess.org/nns It is recommended to use the default one as indicated by the `EvalFile` UCI option. Guidelines for testing new nets can be found at https://github.com/glinscott/fishtest/wiki/Creating-my-first-test#nnue-net-tests Integration has been discussed in various issues: https://github.com/official-stockfish/Stockfish/issues/2823 https://github.com/official-stockfish/Stockfish/issues/2728 The integration branch will be closed after the merge: https://github.com/official-stockfish/Stockfish/pull/2825 https://github.com/official-stockfish/Stockfish/tree/nnue-player-wip closes https://github.com/official-stockfish/Stockfish/pull/2912 This will be an exciting time for computer chess, looking forward to seeing the evolution of this approach. Bench: 4746616
2020-08-05 09:11:15 -06:00
if (rootMoves.empty())
{
rootMoves.emplace_back(MOVE_NONE);
sync_cout << "info depth 0 score "
<< UCI::value(rootPos.checkers() ? -VALUE_MATE : VALUE_DRAW)
<< sync_endl;
}
else
{
Threads.start_searching(); // start non-main threads
Thread::search(); // main thread start searching
}
// When we reach the maximum depth, we can arrive here without a raise of
// Threads.stop. However, if we are pondering or in an infinite search,
// the UCI protocol states that we shouldn't print the best move before the
// GUI sends a "stop" or "ponderhit" command. We therefore simply wait here
// until the GUI sends one of those commands.
while (!Threads.stop && (ponder || Limits.infinite))
{} // Busy wait for a stop or a ponder reset
// Stop the threads if not already stopped (also raise the stop if
// "ponderhit" just reset Threads.ponder).
Threads.stop = true;
// Wait until all threads have finished
Threads.wait_for_search_finished();
// When playing in 'nodes as time' mode, subtract the searched nodes from
// the available ones before exiting.
if (Limits.npmsec)
Time.availableNodes += Limits.inc[us] - Threads.nodes_searched();
Thread* bestThread = this;
Skill skill = Skill(Options["Skill Level"], Options["UCI_LimitStrength"] ? int(Options["UCI_Elo"]) : 0);
if ( int(Options["MultiPV"]) == 1
&& !Limits.depth
&& !skill.enabled()
&& rootMoves[0].pv[0] != MOVE_NONE)
bestThread = Threads.get_best_thread();
bestPreviousScore = bestThread->rootMoves[0].score;
// Send again PV info if we have a new best thread
if (bestThread != this)
sync_cout << UCI::pv(bestThread->rootPos, bestThread->completedDepth, -VALUE_INFINITE, VALUE_INFINITE) << sync_endl;
sync_cout << "bestmove " << UCI::move(bestThread->rootMoves[0].pv[0], rootPos.is_chess960());
if (bestThread->rootMoves[0].pv.size() > 1 || bestThread->rootMoves[0].extract_ponder_from_tt(rootPos))
std::cout << " ponder " << UCI::move(bestThread->rootMoves[0].pv[1], rootPos.is_chess960());
std::cout << sync_endl;
2008-08-31 23:59:13 -06:00
}
/// Thread::search() is the main iterative deepening loop. It calls search()
/// repeatedly with increasing depth until the allocated thinking time has been
/// consumed, the user stops the search, or the maximum search depth is reached.
2008-08-31 23:59:13 -06:00
void Thread::search() {
2008-08-31 23:59:13 -06:00
// To allow access to (ss-7) up to (ss+2), the stack must be oversized.
// The former is needed to allow update_continuation_histories(ss-1, ...),
// which accesses its argument at ss-6, also near the root.
// The latter is needed for statScore and killer initialization.
Stack stack[MAX_PLY+10], *ss = stack+7;
Move pv[MAX_PLY+1];
Value bestValue, alpha, beta, delta;
Move lastBestMove = MOVE_NONE;
Eliminate ONE_PLY Simplification that eliminates ONE_PLY, based on a suggestion in the forum that support for fractional plies has never been used, and @mcostalba's openness to the idea of eliminating it. We lose a little bit of type safety by making Depth an integer, but in return we simplify the code in search.cpp quite significantly. No functional change ------------------------------------------ The argument favoring eliminating ONE_PLY: * The term “ONE_PLY” comes up in a lot of forum posts (474 to date) https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:relevance * There is occasionally a commit that breaks invariance of the code with respect to ONE_PLY https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:date/fishcooking/ZIPdYj6k0fk/KdNGcPWeBgAJ * To prevent such commits, there is a Travis CI hack that doubles ONE_PLY and rechecks bench * Sustaining ONE_PLY has, alas, not resulted in any improvements to the engine, despite many individuals testing many experiments over 5 years. The strongest argument in favor of preserving ONE_PLY comes from @locutus: “If we use par example ONE_PLY=256 the parameter space is increases by the factor 256. So it seems very unlikely that the optimal setting is in the subspace of ONE_PLY=1.” There is a strong theoretical impediment to fractional depth systems: the transposition table uses depth to determine when a stored result is good enough to supply an answer for a current search. If you have fractional depths, then different pathways to the position can be at fractionally different depths. In the end, there are three separate times when a proposal to remove ONE_PLY was defeated by the suggestion to “give it a few more months.” So… it seems like time to remove this distraction from the community. See the pull request here: https://github.com/official-stockfish/Stockfish/pull/2289
2019-09-28 14:27:23 -06:00
Depth lastBestMoveDepth = 0;
MainThread* mainThread = (this == Threads.main() ? Threads.main() : nullptr);
double timeReduction = 1, totBestMoveChanges = 0;
Introduce dynamic contempt Make contempt dependent on the current score of the root position. The idea is that we now use a linear formula like the following to decide on the contempt to use during a search : contempt = x + y * eval where x is the base contempt set by the user in the "Contempt" UCI option, and y * eval is the dynamic part which adapts itself to the estimation of the evaluation of the root position returned by the search. In this patch, we use x = 18 centipawns by default, and the y * eval correction can go from -20 centipawns if the root eval is less than -2.0 pawns, up to +20 centipawns when the root eval is more than 2.0 pawns. To summarize, the new contempt goes from -0.02 to 0.38 pawns, depending if Stockfish is losing or winning, with an average value of 0.18 pawns by default. STC: LLR: 2.95 (-2.94,2.94) [0.00,5.00] Total: 110052 W: 24614 L: 23938 D: 61500 http://tests.stockfishchess.org/tests/view/5a72e6020ebc590f2c86ea20 LTC: LLR: 2.97 (-2.94,2.94) [0.00,5.00] Total: 16470 W: 2896 L: 2705 D: 10869 http://tests.stockfishchess.org/tests/view/5a76c5b90ebc5902971a9830 A second match at LTC was organised against the current master: ELO: 1.45 +-2.9 (95%) LOS: 84.0% Total: 19369 W: 3350 L: 3269 D: 12750 http://tests.stockfishchess.org/tests/view/5a7acf980ebc5902971a9a2e Finally, we checked that there is no apparent problem with multithreading, despite the fact that some threads might have a slightly different contempt level that the main thread. Match of this version against master, both using 5 threads, time control 30+0.3: ELO: 2.18 +-3.2 (95%) LOS: 90.8% Total: 14840 W: 2502 L: 2409 D: 9929 http://tests.stockfishchess.org/tests/view/5a7bf3e80ebc5902971a9aa2 Include suggestions from Marco Costalba, Aram Tumanian, Ronald de Man, etc. Bench: 5207156
2018-02-09 10:43:53 -07:00
Color us = rootPos.side_to_move();
int iterIdx = 0;
std::memset(ss-7, 0, 10 * sizeof(Stack));
for (int i = 7; i > 0; i--)
(ss-i)->continuationHistory = &this->continuationHistory[0][0][NO_PIECE][0]; // Use as a sentinel
for (int i = 0; i <= MAX_PLY + 2; ++i)
(ss+i)->ply = i;
ss->pv = pv;
bestValue = delta = alpha = -VALUE_INFINITE;
beta = VALUE_INFINITE;
if (mainThread)
{
if (mainThread->bestPreviousScore == VALUE_INFINITE)
for (int i = 0; i < 4; ++i)
mainThread->iterValue[i] = VALUE_ZERO;
else
for (int i = 0; i < 4; ++i)
mainThread->iterValue[i] = mainThread->bestPreviousScore;
}
std::copy(&lowPlyHistory[2][0], &lowPlyHistory.back().back() + 1, &lowPlyHistory[0][0]);
std::fill(&lowPlyHistory[MAX_LPH - 2][0], &lowPlyHistory.back().back() + 1, 0);
size_t multiPV = size_t(Options["MultiPV"]);
Skill skill(Options["Skill Level"], Options["UCI_LimitStrength"] ? int(Options["UCI_Elo"]) : 0);
// When playing with strength handicap enable MultiPV search that we will
// use behind the scenes to retrieve a set of possible moves.
if (skill.enabled())
multiPV = std::max(multiPV, (size_t)4);
multiPV = std::min(multiPV, rootMoves.size());
Detect search explosions This patch detects some search explosions (due to double extensions in search.cpp) which can happen in some pathological positions, and takes measures to ensure progress in search even for these pathological situations. While a small number of double extensions can be useful during search (for example to resolve a tactical sequence), a sustained regime of double extensions leads to search explosion and a non-finishing search. See the discussion in https://github.com/official-stockfish/Stockfish/pull/3544 and the issue https://github.com/official-stockfish/Stockfish/issues/3532 . The implemented algorithm is the following: a) at each node during search, store the current depth in the stack. Double extensions are by definition levels of the stack where the depth at ply N is strictly higher than depth at ply N-1. b) during search, calculate for each thread a running average of the number of double extensions in the last 4096 visited nodes. c) if one thread has more than 2% of double extensions for a sustained period of time (6 millions consecutive nodes, or about 4 seconds on my iMac), we decide that this thread is in an explosion state and we calm down this thread by preventing it to do any double extension for the next 6 millions nodes. To calculate the running averages, we also introduced a auxiliary class generalizing the computations of ttHitAverage variable we already had in code. The implementation uses an exponential moving average of period 4096 and resolution 1/1024, and all computations are done with integers for efficiency. ----------- Example where the patch solves a search explosion: ``` ./stockfish ucinewgame position fen 8/Pk6/8/1p6/8/P1K5/8/6B1 w - - 37 130 go infinite ``` This algorithm does not affect search in normal, non-pathological positions. We verified, for instance, that the usual bench is unchanged up to depth 20 at least, and that the node numbers are unchanged for a search of the starting position at depth 32. ------------- See https://github.com/official-stockfish/Stockfish/pull/3714 Bench: 5575265
2021-09-23 15:19:06 -06:00
doubleExtensionAverage[WHITE].set(0, 100); // initialize the running average at 0%
doubleExtensionAverage[BLACK].set(0, 100); // initialize the running average at 0%
nodesLastExplosive = nodes;
nodesLastNormal = nodes;
state = EXPLOSION_NONE;
trend = SCORE_ZERO;
Introduce dynamic contempt Make contempt dependent on the current score of the root position. The idea is that we now use a linear formula like the following to decide on the contempt to use during a search : contempt = x + y * eval where x is the base contempt set by the user in the "Contempt" UCI option, and y * eval is the dynamic part which adapts itself to the estimation of the evaluation of the root position returned by the search. In this patch, we use x = 18 centipawns by default, and the y * eval correction can go from -20 centipawns if the root eval is less than -2.0 pawns, up to +20 centipawns when the root eval is more than 2.0 pawns. To summarize, the new contempt goes from -0.02 to 0.38 pawns, depending if Stockfish is losing or winning, with an average value of 0.18 pawns by default. STC: LLR: 2.95 (-2.94,2.94) [0.00,5.00] Total: 110052 W: 24614 L: 23938 D: 61500 http://tests.stockfishchess.org/tests/view/5a72e6020ebc590f2c86ea20 LTC: LLR: 2.97 (-2.94,2.94) [0.00,5.00] Total: 16470 W: 2896 L: 2705 D: 10869 http://tests.stockfishchess.org/tests/view/5a76c5b90ebc5902971a9830 A second match at LTC was organised against the current master: ELO: 1.45 +-2.9 (95%) LOS: 84.0% Total: 19369 W: 3350 L: 3269 D: 12750 http://tests.stockfishchess.org/tests/view/5a7acf980ebc5902971a9a2e Finally, we checked that there is no apparent problem with multithreading, despite the fact that some threads might have a slightly different contempt level that the main thread. Match of this version against master, both using 5 threads, time control 30+0.3: ELO: 2.18 +-3.2 (95%) LOS: 90.8% Total: 14840 W: 2502 L: 2409 D: 9929 http://tests.stockfishchess.org/tests/view/5a7bf3e80ebc5902971a9aa2 Include suggestions from Marco Costalba, Aram Tumanian, Ronald de Man, etc. Bench: 5207156
2018-02-09 10:43:53 -07:00
Smarter time management near stop limit This patch makes Stockfish search same depth again if > 60% of optimum time is already used, instead of trying the next iteration. The idea is that the next iteration will generally take about the same amount of time as has already been used in total. When we are likely to begin the last iteration, as judged by total time taken so far > 0.6 * optimum time, searching the last depth again instead of increasing the depth still helps the other threads in lazy SMP and prepares better move ordering for the next moves. STC : LLR: 2.95 (-2.94,2.94) {-1.00,3.00} Total: 13436 W: 2695 L: 2558 D: 8183 Ptnml(0-2): 222, 1538, 3087, 1611, 253 https://tests.stockfishchess.org/tests/view/5e1618a761fe5f83a67dd964 LTC : LLR: 2.94 (-2.94,2.94) {0.00,2.00} Total: 32160 W: 4261 L: 4047 D: 23852 Ptnml(0-2): 211, 2988, 9448, 3135, 247 https://tests.stockfishchess.org/tests/view/5e162ca061fe5f83a67dd96d The code was revised as suggested by @vondele for multithreading: STC (8 threads): LLR: 2.95 (-2.94,2.94) {0.00,2.00} Total: 16640 W: 2049 L: 1885 D: 12706 Ptnml(0-2): 119, 1369, 5158, 1557, 108 https://tests.stockfishchess.org/tests/view/5e19826a2cc590e03c3c2f52 LTC (8 threads): LLR: 2.95 (-2.94,2.94) {-1.00,3.00} Total: 16536 W: 2758 L: 2629 D: 11149 Ptnml(0-2): 182, 1758, 4296, 1802, 224 https://tests.stockfishchess.org/tests/view/5e18b91a27dab692fcf9a140 Thanks to those discussing Stockfish lazy SMP on fishcooking which made me try this, and to @vondele for suggestions and doing related tests. See full discussion in the pull request thread: https://github.com/official-stockfish/Stockfish/pull/2482 Bench: 4586187
2020-01-11 15:10:22 -07:00
int searchAgainCounter = 0;
// Iterative deepening loop until requested to stop or the target depth is reached
Eliminate ONE_PLY Simplification that eliminates ONE_PLY, based on a suggestion in the forum that support for fractional plies has never been used, and @mcostalba's openness to the idea of eliminating it. We lose a little bit of type safety by making Depth an integer, but in return we simplify the code in search.cpp quite significantly. No functional change ------------------------------------------ The argument favoring eliminating ONE_PLY: * The term “ONE_PLY” comes up in a lot of forum posts (474 to date) https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:relevance * There is occasionally a commit that breaks invariance of the code with respect to ONE_PLY https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:date/fishcooking/ZIPdYj6k0fk/KdNGcPWeBgAJ * To prevent such commits, there is a Travis CI hack that doubles ONE_PLY and rechecks bench * Sustaining ONE_PLY has, alas, not resulted in any improvements to the engine, despite many individuals testing many experiments over 5 years. The strongest argument in favor of preserving ONE_PLY comes from @locutus: “If we use par example ONE_PLY=256 the parameter space is increases by the factor 256. So it seems very unlikely that the optimal setting is in the subspace of ONE_PLY=1.” There is a strong theoretical impediment to fractional depth systems: the transposition table uses depth to determine when a stored result is good enough to supply an answer for a current search. If you have fractional depths, then different pathways to the position can be at fractionally different depths. In the end, there are three separate times when a proposal to remove ONE_PLY was defeated by the suggestion to “give it a few more months.” So… it seems like time to remove this distraction from the community. See the pull request here: https://github.com/official-stockfish/Stockfish/pull/2289
2019-09-28 14:27:23 -06:00
while ( ++rootDepth < MAX_PLY
&& !Threads.stop
Eliminate ONE_PLY Simplification that eliminates ONE_PLY, based on a suggestion in the forum that support for fractional plies has never been used, and @mcostalba's openness to the idea of eliminating it. We lose a little bit of type safety by making Depth an integer, but in return we simplify the code in search.cpp quite significantly. No functional change ------------------------------------------ The argument favoring eliminating ONE_PLY: * The term “ONE_PLY” comes up in a lot of forum posts (474 to date) https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:relevance * There is occasionally a commit that breaks invariance of the code with respect to ONE_PLY https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:date/fishcooking/ZIPdYj6k0fk/KdNGcPWeBgAJ * To prevent such commits, there is a Travis CI hack that doubles ONE_PLY and rechecks bench * Sustaining ONE_PLY has, alas, not resulted in any improvements to the engine, despite many individuals testing many experiments over 5 years. The strongest argument in favor of preserving ONE_PLY comes from @locutus: “If we use par example ONE_PLY=256 the parameter space is increases by the factor 256. So it seems very unlikely that the optimal setting is in the subspace of ONE_PLY=1.” There is a strong theoretical impediment to fractional depth systems: the transposition table uses depth to determine when a stored result is good enough to supply an answer for a current search. If you have fractional depths, then different pathways to the position can be at fractionally different depths. In the end, there are three separate times when a proposal to remove ONE_PLY was defeated by the suggestion to “give it a few more months.” So… it seems like time to remove this distraction from the community. See the pull request here: https://github.com/official-stockfish/Stockfish/pull/2289
2019-09-28 14:27:23 -06:00
&& !(Limits.depth && mainThread && rootDepth > Limits.depth))
{
// Age out PV variability metric
if (mainThread)
totBestMoveChanges /= 2;
// Save the last iteration's scores before first PV line is searched and
// all the move scores except the (new) PV are set to -VALUE_INFINITE.
for (RootMove& rm : rootMoves)
rm.previousScore = rm.score;
size_t pvFirst = 0;
pvLast = 0;
Tablebases root ranking This patch corrects both MultiPV behaviour and "go searchmoves" behaviour for tablebases. We change the logic of table base probing at root positions from filtering to ranking. The ranking code is much more straightforward than the current filtering code (this is a simplification), and also more versatile. If the root is a TB position, each root move is probed and assigned a TB score and a TB rank. The TB score is the Value to be displayed to the user for that move (unless the search finds a mate score), while the TB rank determines which moves should appear higher in a multi-pv search. In game play, the engine will always pick a move with the highest rank. Ranks run from -1000 to +1000: 901 to 1000 : TB win 900 : normally a TB win, in rare cases this could be a draw 1 to 899 : cursed TB wins 0 : draw -1 to -899 : blessed TB losses -900 : normally a TB loss, in rare cases this could be a draw -901 to -1000 : TB loss Normally all winning moves get rank 1000 (to let the search pick the best among them). The exception is if there has been a first repetition. In that case, moves are ranked strictly by DTZ so that the engine will play a move that lowers DTZ (and therefore cannot repeat the position a second time). Losing moves get rank -1000 unless they have relatively high DTZ, meaning they have some drawing chances. Those get ranks towards -901 (when they cross -900 the draw is certain). Closes https://github.com/official-stockfish/Stockfish/pull/1467 No functional change (without tablebases).
2018-04-18 10:38:38 -06:00
Smarter time management near stop limit This patch makes Stockfish search same depth again if > 60% of optimum time is already used, instead of trying the next iteration. The idea is that the next iteration will generally take about the same amount of time as has already been used in total. When we are likely to begin the last iteration, as judged by total time taken so far > 0.6 * optimum time, searching the last depth again instead of increasing the depth still helps the other threads in lazy SMP and prepares better move ordering for the next moves. STC : LLR: 2.95 (-2.94,2.94) {-1.00,3.00} Total: 13436 W: 2695 L: 2558 D: 8183 Ptnml(0-2): 222, 1538, 3087, 1611, 253 https://tests.stockfishchess.org/tests/view/5e1618a761fe5f83a67dd964 LTC : LLR: 2.94 (-2.94,2.94) {0.00,2.00} Total: 32160 W: 4261 L: 4047 D: 23852 Ptnml(0-2): 211, 2988, 9448, 3135, 247 https://tests.stockfishchess.org/tests/view/5e162ca061fe5f83a67dd96d The code was revised as suggested by @vondele for multithreading: STC (8 threads): LLR: 2.95 (-2.94,2.94) {0.00,2.00} Total: 16640 W: 2049 L: 1885 D: 12706 Ptnml(0-2): 119, 1369, 5158, 1557, 108 https://tests.stockfishchess.org/tests/view/5e19826a2cc590e03c3c2f52 LTC (8 threads): LLR: 2.95 (-2.94,2.94) {-1.00,3.00} Total: 16536 W: 2758 L: 2629 D: 11149 Ptnml(0-2): 182, 1758, 4296, 1802, 224 https://tests.stockfishchess.org/tests/view/5e18b91a27dab692fcf9a140 Thanks to those discussing Stockfish lazy SMP on fishcooking which made me try this, and to @vondele for suggestions and doing related tests. See full discussion in the pull request thread: https://github.com/official-stockfish/Stockfish/pull/2482 Bench: 4586187
2020-01-11 15:10:22 -07:00
if (!Threads.increaseDepth)
searchAgainCounter++;
// MultiPV loop. We perform a full root search for each PV line
for (pvIdx = 0; pvIdx < multiPV && !Threads.stop; ++pvIdx)
{
if (pvIdx == pvLast)
Tablebases root ranking This patch corrects both MultiPV behaviour and "go searchmoves" behaviour for tablebases. We change the logic of table base probing at root positions from filtering to ranking. The ranking code is much more straightforward than the current filtering code (this is a simplification), and also more versatile. If the root is a TB position, each root move is probed and assigned a TB score and a TB rank. The TB score is the Value to be displayed to the user for that move (unless the search finds a mate score), while the TB rank determines which moves should appear higher in a multi-pv search. In game play, the engine will always pick a move with the highest rank. Ranks run from -1000 to +1000: 901 to 1000 : TB win 900 : normally a TB win, in rare cases this could be a draw 1 to 899 : cursed TB wins 0 : draw -1 to -899 : blessed TB losses -900 : normally a TB loss, in rare cases this could be a draw -901 to -1000 : TB loss Normally all winning moves get rank 1000 (to let the search pick the best among them). The exception is if there has been a first repetition. In that case, moves are ranked strictly by DTZ so that the engine will play a move that lowers DTZ (and therefore cannot repeat the position a second time). Losing moves get rank -1000 unless they have relatively high DTZ, meaning they have some drawing chances. Those get ranks towards -901 (when they cross -900 the draw is certain). Closes https://github.com/official-stockfish/Stockfish/pull/1467 No functional change (without tablebases).
2018-04-18 10:38:38 -06:00
{
pvFirst = pvLast;
for (pvLast++; pvLast < rootMoves.size(); pvLast++)
if (rootMoves[pvLast].tbRank != rootMoves[pvFirst].tbRank)
Tablebases root ranking This patch corrects both MultiPV behaviour and "go searchmoves" behaviour for tablebases. We change the logic of table base probing at root positions from filtering to ranking. The ranking code is much more straightforward than the current filtering code (this is a simplification), and also more versatile. If the root is a TB position, each root move is probed and assigned a TB score and a TB rank. The TB score is the Value to be displayed to the user for that move (unless the search finds a mate score), while the TB rank determines which moves should appear higher in a multi-pv search. In game play, the engine will always pick a move with the highest rank. Ranks run from -1000 to +1000: 901 to 1000 : TB win 900 : normally a TB win, in rare cases this could be a draw 1 to 899 : cursed TB wins 0 : draw -1 to -899 : blessed TB losses -900 : normally a TB loss, in rare cases this could be a draw -901 to -1000 : TB loss Normally all winning moves get rank 1000 (to let the search pick the best among them). The exception is if there has been a first repetition. In that case, moves are ranked strictly by DTZ so that the engine will play a move that lowers DTZ (and therefore cannot repeat the position a second time). Losing moves get rank -1000 unless they have relatively high DTZ, meaning they have some drawing chances. Those get ranks towards -901 (when they cross -900 the draw is certain). Closes https://github.com/official-stockfish/Stockfish/pull/1467 No functional change (without tablebases).
2018-04-18 10:38:38 -06:00
break;
}
// Reset UCI info selDepth for each depth and each PV line
selDepth = 0;
// Reset aspiration window starting size
Eliminate ONE_PLY Simplification that eliminates ONE_PLY, based on a suggestion in the forum that support for fractional plies has never been used, and @mcostalba's openness to the idea of eliminating it. We lose a little bit of type safety by making Depth an integer, but in return we simplify the code in search.cpp quite significantly. No functional change ------------------------------------------ The argument favoring eliminating ONE_PLY: * The term “ONE_PLY” comes up in a lot of forum posts (474 to date) https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:relevance * There is occasionally a commit that breaks invariance of the code with respect to ONE_PLY https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:date/fishcooking/ZIPdYj6k0fk/KdNGcPWeBgAJ * To prevent such commits, there is a Travis CI hack that doubles ONE_PLY and rechecks bench * Sustaining ONE_PLY has, alas, not resulted in any improvements to the engine, despite many individuals testing many experiments over 5 years. The strongest argument in favor of preserving ONE_PLY comes from @locutus: “If we use par example ONE_PLY=256 the parameter space is increases by the factor 256. So it seems very unlikely that the optimal setting is in the subspace of ONE_PLY=1.” There is a strong theoretical impediment to fractional depth systems: the transposition table uses depth to determine when a stored result is good enough to supply an answer for a current search. If you have fractional depths, then different pathways to the position can be at fractionally different depths. In the end, there are three separate times when a proposal to remove ONE_PLY was defeated by the suggestion to “give it a few more months.” So… it seems like time to remove this distraction from the community. See the pull request here: https://github.com/official-stockfish/Stockfish/pull/2289
2019-09-28 14:27:23 -06:00
if (rootDepth >= 4)
{
Value prev = rootMoves[pvIdx].previousScore;
delta = Value(17) + int(prev) * prev / 16384;
alpha = std::max(prev - delta,-VALUE_INFINITE);
beta = std::min(prev + delta, VALUE_INFINITE);
Introduce dynamic contempt Make contempt dependent on the current score of the root position. The idea is that we now use a linear formula like the following to decide on the contempt to use during a search : contempt = x + y * eval where x is the base contempt set by the user in the "Contempt" UCI option, and y * eval is the dynamic part which adapts itself to the estimation of the evaluation of the root position returned by the search. In this patch, we use x = 18 centipawns by default, and the y * eval correction can go from -20 centipawns if the root eval is less than -2.0 pawns, up to +20 centipawns when the root eval is more than 2.0 pawns. To summarize, the new contempt goes from -0.02 to 0.38 pawns, depending if Stockfish is losing or winning, with an average value of 0.18 pawns by default. STC: LLR: 2.95 (-2.94,2.94) [0.00,5.00] Total: 110052 W: 24614 L: 23938 D: 61500 http://tests.stockfishchess.org/tests/view/5a72e6020ebc590f2c86ea20 LTC: LLR: 2.97 (-2.94,2.94) [0.00,5.00] Total: 16470 W: 2896 L: 2705 D: 10869 http://tests.stockfishchess.org/tests/view/5a76c5b90ebc5902971a9830 A second match at LTC was organised against the current master: ELO: 1.45 +-2.9 (95%) LOS: 84.0% Total: 19369 W: 3350 L: 3269 D: 12750 http://tests.stockfishchess.org/tests/view/5a7acf980ebc5902971a9a2e Finally, we checked that there is no apparent problem with multithreading, despite the fact that some threads might have a slightly different contempt level that the main thread. Match of this version against master, both using 5 threads, time control 30+0.3: ELO: 2.18 +-3.2 (95%) LOS: 90.8% Total: 14840 W: 2502 L: 2409 D: 9929 http://tests.stockfishchess.org/tests/view/5a7bf3e80ebc5902971a9aa2 Include suggestions from Marco Costalba, Aram Tumanian, Ronald de Man, etc. Bench: 5207156
2018-02-09 10:43:53 -07:00
// Adjust trend based on root move's previousScore (dynamic contempt)
int tr = 113 * prev / (abs(prev) + 147);
Introduce dynamic contempt Make contempt dependent on the current score of the root position. The idea is that we now use a linear formula like the following to decide on the contempt to use during a search : contempt = x + y * eval where x is the base contempt set by the user in the "Contempt" UCI option, and y * eval is the dynamic part which adapts itself to the estimation of the evaluation of the root position returned by the search. In this patch, we use x = 18 centipawns by default, and the y * eval correction can go from -20 centipawns if the root eval is less than -2.0 pawns, up to +20 centipawns when the root eval is more than 2.0 pawns. To summarize, the new contempt goes from -0.02 to 0.38 pawns, depending if Stockfish is losing or winning, with an average value of 0.18 pawns by default. STC: LLR: 2.95 (-2.94,2.94) [0.00,5.00] Total: 110052 W: 24614 L: 23938 D: 61500 http://tests.stockfishchess.org/tests/view/5a72e6020ebc590f2c86ea20 LTC: LLR: 2.97 (-2.94,2.94) [0.00,5.00] Total: 16470 W: 2896 L: 2705 D: 10869 http://tests.stockfishchess.org/tests/view/5a76c5b90ebc5902971a9830 A second match at LTC was organised against the current master: ELO: 1.45 +-2.9 (95%) LOS: 84.0% Total: 19369 W: 3350 L: 3269 D: 12750 http://tests.stockfishchess.org/tests/view/5a7acf980ebc5902971a9a2e Finally, we checked that there is no apparent problem with multithreading, despite the fact that some threads might have a slightly different contempt level that the main thread. Match of this version against master, both using 5 threads, time control 30+0.3: ELO: 2.18 +-3.2 (95%) LOS: 90.8% Total: 14840 W: 2502 L: 2409 D: 9929 http://tests.stockfishchess.org/tests/view/5a7bf3e80ebc5902971a9aa2 Include suggestions from Marco Costalba, Aram Tumanian, Ronald de Man, etc. Bench: 5207156
2018-02-09 10:43:53 -07:00
trend = (us == WHITE ? make_score(tr, tr / 2)
: -make_score(tr, tr / 2));
}
// Start with a small aspiration window and, in the case of a fail
// high/low, re-search with a bigger window until we don't fail
// high/low anymore.
int failedHighCnt = 0;
while (true)
{
Smarter time management near stop limit This patch makes Stockfish search same depth again if > 60% of optimum time is already used, instead of trying the next iteration. The idea is that the next iteration will generally take about the same amount of time as has already been used in total. When we are likely to begin the last iteration, as judged by total time taken so far > 0.6 * optimum time, searching the last depth again instead of increasing the depth still helps the other threads in lazy SMP and prepares better move ordering for the next moves. STC : LLR: 2.95 (-2.94,2.94) {-1.00,3.00} Total: 13436 W: 2695 L: 2558 D: 8183 Ptnml(0-2): 222, 1538, 3087, 1611, 253 https://tests.stockfishchess.org/tests/view/5e1618a761fe5f83a67dd964 LTC : LLR: 2.94 (-2.94,2.94) {0.00,2.00} Total: 32160 W: 4261 L: 4047 D: 23852 Ptnml(0-2): 211, 2988, 9448, 3135, 247 https://tests.stockfishchess.org/tests/view/5e162ca061fe5f83a67dd96d The code was revised as suggested by @vondele for multithreading: STC (8 threads): LLR: 2.95 (-2.94,2.94) {0.00,2.00} Total: 16640 W: 2049 L: 1885 D: 12706 Ptnml(0-2): 119, 1369, 5158, 1557, 108 https://tests.stockfishchess.org/tests/view/5e19826a2cc590e03c3c2f52 LTC (8 threads): LLR: 2.95 (-2.94,2.94) {-1.00,3.00} Total: 16536 W: 2758 L: 2629 D: 11149 Ptnml(0-2): 182, 1758, 4296, 1802, 224 https://tests.stockfishchess.org/tests/view/5e18b91a27dab692fcf9a140 Thanks to those discussing Stockfish lazy SMP on fishcooking which made me try this, and to @vondele for suggestions and doing related tests. See full discussion in the pull request thread: https://github.com/official-stockfish/Stockfish/pull/2482 Bench: 4586187
2020-01-11 15:10:22 -07:00
Depth adjustedDepth = std::max(1, rootDepth - failedHighCnt - searchAgainCounter);
bestValue = Stockfish::search<Root>(rootPos, ss, alpha, beta, adjustedDepth, false);
// Bring the best move to the front. It is critical that sorting
// is done with a stable algorithm because all the values but the
// first and eventually the new best one are set to -VALUE_INFINITE
// and we want to keep the same order for all the moves except the
// new PV that goes to the front. Note that in case of MultiPV
// search the already searched PV lines are preserved.
std::stable_sort(rootMoves.begin() + pvIdx, rootMoves.begin() + pvLast);
// If search has been stopped, we break immediately. Sorting is
// safe because RootMoves is still valid, although it refers to
// the previous iteration.
if (Threads.stop)
break;
// When failing high/low give some update (without cluttering
// the UI) before a re-search.
if ( mainThread
&& multiPV == 1
&& (bestValue <= alpha || bestValue >= beta)
&& Time.elapsed() > 3000)
Fix issues from using adjustedDepth too broadly The recently committed Fail-High patch (081af9080542a0d076a5482da37103a96ee15f64) had a number of changes beyond adjusting the depth of search on fail high, with some undesirable side effects. 1) Decreasing depth on PV output, confusing GUIs and players alike as described in issue #1787. The depth printed is anyway a convention, let's consider adjustedDepth an implementation detail, and continue to print rootDepth. Depth, nodes, time and move quality all increase as we compute more. (fixing this output has no effect on play). 2) Fixes go depth output (now based on rootDepth again, no effect on play), also reported in issue #1787 3) The depth lastBestDepth is used to compute how long a move is stable, a new move found during fail-high is incorrectly considered stable if based on adjustedDepth instead of rootDepth (this changes time management). Reverting this passed STC and LTC: STC LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 82982 W: 17810 L: 17808 D: 47364 http://tests.stockfishchess.org/tests/view/5bd391a80ebc595e0ae1e993 LTC LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 109083 W: 17602 L: 17619 D: 73862 http://tests.stockfishchess.org/tests/view/5bd40c820ebc595e0ae1f1fb 4) In the thread voting scheme, the rank of the fail-high thread is now artificially low, incorrectly since the quality of the move is much better than what adjustedDepth suggests (e.g. if it takes 10 iterations to find VALUE_KNOWN_WIN, it has very low depth). Further evidence comes from a test that showed that the move of highest depth is not better than that of the last PV (which is potentially of much lower adjustedDepth). I.e. this test http://tests.stockfishchess.org/tests/view/5bd37a120ebc595e0ae1e7c3 failed SPRT[0, 5]: LLR: -2.95 (-2.94,2.94) [0.00,5.00] Total: 10609 W: 2266 L: 2345 D: 5998 In a running 5+0.05 th 8 test (more than 10000 games) a positive Elo estimate is shown (strong enough for a [-3,1], possibly not [0,4]): http://tests.stockfishchess.org/tests/view/5bd421be0ebc595e0ae1f315 LLR: -0.13 (-2.94,2.94) [0.00,4.00] Total: 13644 W: 2573 L: 2532 D: 8539 Elo 1.04 [-2.52,4.61] / LOS 71% Thus, restore old behavior as a bugfix, keeping the core of the fail-high patch idea as resolving scheme. This is non-functional for bench, but changes searches via time management and in the threaded case. Bench: 3556672
2018-10-28 08:25:15 -06:00
sync_cout << UCI::pv(rootPos, rootDepth, alpha, beta) << sync_endl;
// In case of failing low/high increase aspiration window and
// re-search, otherwise exit the loop.
if (bestValue <= alpha)
{
beta = (alpha + beta) / 2;
alpha = std::max(bestValue - delta, -VALUE_INFINITE);
failedHighCnt = 0;
if (mainThread)
mainThread->stopOnPonderhit = false;
}
else if (bestValue >= beta)
{
beta = std::min(bestValue + delta, VALUE_INFINITE);
++failedHighCnt;
}
else
break;
delta += delta / 4 + 5;
assert(alpha >= -VALUE_INFINITE && beta <= VALUE_INFINITE);
}
// Sort the PV lines searched so far and update the GUI
std::stable_sort(rootMoves.begin() + pvFirst, rootMoves.begin() + pvIdx + 1);
if ( mainThread
&& (Threads.stop || pvIdx + 1 == multiPV || Time.elapsed() > 3000))
Fix issues from using adjustedDepth too broadly The recently committed Fail-High patch (081af9080542a0d076a5482da37103a96ee15f64) had a number of changes beyond adjusting the depth of search on fail high, with some undesirable side effects. 1) Decreasing depth on PV output, confusing GUIs and players alike as described in issue #1787. The depth printed is anyway a convention, let's consider adjustedDepth an implementation detail, and continue to print rootDepth. Depth, nodes, time and move quality all increase as we compute more. (fixing this output has no effect on play). 2) Fixes go depth output (now based on rootDepth again, no effect on play), also reported in issue #1787 3) The depth lastBestDepth is used to compute how long a move is stable, a new move found during fail-high is incorrectly considered stable if based on adjustedDepth instead of rootDepth (this changes time management). Reverting this passed STC and LTC: STC LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 82982 W: 17810 L: 17808 D: 47364 http://tests.stockfishchess.org/tests/view/5bd391a80ebc595e0ae1e993 LTC LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 109083 W: 17602 L: 17619 D: 73862 http://tests.stockfishchess.org/tests/view/5bd40c820ebc595e0ae1f1fb 4) In the thread voting scheme, the rank of the fail-high thread is now artificially low, incorrectly since the quality of the move is much better than what adjustedDepth suggests (e.g. if it takes 10 iterations to find VALUE_KNOWN_WIN, it has very low depth). Further evidence comes from a test that showed that the move of highest depth is not better than that of the last PV (which is potentially of much lower adjustedDepth). I.e. this test http://tests.stockfishchess.org/tests/view/5bd37a120ebc595e0ae1e7c3 failed SPRT[0, 5]: LLR: -2.95 (-2.94,2.94) [0.00,5.00] Total: 10609 W: 2266 L: 2345 D: 5998 In a running 5+0.05 th 8 test (more than 10000 games) a positive Elo estimate is shown (strong enough for a [-3,1], possibly not [0,4]): http://tests.stockfishchess.org/tests/view/5bd421be0ebc595e0ae1f315 LLR: -0.13 (-2.94,2.94) [0.00,4.00] Total: 13644 W: 2573 L: 2532 D: 8539 Elo 1.04 [-2.52,4.61] / LOS 71% Thus, restore old behavior as a bugfix, keeping the core of the fail-high patch idea as resolving scheme. This is non-functional for bench, but changes searches via time management and in the threaded case. Bench: 3556672
2018-10-28 08:25:15 -06:00
sync_cout << UCI::pv(rootPos, rootDepth, alpha, beta) << sync_endl;
}
if (!Threads.stop)
Fix issues from using adjustedDepth too broadly The recently committed Fail-High patch (081af9080542a0d076a5482da37103a96ee15f64) had a number of changes beyond adjusting the depth of search on fail high, with some undesirable side effects. 1) Decreasing depth on PV output, confusing GUIs and players alike as described in issue #1787. The depth printed is anyway a convention, let's consider adjustedDepth an implementation detail, and continue to print rootDepth. Depth, nodes, time and move quality all increase as we compute more. (fixing this output has no effect on play). 2) Fixes go depth output (now based on rootDepth again, no effect on play), also reported in issue #1787 3) The depth lastBestDepth is used to compute how long a move is stable, a new move found during fail-high is incorrectly considered stable if based on adjustedDepth instead of rootDepth (this changes time management). Reverting this passed STC and LTC: STC LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 82982 W: 17810 L: 17808 D: 47364 http://tests.stockfishchess.org/tests/view/5bd391a80ebc595e0ae1e993 LTC LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 109083 W: 17602 L: 17619 D: 73862 http://tests.stockfishchess.org/tests/view/5bd40c820ebc595e0ae1f1fb 4) In the thread voting scheme, the rank of the fail-high thread is now artificially low, incorrectly since the quality of the move is much better than what adjustedDepth suggests (e.g. if it takes 10 iterations to find VALUE_KNOWN_WIN, it has very low depth). Further evidence comes from a test that showed that the move of highest depth is not better than that of the last PV (which is potentially of much lower adjustedDepth). I.e. this test http://tests.stockfishchess.org/tests/view/5bd37a120ebc595e0ae1e7c3 failed SPRT[0, 5]: LLR: -2.95 (-2.94,2.94) [0.00,5.00] Total: 10609 W: 2266 L: 2345 D: 5998 In a running 5+0.05 th 8 test (more than 10000 games) a positive Elo estimate is shown (strong enough for a [-3,1], possibly not [0,4]): http://tests.stockfishchess.org/tests/view/5bd421be0ebc595e0ae1f315 LLR: -0.13 (-2.94,2.94) [0.00,4.00] Total: 13644 W: 2573 L: 2532 D: 8539 Elo 1.04 [-2.52,4.61] / LOS 71% Thus, restore old behavior as a bugfix, keeping the core of the fail-high patch idea as resolving scheme. This is non-functional for bench, but changes searches via time management and in the threaded case. Bench: 3556672
2018-10-28 08:25:15 -06:00
completedDepth = rootDepth;
if (rootMoves[0].pv[0] != lastBestMove) {
lastBestMove = rootMoves[0].pv[0];
Fix issues from using adjustedDepth too broadly The recently committed Fail-High patch (081af9080542a0d076a5482da37103a96ee15f64) had a number of changes beyond adjusting the depth of search on fail high, with some undesirable side effects. 1) Decreasing depth on PV output, confusing GUIs and players alike as described in issue #1787. The depth printed is anyway a convention, let's consider adjustedDepth an implementation detail, and continue to print rootDepth. Depth, nodes, time and move quality all increase as we compute more. (fixing this output has no effect on play). 2) Fixes go depth output (now based on rootDepth again, no effect on play), also reported in issue #1787 3) The depth lastBestDepth is used to compute how long a move is stable, a new move found during fail-high is incorrectly considered stable if based on adjustedDepth instead of rootDepth (this changes time management). Reverting this passed STC and LTC: STC LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 82982 W: 17810 L: 17808 D: 47364 http://tests.stockfishchess.org/tests/view/5bd391a80ebc595e0ae1e993 LTC LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 109083 W: 17602 L: 17619 D: 73862 http://tests.stockfishchess.org/tests/view/5bd40c820ebc595e0ae1f1fb 4) In the thread voting scheme, the rank of the fail-high thread is now artificially low, incorrectly since the quality of the move is much better than what adjustedDepth suggests (e.g. if it takes 10 iterations to find VALUE_KNOWN_WIN, it has very low depth). Further evidence comes from a test that showed that the move of highest depth is not better than that of the last PV (which is potentially of much lower adjustedDepth). I.e. this test http://tests.stockfishchess.org/tests/view/5bd37a120ebc595e0ae1e7c3 failed SPRT[0, 5]: LLR: -2.95 (-2.94,2.94) [0.00,5.00] Total: 10609 W: 2266 L: 2345 D: 5998 In a running 5+0.05 th 8 test (more than 10000 games) a positive Elo estimate is shown (strong enough for a [-3,1], possibly not [0,4]): http://tests.stockfishchess.org/tests/view/5bd421be0ebc595e0ae1f315 LLR: -0.13 (-2.94,2.94) [0.00,4.00] Total: 13644 W: 2573 L: 2532 D: 8539 Elo 1.04 [-2.52,4.61] / LOS 71% Thus, restore old behavior as a bugfix, keeping the core of the fail-high patch idea as resolving scheme. This is non-functional for bench, but changes searches via time management and in the threaded case. Bench: 3556672
2018-10-28 08:25:15 -06:00
lastBestMoveDepth = rootDepth;
}
// Have we found a "mate in x"?
if ( Limits.mate
&& bestValue >= VALUE_MATE_IN_MAX_PLY
&& VALUE_MATE - bestValue <= 2 * Limits.mate)
Threads.stop = true;
if (!mainThread)
continue;
// If skill level is enabled and time is up, pick a sub-optimal best move
if (skill.enabled() && skill.time_to_pick(rootDepth))
skill.pick_best(multiPV);
// Do we have time for the next iteration? Can we stop searching now?
if ( Limits.use_time_management()
&& !Threads.stop
&& !mainThread->stopOnPonderhit)
{
double fallingEval = (318 + 6 * (mainThread->bestPreviousScore - bestValue)
+ 6 * (mainThread->iterValue[iterIdx] - bestValue)) / 825.0;
fallingEval = std::clamp(fallingEval, 0.5, 1.5);
// If the bestMove is stable over several iterations, reduce time accordingly
timeReduction = lastBestMoveDepth + 9 < completedDepth ? 1.92 : 0.95;
double reduction = (1.47 + mainThread->previousTimeReduction) / (2.32 * timeReduction);
// Use part of the gained time from a previous stable move for the current move
for (Thread* th : Threads)
{
totBestMoveChanges += th->bestMoveChanges;
th->bestMoveChanges = 0;
}
double bestMoveInstability = 1.073 + std::max(1.0, 2.25 - 9.9 / rootDepth)
* totBestMoveChanges / Threads.size();
double totalTime = Time.optimum() * fallingEval * reduction * bestMoveInstability;
// Cap used time in case of a single legal move for a better viewer experience in tournaments
// yielding correct scores and sufficiently fast moves.
if (rootMoves.size() == 1)
totalTime = std::min(500.0, totalTime);
// Stop the search if we have exceeded the totalTime
if (Time.elapsed() > totalTime)
{
// If we are allowed to ponder do not stop the search now but
// keep pondering until the GUI sends "ponderhit" or "stop".
if (mainThread->ponder)
mainThread->stopOnPonderhit = true;
else
Threads.stop = true;
}
Smarter time management near stop limit This patch makes Stockfish search same depth again if > 60% of optimum time is already used, instead of trying the next iteration. The idea is that the next iteration will generally take about the same amount of time as has already been used in total. When we are likely to begin the last iteration, as judged by total time taken so far > 0.6 * optimum time, searching the last depth again instead of increasing the depth still helps the other threads in lazy SMP and prepares better move ordering for the next moves. STC : LLR: 2.95 (-2.94,2.94) {-1.00,3.00} Total: 13436 W: 2695 L: 2558 D: 8183 Ptnml(0-2): 222, 1538, 3087, 1611, 253 https://tests.stockfishchess.org/tests/view/5e1618a761fe5f83a67dd964 LTC : LLR: 2.94 (-2.94,2.94) {0.00,2.00} Total: 32160 W: 4261 L: 4047 D: 23852 Ptnml(0-2): 211, 2988, 9448, 3135, 247 https://tests.stockfishchess.org/tests/view/5e162ca061fe5f83a67dd96d The code was revised as suggested by @vondele for multithreading: STC (8 threads): LLR: 2.95 (-2.94,2.94) {0.00,2.00} Total: 16640 W: 2049 L: 1885 D: 12706 Ptnml(0-2): 119, 1369, 5158, 1557, 108 https://tests.stockfishchess.org/tests/view/5e19826a2cc590e03c3c2f52 LTC (8 threads): LLR: 2.95 (-2.94,2.94) {-1.00,3.00} Total: 16536 W: 2758 L: 2629 D: 11149 Ptnml(0-2): 182, 1758, 4296, 1802, 224 https://tests.stockfishchess.org/tests/view/5e18b91a27dab692fcf9a140 Thanks to those discussing Stockfish lazy SMP on fishcooking which made me try this, and to @vondele for suggestions and doing related tests. See full discussion in the pull request thread: https://github.com/official-stockfish/Stockfish/pull/2482 Bench: 4586187
2020-01-11 15:10:22 -07:00
else if ( Threads.increaseDepth
&& !mainThread->ponder
&& Time.elapsed() > totalTime * 0.58)
Smarter time management near stop limit This patch makes Stockfish search same depth again if > 60% of optimum time is already used, instead of trying the next iteration. The idea is that the next iteration will generally take about the same amount of time as has already been used in total. When we are likely to begin the last iteration, as judged by total time taken so far > 0.6 * optimum time, searching the last depth again instead of increasing the depth still helps the other threads in lazy SMP and prepares better move ordering for the next moves. STC : LLR: 2.95 (-2.94,2.94) {-1.00,3.00} Total: 13436 W: 2695 L: 2558 D: 8183 Ptnml(0-2): 222, 1538, 3087, 1611, 253 https://tests.stockfishchess.org/tests/view/5e1618a761fe5f83a67dd964 LTC : LLR: 2.94 (-2.94,2.94) {0.00,2.00} Total: 32160 W: 4261 L: 4047 D: 23852 Ptnml(0-2): 211, 2988, 9448, 3135, 247 https://tests.stockfishchess.org/tests/view/5e162ca061fe5f83a67dd96d The code was revised as suggested by @vondele for multithreading: STC (8 threads): LLR: 2.95 (-2.94,2.94) {0.00,2.00} Total: 16640 W: 2049 L: 1885 D: 12706 Ptnml(0-2): 119, 1369, 5158, 1557, 108 https://tests.stockfishchess.org/tests/view/5e19826a2cc590e03c3c2f52 LTC (8 threads): LLR: 2.95 (-2.94,2.94) {-1.00,3.00} Total: 16536 W: 2758 L: 2629 D: 11149 Ptnml(0-2): 182, 1758, 4296, 1802, 224 https://tests.stockfishchess.org/tests/view/5e18b91a27dab692fcf9a140 Thanks to those discussing Stockfish lazy SMP on fishcooking which made me try this, and to @vondele for suggestions and doing related tests. See full discussion in the pull request thread: https://github.com/official-stockfish/Stockfish/pull/2482 Bench: 4586187
2020-01-11 15:10:22 -07:00
Threads.increaseDepth = false;
else
Threads.increaseDepth = true;
}
mainThread->iterValue[iterIdx] = bestValue;
iterIdx = (iterIdx + 1) & 3;
2008-08-31 23:59:13 -06:00
}
if (!mainThread)
return;
mainThread->previousTimeReduction = timeReduction;
// If skill level is enabled, swap best PV line with the sub-optimal one
if (skill.enabled())
std::swap(rootMoves[0], *std::find(rootMoves.begin(), rootMoves.end(),
skill.best ? skill.best : skill.pick_best(multiPV)));
}
namespace {
2008-08-31 23:59:13 -06:00
// search<>() is the main search function for both PV and non-PV nodes
2008-08-31 23:59:13 -06:00
template <NodeType nodeType>
Value search(Position& pos, Stack* ss, Value alpha, Value beta, Depth depth, bool cutNode) {
Detect search explosions This patch detects some search explosions (due to double extensions in search.cpp) which can happen in some pathological positions, and takes measures to ensure progress in search even for these pathological situations. While a small number of double extensions can be useful during search (for example to resolve a tactical sequence), a sustained regime of double extensions leads to search explosion and a non-finishing search. See the discussion in https://github.com/official-stockfish/Stockfish/pull/3544 and the issue https://github.com/official-stockfish/Stockfish/issues/3532 . The implemented algorithm is the following: a) at each node during search, store the current depth in the stack. Double extensions are by definition levels of the stack where the depth at ply N is strictly higher than depth at ply N-1. b) during search, calculate for each thread a running average of the number of double extensions in the last 4096 visited nodes. c) if one thread has more than 2% of double extensions for a sustained period of time (6 millions consecutive nodes, or about 4 seconds on my iMac), we decide that this thread is in an explosion state and we calm down this thread by preventing it to do any double extension for the next 6 millions nodes. To calculate the running averages, we also introduced a auxiliary class generalizing the computations of ttHitAverage variable we already had in code. The implementation uses an exponential moving average of period 4096 and resolution 1/1024, and all computations are done with integers for efficiency. ----------- Example where the patch solves a search explosion: ``` ./stockfish ucinewgame position fen 8/Pk6/8/1p6/8/P1K5/8/6B1 w - - 37 130 go infinite ``` This algorithm does not affect search in normal, non-pathological positions. We verified, for instance, that the usual bench is unchanged up to depth 20 at least, and that the node numbers are unchanged for a search of the starting position at depth 32. ------------- See https://github.com/official-stockfish/Stockfish/pull/3714 Bench: 5575265
2021-09-23 15:19:06 -06:00
Thread* thisThread = pos.this_thread();
// Step 0. Limit search explosion
if ( ss->ply > 10
&& search_explosion(thisThread) == MUST_CALM_DOWN
&& depth > (ss-1)->depth)
depth = (ss-1)->depth;
constexpr bool PvNode = nodeType != NonPV;
constexpr bool rootNode = nodeType == Root;
const Depth maxNextDepth = rootNode ? depth : depth + 1;
// Check if we have an upcoming move which draws by repetition, or
// if the opponent had an alternative move earlier to this position.
if ( !rootNode
&& pos.rule50_count() >= 3
&& alpha < VALUE_DRAW
&& pos.has_game_cycle(ss->ply))
{
alpha = value_draw(pos.this_thread());
if (alpha >= beta)
return alpha;
}
// Dive into quiescence search when the depth reaches zero
Eliminate ONE_PLY Simplification that eliminates ONE_PLY, based on a suggestion in the forum that support for fractional plies has never been used, and @mcostalba's openness to the idea of eliminating it. We lose a little bit of type safety by making Depth an integer, but in return we simplify the code in search.cpp quite significantly. No functional change ------------------------------------------ The argument favoring eliminating ONE_PLY: * The term “ONE_PLY” comes up in a lot of forum posts (474 to date) https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:relevance * There is occasionally a commit that breaks invariance of the code with respect to ONE_PLY https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:date/fishcooking/ZIPdYj6k0fk/KdNGcPWeBgAJ * To prevent such commits, there is a Travis CI hack that doubles ONE_PLY and rechecks bench * Sustaining ONE_PLY has, alas, not resulted in any improvements to the engine, despite many individuals testing many experiments over 5 years. The strongest argument in favor of preserving ONE_PLY comes from @locutus: “If we use par example ONE_PLY=256 the parameter space is increases by the factor 256. So it seems very unlikely that the optimal setting is in the subspace of ONE_PLY=1.” There is a strong theoretical impediment to fractional depth systems: the transposition table uses depth to determine when a stored result is good enough to supply an answer for a current search. If you have fractional depths, then different pathways to the position can be at fractionally different depths. In the end, there are three separate times when a proposal to remove ONE_PLY was defeated by the suggestion to “give it a few more months.” So… it seems like time to remove this distraction from the community. See the pull request here: https://github.com/official-stockfish/Stockfish/pull/2289
2019-09-28 14:27:23 -06:00
if (depth <= 0)
return qsearch<PvNode ? PV : NonPV>(pos, ss, alpha, beta);
assert(-VALUE_INFINITE <= alpha && alpha < beta && beta <= VALUE_INFINITE);
assert(PvNode || (alpha == beta - 1));
Eliminate ONE_PLY Simplification that eliminates ONE_PLY, based on a suggestion in the forum that support for fractional plies has never been used, and @mcostalba's openness to the idea of eliminating it. We lose a little bit of type safety by making Depth an integer, but in return we simplify the code in search.cpp quite significantly. No functional change ------------------------------------------ The argument favoring eliminating ONE_PLY: * The term “ONE_PLY” comes up in a lot of forum posts (474 to date) https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:relevance * There is occasionally a commit that breaks invariance of the code with respect to ONE_PLY https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:date/fishcooking/ZIPdYj6k0fk/KdNGcPWeBgAJ * To prevent such commits, there is a Travis CI hack that doubles ONE_PLY and rechecks bench * Sustaining ONE_PLY has, alas, not resulted in any improvements to the engine, despite many individuals testing many experiments over 5 years. The strongest argument in favor of preserving ONE_PLY comes from @locutus: “If we use par example ONE_PLY=256 the parameter space is increases by the factor 256. So it seems very unlikely that the optimal setting is in the subspace of ONE_PLY=1.” There is a strong theoretical impediment to fractional depth systems: the transposition table uses depth to determine when a stored result is good enough to supply an answer for a current search. If you have fractional depths, then different pathways to the position can be at fractionally different depths. In the end, there are three separate times when a proposal to remove ONE_PLY was defeated by the suggestion to “give it a few more months.” So… it seems like time to remove this distraction from the community. See the pull request here: https://github.com/official-stockfish/Stockfish/pull/2289
2019-09-28 14:27:23 -06:00
assert(0 < depth && depth < MAX_PLY);
assert(!(PvNode && cutNode));
2008-08-31 23:59:13 -06:00
Move pv[MAX_PLY+1], capturesSearched[32], quietsSearched[64];
StateInfo st;
ASSERT_ALIGNED(&st, Eval::NNUE::CacheLineSize);
TTEntry* tte;
Key posKey;
Move ttMove, move, excludedMove, bestMove;
Depth extension, newDepth;
Value bestValue, value, ttValue, eval, maxValue, probCutBeta;
bool givesCheck, improving, didLMR, priorCapture;
bool captureOrPromotion, doFullDepthSearch, moveCountPruning,
ttCapture, singularQuietLMR;
Piece movedPiece;
int moveCount, captureCount, quietCount, bestMoveCount, improvement;
// Step 1. Initialize node
ss->inCheck = pos.checkers();
priorCapture = pos.captured_piece();
Color us = pos.side_to_move();
moveCount = bestMoveCount = captureCount = quietCount = ss->moveCount = 0;
bestValue = -VALUE_INFINITE;
maxValue = VALUE_INFINITE;
// Check for the available remaining time
if (thisThread == Threads.main())
static_cast<MainThread*>(thisThread)->check_time();
Let ss->ply denote the number of plies from the root to the current node This patch lets ss->ply be equal to 0 at the root of the search. Currently, the root has ss->ply == 1, which is less intuitive: - Setting the rootNode bool has to check (ss-1)->ply == 0. - All mate values are off by one: the code seems to assume that mated-in-0 is -VALUE_MATE, mate-1-in-ply is VALUE_MATE-1, mated-in-2-ply is VALUE_MATE+2, etc. But the mate_in() and mated_in() functions are called with ss->ply, which is 1 in at the root. - The is_draw() function currently needs to explain why it has "ply - 1 > i" instead of simply "ply > i". - The ss->ply >= MAX_PLY tests in search() and qsearch() already assume that ss->ply == 0 at the root. If we start at ss->ply == 1, it would make more sense to go up to and including ss->ply == MAX_PLY, so stop at ss->ply > MAX_PLY. See also the asserts testing for 0 <= ss->ply && ss->ply < MAX_PLY. The reason for ss->ply == 1 at the root is the line "ss->ply = (ss-1)->ply + 1" at the start for search() and qsearch(). By replacing this with "(ss+1)->ply = ss->ply + 1" we keep ss->ply == 0 at the root. Note that search() already clears killers in (ss+2), so there is no danger in accessing ss+1. I have NOT changed pv[MAX_PLY + 1] to pv[MAX_PLY + 2] in search() and qsearch(). It seems to me that MAX_PLY + 1 is exactly right: - MAX_PLY entries for ss->ply running from 0 to MAX_PLY-1, and 1 entry for the final MOVE_NONE. I have verified that mate scores are reported correctly. (They were already reported correctly due to the extra ply being rounded down when converting to moves.) The value of seldepth output to the user should probably not change, so I add 1 to it. (Humans count from 1, computers from 0.) A small optimisation I did not include: instead of setting ss->ply in every invocation of search() and qsearch(), it could be set once for all plies at the start of Thread::search(). This saves a couple of instructions per node. No functional change (unless the search searches a branch MAX_PLY deep), so bench does not change.
2017-09-16 13:49:29 -06:00
// Used to send selDepth info to GUI (selDepth counts from 1, ply from 0)
if (PvNode && thisThread->selDepth < ss->ply + 1)
thisThread->selDepth = ss->ply + 1;
if (!rootNode)
{
// Step 2. Check for aborted search and immediate draw
if ( Threads.stop.load(std::memory_order_relaxed)
|| pos.is_draw(ss->ply)
|| ss->ply >= MAX_PLY)
return (ss->ply >= MAX_PLY && !ss->inCheck) ? evaluate(pos)
: value_draw(pos.this_thread());
// Step 3. Mate distance pruning. Even if we mate at the next move our score
// would be at best mate_in(ss->ply+1), but if alpha is already bigger because
// a shorter mate was found upward in the tree then there is no need to search
// because we will never beat the current alpha. Same logic but with reversed
// signs applies also in the opposite condition of being mated instead of giving
// mate. In this case return a fail-high score.
alpha = std::max(mated_in(ss->ply), alpha);
beta = std::min(mate_in(ss->ply+1), beta);
if (alpha >= beta)
return alpha;
}
assert(0 <= ss->ply && ss->ply < MAX_PLY);
(ss+1)->ttPv = false;
(ss+1)->excludedMove = bestMove = MOVE_NONE;
(ss+2)->killers[0] = (ss+2)->killers[1] = MOVE_NONE;
ss->doubleExtensions = (ss-1)->doubleExtensions;
Detect search explosions This patch detects some search explosions (due to double extensions in search.cpp) which can happen in some pathological positions, and takes measures to ensure progress in search even for these pathological situations. While a small number of double extensions can be useful during search (for example to resolve a tactical sequence), a sustained regime of double extensions leads to search explosion and a non-finishing search. See the discussion in https://github.com/official-stockfish/Stockfish/pull/3544 and the issue https://github.com/official-stockfish/Stockfish/issues/3532 . The implemented algorithm is the following: a) at each node during search, store the current depth in the stack. Double extensions are by definition levels of the stack where the depth at ply N is strictly higher than depth at ply N-1. b) during search, calculate for each thread a running average of the number of double extensions in the last 4096 visited nodes. c) if one thread has more than 2% of double extensions for a sustained period of time (6 millions consecutive nodes, or about 4 seconds on my iMac), we decide that this thread is in an explosion state and we calm down this thread by preventing it to do any double extension for the next 6 millions nodes. To calculate the running averages, we also introduced a auxiliary class generalizing the computations of ttHitAverage variable we already had in code. The implementation uses an exponential moving average of period 4096 and resolution 1/1024, and all computations are done with integers for efficiency. ----------- Example where the patch solves a search explosion: ``` ./stockfish ucinewgame position fen 8/Pk6/8/1p6/8/P1K5/8/6B1 w - - 37 130 go infinite ``` This algorithm does not affect search in normal, non-pathological positions. We verified, for instance, that the usual bench is unchanged up to depth 20 at least, and that the node numbers are unchanged for a search of the starting position at depth 32. ------------- See https://github.com/official-stockfish/Stockfish/pull/3714 Bench: 5575265
2021-09-23 15:19:06 -06:00
ss->depth = depth;
Square prevSq = to_sq((ss-1)->currentMove);
Detect search explosions This patch detects some search explosions (due to double extensions in search.cpp) which can happen in some pathological positions, and takes measures to ensure progress in search even for these pathological situations. While a small number of double extensions can be useful during search (for example to resolve a tactical sequence), a sustained regime of double extensions leads to search explosion and a non-finishing search. See the discussion in https://github.com/official-stockfish/Stockfish/pull/3544 and the issue https://github.com/official-stockfish/Stockfish/issues/3532 . The implemented algorithm is the following: a) at each node during search, store the current depth in the stack. Double extensions are by definition levels of the stack where the depth at ply N is strictly higher than depth at ply N-1. b) during search, calculate for each thread a running average of the number of double extensions in the last 4096 visited nodes. c) if one thread has more than 2% of double extensions for a sustained period of time (6 millions consecutive nodes, or about 4 seconds on my iMac), we decide that this thread is in an explosion state and we calm down this thread by preventing it to do any double extension for the next 6 millions nodes. To calculate the running averages, we also introduced a auxiliary class generalizing the computations of ttHitAverage variable we already had in code. The implementation uses an exponential moving average of period 4096 and resolution 1/1024, and all computations are done with integers for efficiency. ----------- Example where the patch solves a search explosion: ``` ./stockfish ucinewgame position fen 8/Pk6/8/1p6/8/P1K5/8/6B1 w - - 37 130 go infinite ``` This algorithm does not affect search in normal, non-pathological positions. We verified, for instance, that the usual bench is unchanged up to depth 20 at least, and that the node numbers are unchanged for a search of the starting position at depth 32. ------------- See https://github.com/official-stockfish/Stockfish/pull/3714 Bench: 5575265
2021-09-23 15:19:06 -06:00
// Update the running average statistics for double extensions
thisThread->doubleExtensionAverage[us].update(ss->depth > (ss-1)->depth);
// Initialize statScore to zero for the grandchildren of the current position.
// So statScore is shared between all grandchildren and only the first grandchild
// starts with statScore = 0. Later grandchildren start with the last calculated
// statScore of the previous grandchild. This influences the reduction rules in
// LMR which are based on the statScore of parent position.
if (!rootNode)
(ss+2)->statScore = 0;
// Step 4. Transposition table lookup. We don't want the score of a partial
// search to overwrite a previous full search TT value, so we use a different
// position key in case of an excluded move.
excludedMove = ss->excludedMove;
posKey = excludedMove == MOVE_NONE ? pos.key() : pos.key() ^ make_key(excludedMove);
tte = TT.probe(posKey, ss->ttHit);
ttValue = ss->ttHit ? value_from_tt(tte->value(), ss->ply, pos.rule50_count()) : VALUE_NONE;
ttMove = rootNode ? thisThread->rootMoves[thisThread->pvIdx].pv[0]
: ss->ttHit ? tte->move() : MOVE_NONE;
ttCapture = ttMove && pos.capture_or_promotion(ttMove);
if (!excludedMove)
ss->ttPv = PvNode || (ss->ttHit && tte->is_pv());
// Update low ply history for previous move if we are near root and position is or has been in PV
if ( ss->ttPv
&& depth > 12
&& ss->ply - 1 < MAX_LPH
&& !priorCapture
&& is_ok((ss-1)->currentMove))
thisThread->lowPlyHistory[ss->ply - 1][from_to((ss-1)->currentMove)] << stat_bonus(depth - 5);
// At non-PV nodes we check for an early TT cutoff
if ( !PvNode
&& ss->ttHit
&& tte->depth() > depth - (thisThread->id() % 2 == 1)
&& ttValue != VALUE_NONE // Possible in case of TT access race
&& (ttValue >= beta ? (tte->bound() & BOUND_LOWER)
: (tte->bound() & BOUND_UPPER)))
{
// If ttMove is quiet, update move sorting heuristics on TT hit
if (ttMove)
{
if (ttValue >= beta)
{
// Bonus for a quiet ttMove that fails high
if (!ttCapture)
update_quiet_stats(pos, ss, ttMove, stat_bonus(depth), depth);
// Extra penalty for early quiet moves of the previous ply
if ((ss-1)->moveCount <= 2 && !priorCapture)
Eliminate ONE_PLY Simplification that eliminates ONE_PLY, based on a suggestion in the forum that support for fractional plies has never been used, and @mcostalba's openness to the idea of eliminating it. We lose a little bit of type safety by making Depth an integer, but in return we simplify the code in search.cpp quite significantly. No functional change ------------------------------------------ The argument favoring eliminating ONE_PLY: * The term “ONE_PLY” comes up in a lot of forum posts (474 to date) https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:relevance * There is occasionally a commit that breaks invariance of the code with respect to ONE_PLY https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:date/fishcooking/ZIPdYj6k0fk/KdNGcPWeBgAJ * To prevent such commits, there is a Travis CI hack that doubles ONE_PLY and rechecks bench * Sustaining ONE_PLY has, alas, not resulted in any improvements to the engine, despite many individuals testing many experiments over 5 years. The strongest argument in favor of preserving ONE_PLY comes from @locutus: “If we use par example ONE_PLY=256 the parameter space is increases by the factor 256. So it seems very unlikely that the optimal setting is in the subspace of ONE_PLY=1.” There is a strong theoretical impediment to fractional depth systems: the transposition table uses depth to determine when a stored result is good enough to supply an answer for a current search. If you have fractional depths, then different pathways to the position can be at fractionally different depths. In the end, there are three separate times when a proposal to remove ONE_PLY was defeated by the suggestion to “give it a few more months.” So… it seems like time to remove this distraction from the community. See the pull request here: https://github.com/official-stockfish/Stockfish/pull/2289
2019-09-28 14:27:23 -06:00
update_continuation_histories(ss-1, pos.piece_on(prevSq), prevSq, -stat_bonus(depth + 1));
}
// Penalty for a quiet ttMove that fails low
else if (!ttCapture)
{
Revert 5 recent patches Revert 5 patches which were merged, but lead to a regression test that showed negative Elo gain: http://tests.stockfishchess.org/tests/view/5e307251ab2d69d58394fdb9 This was discussed in depth in: https://github.com/official-stockfish/Stockfish/issues/2531 Each patch was removed and tested as a simplification, full list below, and the whole combo as well. After the revert the regression test showed a neutral result: http://tests.stockfishchess.org/tests/view/5e334851708b13464ceea33c As a result of this experience, the SPRT testing bounds will be made more strict. Reverted patches: 1 Dynamic Complexity 6d0eabd5fe2961551477820ab7619e2c31e01ffd : STC 10+0.1 https://tests.stockfishchess.org/tests/view/5e31fcacec661e2e6a340d08 : LLR: 2.97 (-2.94,2.94) {-1.50,0.50} Total: 38130 W: 7326 L: 7189 D: 23615 Ptnml(0-2): 677, 4346, 8843, 4545, 646 LTC 60+0.6 https://tests.stockfishchess.org/tests/view/5e32c18fec661e2e6a340d73 : LLR: 2.94 (-2.94,2.94) {-1.50,0.50} Total: 38675 W: 4941 L: 4866 D: 28868 Ptnml(0-2): 270, 3556, 11429, 3584, 291 3 More bonus for bestMoves on past PV nodes 71e0b5385e2717679a57c6b77d8c7ac5fff3b89f : STC 10+0.1 https://tests.stockfishchess.org/tests/view/5e31fe93ec661e2e6a340d10 : LLR: 2.95 (-2.94,2.94) {-1.50,0.50} Total: 46100 W: 8853 L: 8727 D: 28520 Ptnml(0-2): 796, 5297, 10749, 5387, 813 LTC 60+0.6 https://tests.stockfishchess.org/tests/view/5e32c187ec661e2e6a340d71 : LLR: 2.96 (-2.94,2.94) {-1.50,0.50} Total: 16920 W: 2161 L: 2055 D: 12704 Ptnml(0-2): 115, 1498, 5006, 1569, 130 4 Tweak Restricted Piece Bonus 0ae00454ba6928d181b46103e5c83e6d58fcebe5 : STC 10+0.1 https://tests.stockfishchess.org/tests/view/5e31fefaec661e2e6a340d15 : LLR: 2.94 (-2.94,2.94) {-1.50,0.50} Total: 88328 W: 17060 L: 16997 D: 54271 Ptnml(0-2): 1536, 10446, 20169, 10422, 1581 LTC 60+0.6 https://tests.stockfishchess.org/tests/view/5e32c17aec661e2e6a340d6f : LLR: 2.95 (-2.94,2.94) {-1.50,0.50} Total: 34784 W: 4551 L: 4466 D: 25767 Ptnml(0-2): 255, 3279, 10061, 3345, 262 5 History update for pruned captures 01b6088af39902001d2d6844561b6a2faa549282 : STC 10+0.1 https://tests.stockfishchess.org/tests/view/5e31ff5eec661e2e6a340d1a : LLR: 2.94 (-2.94,2.94) {-1.50,0.50} Total: 29541 W: 5735 L: 5588 D: 18218 Ptnml(0-2): 483, 3445, 6820, 3469, 545 LTC 60+0.6 https://tests.stockfishchess.org/tests/view/5e32c196ec661e2e6a340d75 : LLR: 2.94 (-2.94,2.94) {-1.50,0.50} Total: 22177 W: 2854 L: 2757 D: 16566 Ptnml(0-2): 143, 2005, 6555, 2055, 164 6 Tweak trapped rook penalty 18fc21eba0368fd5e3c4c4b8ee1000c9ac445425 : STC 10+0.1 https://tests.stockfishchess.org/tests/view/5e31ffb1ec661e2e6a340d1c : LLR: 2.95 (-2.94,2.94) {-1.50,0.50} Total: 24476 W: 4727 L: 4569 D: 15180 Ptnml(0-2): 390, 2834, 5659, 2933, 417 LTC 60+0.6 https://tests.stockfishchess.org/tests/view/5e32c19eec661e2e6a340d77 : LLR: 2.95 (-2.94,2.94) {-1.50,0.50} Total: 97332 W: 12492 L: 12466 D: 72374 Ptnml(0-2): 690, 9107, 28738, 9034, 720 All 5 as one simplification : LTC 60+0.6 https://tests.stockfishchess.org/tests/view/5e334098708b13464ceea330 : LLR: 2.94 (-2.94,2.94) {-1.50,0.50} Total: 7829 W: 1079 L: 964 D: 5786 Ptnml(0-2): 52, 690, 2281, 781, 65 Bench: 5153165
2020-01-30 13:44:04 -07:00
int penalty = -stat_bonus(depth);
thisThread->mainHistory[us][from_to(ttMove)] << penalty;
update_continuation_histories(ss, pos.moved_piece(ttMove), to_sq(ttMove), penalty);
}
}
50-moves rule improvement for transposition table User "adentong" reported recently of a game where Stockfish blundered a game in a tournament because during a search there was an hash-table issue for positions inside the tree very close to the 50-moves draw rule. This is part of a problem which is commonly referred to as the Graph History Interaction (GHI), and is difficult to solve in computer chess because storing the 50-moves counter in the hash-table loses Elo in general. Links: Issue 2451 : https://github.com/official-stockfish/Stockfish/issues/2451 About the GHI : https://www.chessprogramming.org/Graph_History_Interaction This patch tries to address the issue in this particular game and similar reported games: it prevents that values from the transposition table are getting used when the 50-move counter is close to reaching 100 (). The idea is that in such cases values from previous searches, with a much lower 50-move count, become less and less reliable. More precisely, the heuristic we use in this patch is that we don't take the transposition table cutoff when we have reached a 45-moves limit, but let the search continue doing its job. There is a possible slowdown involved, but it will also help to find either a draw when it thought to be losing, or a way to avoid the draw by 50-move rule. This heuristics probably will not fix all possible cases, but seems to be working reasonably well in practice while not losing too much Elo. Passed non-regression tests: STC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 274452 W: 59700 L: 60075 D: 154677 http://tests.stockfishchess.org/tests/view/5df546116932658fe9b451bf LTC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 95235 W: 15297 L: 15292 D: 64646 http://tests.stockfishchess.org/tests/view/5df69c926932658fe9b4520e Closes https://github.com/official-stockfish/Stockfish/pull/2453 Bench: 4586187
2019-12-12 04:53:47 -07:00
// Partial workaround for the graph history interaction problem
// For high rule50 counts don't produce transposition table cutoffs.
50-moves rule improvement for transposition table User "adentong" reported recently of a game where Stockfish blundered a game in a tournament because during a search there was an hash-table issue for positions inside the tree very close to the 50-moves draw rule. This is part of a problem which is commonly referred to as the Graph History Interaction (GHI), and is difficult to solve in computer chess because storing the 50-moves counter in the hash-table loses Elo in general. Links: Issue 2451 : https://github.com/official-stockfish/Stockfish/issues/2451 About the GHI : https://www.chessprogramming.org/Graph_History_Interaction This patch tries to address the issue in this particular game and similar reported games: it prevents that values from the transposition table are getting used when the 50-move counter is close to reaching 100 (). The idea is that in such cases values from previous searches, with a much lower 50-move count, become less and less reliable. More precisely, the heuristic we use in this patch is that we don't take the transposition table cutoff when we have reached a 45-moves limit, but let the search continue doing its job. There is a possible slowdown involved, but it will also help to find either a draw when it thought to be losing, or a way to avoid the draw by 50-move rule. This heuristics probably will not fix all possible cases, but seems to be working reasonably well in practice while not losing too much Elo. Passed non-regression tests: STC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 274452 W: 59700 L: 60075 D: 154677 http://tests.stockfishchess.org/tests/view/5df546116932658fe9b451bf LTC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 95235 W: 15297 L: 15292 D: 64646 http://tests.stockfishchess.org/tests/view/5df69c926932658fe9b4520e Closes https://github.com/official-stockfish/Stockfish/pull/2453 Bench: 4586187
2019-12-12 04:53:47 -07:00
if (pos.rule50_count() < 90)
return ttValue;
2008-08-31 23:59:13 -06:00
}
// Step 5. Tablebases probe
if (!rootNode && TB::Cardinality)
2015-01-18 00:05:05 -07:00
{
int piecesCount = pos.count<ALL_PIECES>();
2015-01-18 00:05:05 -07:00
if ( piecesCount <= TB::Cardinality
&& (piecesCount < TB::Cardinality || depth >= TB::ProbeDepth)
&& pos.rule50_count() == 0
&& !pos.can_castle(ANY_CASTLING))
2015-01-18 00:05:05 -07:00
{
TB::ProbeState err;
TB::WDLScore wdl = Tablebases::probe_wdl(pos, &err);
2015-01-18 00:05:05 -07:00
// Force check of time on the next occasion
if (thisThread == Threads.main())
static_cast<MainThread*>(thisThread)->callsCnt = 0;
if (err != TB::ProbeState::FAIL)
2015-01-18 00:05:05 -07:00
{
thisThread->tbHits.fetch_add(1, std::memory_order_relaxed);
2015-01-18 00:05:05 -07:00
int drawScore = TB::UseRule50 ? 1 : 0;
Fix for incorrect VALUE_MATE_IN_MAX_PLY usage. Fixes #2533, fixes #2543, fixes #2423. the code that prevents false mate announcements depending on the TT state (GHI), incorrectly used VALUE_MATE_IN_MAX_PLY. The latter constant, however, also includes, counterintuitively, the TB win range. This patch fixes that, by restoring the behavior for TB win scores, while retaining the false mate correctness, and improving the mate finding ability. In particular no alse mates are announced with the poisened hash testcase ``` position fen 8/8/8/3k4/8/8/6K1/7R w - - 0 1 go depth 40 position fen 8/8/8/3k4/8/8/6K1/7R w - - 76 1 go depth 20 ucinewgame ``` mates are found with the testcases reported in #2543 ``` position fen 4k3/3pp3/8/8/8/8/2PPP3/4K3 w - - 0 1 setoption name Hash value 1024 go depth 55 ucinewgame ``` and ``` position fen 4k3/4p3/8/8/8/8/3PP3/4K3 w - - 0 1 setoption name Hash value 1024 go depth 45 ucinewgame ``` furthermore, on the mate finding benchmark (ChestUCI_23102018.epd), performance improves over master, roughly reaching performance with the false mate protection reverted ``` Analyzing 6566 mate positions for best and found mates: ----------------best ---------------found nodes master revert fixed master revert fixed 16000000 4233 4236 4235 5200 5201 5199 32000000 4583 4585 4585 5417 5424 5418 64000000 4852 4853 4855 5575 5584 5579 128000000 5071 5068 5066 5710 5720 5716 256000000 5280 5282 5279 5819 5827 5826 512000000 5471 5468 5468 5919 5935 5932 ``` On a testcase with TB enabled, progress is made consistently, contrary to master ``` setoption name SyzygyPath value ../../../syzygy/3-4-5/ setoption name Hash value 2048 position fen 1R6/3k4/8/K2p4/4n3/2P5/8/8 w - - 0 1 go depth 58 ucinewgame ``` The PR (prior to a rewrite for clarity) passed STC: LLR: 2.94 (-2.94,2.94) {-1.50,0.50} Total: 65405 W: 12454 L: 12384 D: 40567 Ptnml(0-2): 920, 7256, 16285, 7286, 944 http://tests.stockfishchess.org/tests/view/5e441a3be70d848499f63d15 passed LTC: LLR: 2.94 (-2.94,2.94) {-1.50,0.50} Total: 27096 W: 3477 L: 3413 D: 20206 Ptnml(0-2): 128, 2215, 8776, 2292, 122 http://tests.stockfishchess.org/tests/view/5e44e277e70d848499f63d63 The incorrectly named VALUE_MATE_IN_MAX_PLY and VALUE_MATED_IN_MAX_PLY were renamed into VALUE_TB_WIN_IN_MAX_PLY and VALUE_TB_LOSS_IN_MAX_PLY, and correclty defined VALUE_MATE_IN_MAX_PLY and VALUE_MATED_IN_MAX_PLY were introduced. One further (corner case) mistake using these constants was fixed (go mate X), which could lead to a premature return if X > MAX_PLY / 2, but TB were present. Thanks to @svivanov72 for one of the reports and help fixing the issue. closes https://github.com/official-stockfish/Stockfish/pull/2552 Bench: 4932981
2020-02-11 12:42:32 -07:00
// use the range VALUE_MATE_IN_MAX_PLY to VALUE_TB_WIN_IN_MAX_PLY to score
value = wdl < -drawScore ? VALUE_MATED_IN_MAX_PLY + ss->ply + 1
: wdl > drawScore ? VALUE_MATE_IN_MAX_PLY - ss->ply - 1
: VALUE_DRAW + 2 * wdl * drawScore;
2015-01-18 00:05:05 -07:00
Bound b = wdl < -drawScore ? BOUND_UPPER
: wdl > drawScore ? BOUND_LOWER : BOUND_EXACT;
2015-01-18 00:05:05 -07:00
if ( b == BOUND_EXACT
|| (b == BOUND_LOWER ? value >= beta : value <= alpha))
{
tte->save(posKey, value_to_tt(value, ss->ply), ss->ttPv, b,
Eliminate ONE_PLY Simplification that eliminates ONE_PLY, based on a suggestion in the forum that support for fractional plies has never been used, and @mcostalba's openness to the idea of eliminating it. We lose a little bit of type safety by making Depth an integer, but in return we simplify the code in search.cpp quite significantly. No functional change ------------------------------------------ The argument favoring eliminating ONE_PLY: * The term “ONE_PLY” comes up in a lot of forum posts (474 to date) https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:relevance * There is occasionally a commit that breaks invariance of the code with respect to ONE_PLY https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:date/fishcooking/ZIPdYj6k0fk/KdNGcPWeBgAJ * To prevent such commits, there is a Travis CI hack that doubles ONE_PLY and rechecks bench * Sustaining ONE_PLY has, alas, not resulted in any improvements to the engine, despite many individuals testing many experiments over 5 years. The strongest argument in favor of preserving ONE_PLY comes from @locutus: “If we use par example ONE_PLY=256 the parameter space is increases by the factor 256. So it seems very unlikely that the optimal setting is in the subspace of ONE_PLY=1.” There is a strong theoretical impediment to fractional depth systems: the transposition table uses depth to determine when a stored result is good enough to supply an answer for a current search. If you have fractional depths, then different pathways to the position can be at fractionally different depths. In the end, there are three separate times when a proposal to remove ONE_PLY was defeated by the suggestion to “give it a few more months.” So… it seems like time to remove this distraction from the community. See the pull request here: https://github.com/official-stockfish/Stockfish/pull/2289
2019-09-28 14:27:23 -06:00
std::min(MAX_PLY - 1, depth + 6),
MOVE_NONE, VALUE_NONE);
return value;
}
if (PvNode)
{
if (b == BOUND_LOWER)
bestValue = value, alpha = std::max(alpha, bestValue);
else
maxValue = value;
}
2015-01-18 00:05:05 -07:00
}
}
}
CapturePieceToHistory& captureHistory = thisThread->captureHistory;
// Step 6. Static evaluation of the position
if (ss->inCheck)
{
// Skip early pruning when in check
ss->staticEval = eval = VALUE_NONE;
improving = false;
improvement = 0;
goto moves_loop;
}
else if (ss->ttHit)
{
// Never assume anything about values stored in TT
ss->staticEval = eval = tte->eval();
if (eval == VALUE_NONE)
ss->staticEval = eval = evaluate(pos);
// Randomize draw evaluation
if (eval == VALUE_DRAW)
eval = value_draw(thisThread);
// Can ttValue be used as a better position evaluation?
if ( ttValue != VALUE_NONE
&& (tte->bound() & (ttValue > eval ? BOUND_LOWER : BOUND_UPPER)))
eval = ttValue;
}
else
{
ss->staticEval = eval = evaluate(pos);
// Save static evaluation into transposition table
if (!excludedMove)
tte->save(posKey, VALUE_NONE, ss->ttPv, BOUND_NONE, DEPTH_NONE, MOVE_NONE, eval);
2011-10-31 01:28:59 -06:00
}
2008-08-31 23:59:13 -06:00
// Use static evaluation difference to improve quiet move ordering
if (is_ok((ss-1)->currentMove) && !(ss-1)->inCheck && !priorCapture)
{
int bonus = std::clamp(-depth * 4 * int((ss-1)->staticEval + ss->staticEval), -1000, 1000);
thisThread->mainHistory[~us][from_to((ss-1)->currentMove)] << bonus;
}
// Set up the improvement variable, which is the difference between the current
// static evaluation and the previous static evaluation at our turn (if we were
// in check at our previous move we look at the move prior to it). The improvement
// margin and the improving flag are used in various pruning heuristics.
improvement = (ss-2)->staticEval != VALUE_NONE ? ss->staticEval - (ss-2)->staticEval
: (ss-4)->staticEval != VALUE_NONE ? ss->staticEval - (ss-4)->staticEval
: 200;
improving = improvement > 0;
// Step 7. Futility pruning: child node (~50 Elo).
// The depth condition is important for mate finding.
if ( !PvNode
&& depth < 9
&& eval - futility_margin(depth, improving) >= beta
&& eval < VALUE_KNOWN_WIN) // Do not return unproven wins
return eval;
// Step 8. Null move search with verification search (~40 Elo)
if ( !PvNode
&& (ss-1)->currentMove != MOVE_NULL
&& (ss-1)->statScore < 23767
&& eval >= beta
&& eval >= ss->staticEval
&& ss->staticEval >= beta - 20 * depth - improvement / 15 + 204
&& !excludedMove
&& pos.non_pawn_material(us)
&& (ss->ply >= thisThread->nmpMinPly || us != thisThread->nmpColor))
{
assert(eval - beta >= 0);
// Null move dynamic reduction based on depth and value
Depth R = std::min(int(eval - beta) / 205, 3) + depth / 3 + 4;
ss->currentMove = MOVE_NULL;
ss->continuationHistory = &thisThread->continuationHistory[0][0][NO_PIECE][0];
pos.do_null_move(st);
Value nullValue = -search<NonPV>(pos, ss+1, -beta, -beta+1, depth-R, !cutNode);
pos.undo_null_move();
if (nullValue >= beta)
{
// Do not return unproven mate or TB scores
Fix for incorrect VALUE_MATE_IN_MAX_PLY usage. Fixes #2533, fixes #2543, fixes #2423. the code that prevents false mate announcements depending on the TT state (GHI), incorrectly used VALUE_MATE_IN_MAX_PLY. The latter constant, however, also includes, counterintuitively, the TB win range. This patch fixes that, by restoring the behavior for TB win scores, while retaining the false mate correctness, and improving the mate finding ability. In particular no alse mates are announced with the poisened hash testcase ``` position fen 8/8/8/3k4/8/8/6K1/7R w - - 0 1 go depth 40 position fen 8/8/8/3k4/8/8/6K1/7R w - - 76 1 go depth 20 ucinewgame ``` mates are found with the testcases reported in #2543 ``` position fen 4k3/3pp3/8/8/8/8/2PPP3/4K3 w - - 0 1 setoption name Hash value 1024 go depth 55 ucinewgame ``` and ``` position fen 4k3/4p3/8/8/8/8/3PP3/4K3 w - - 0 1 setoption name Hash value 1024 go depth 45 ucinewgame ``` furthermore, on the mate finding benchmark (ChestUCI_23102018.epd), performance improves over master, roughly reaching performance with the false mate protection reverted ``` Analyzing 6566 mate positions for best and found mates: ----------------best ---------------found nodes master revert fixed master revert fixed 16000000 4233 4236 4235 5200 5201 5199 32000000 4583 4585 4585 5417 5424 5418 64000000 4852 4853 4855 5575 5584 5579 128000000 5071 5068 5066 5710 5720 5716 256000000 5280 5282 5279 5819 5827 5826 512000000 5471 5468 5468 5919 5935 5932 ``` On a testcase with TB enabled, progress is made consistently, contrary to master ``` setoption name SyzygyPath value ../../../syzygy/3-4-5/ setoption name Hash value 2048 position fen 1R6/3k4/8/K2p4/4n3/2P5/8/8 w - - 0 1 go depth 58 ucinewgame ``` The PR (prior to a rewrite for clarity) passed STC: LLR: 2.94 (-2.94,2.94) {-1.50,0.50} Total: 65405 W: 12454 L: 12384 D: 40567 Ptnml(0-2): 920, 7256, 16285, 7286, 944 http://tests.stockfishchess.org/tests/view/5e441a3be70d848499f63d15 passed LTC: LLR: 2.94 (-2.94,2.94) {-1.50,0.50} Total: 27096 W: 3477 L: 3413 D: 20206 Ptnml(0-2): 128, 2215, 8776, 2292, 122 http://tests.stockfishchess.org/tests/view/5e44e277e70d848499f63d63 The incorrectly named VALUE_MATE_IN_MAX_PLY and VALUE_MATED_IN_MAX_PLY were renamed into VALUE_TB_WIN_IN_MAX_PLY and VALUE_TB_LOSS_IN_MAX_PLY, and correclty defined VALUE_MATE_IN_MAX_PLY and VALUE_MATED_IN_MAX_PLY were introduced. One further (corner case) mistake using these constants was fixed (go mate X), which could lead to a premature return if X > MAX_PLY / 2, but TB were present. Thanks to @svivanov72 for one of the reports and help fixing the issue. closes https://github.com/official-stockfish/Stockfish/pull/2552 Bench: 4932981
2020-02-11 12:42:32 -07:00
if (nullValue >= VALUE_TB_WIN_IN_MAX_PLY)
nullValue = beta;
if (thisThread->nmpMinPly || (abs(beta) < VALUE_KNOWN_WIN && depth < 14))
return nullValue;
assert(!thisThread->nmpMinPly); // Recursive verification is not allowed
// Do verification search at high depths, with null move pruning disabled
// for us, until ply exceeds nmpMinPly.
Eliminate ONE_PLY Simplification that eliminates ONE_PLY, based on a suggestion in the forum that support for fractional plies has never been used, and @mcostalba's openness to the idea of eliminating it. We lose a little bit of type safety by making Depth an integer, but in return we simplify the code in search.cpp quite significantly. No functional change ------------------------------------------ The argument favoring eliminating ONE_PLY: * The term “ONE_PLY” comes up in a lot of forum posts (474 to date) https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:relevance * There is occasionally a commit that breaks invariance of the code with respect to ONE_PLY https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:date/fishcooking/ZIPdYj6k0fk/KdNGcPWeBgAJ * To prevent such commits, there is a Travis CI hack that doubles ONE_PLY and rechecks bench * Sustaining ONE_PLY has, alas, not resulted in any improvements to the engine, despite many individuals testing many experiments over 5 years. The strongest argument in favor of preserving ONE_PLY comes from @locutus: “If we use par example ONE_PLY=256 the parameter space is increases by the factor 256. So it seems very unlikely that the optimal setting is in the subspace of ONE_PLY=1.” There is a strong theoretical impediment to fractional depth systems: the transposition table uses depth to determine when a stored result is good enough to supply an answer for a current search. If you have fractional depths, then different pathways to the position can be at fractionally different depths. In the end, there are three separate times when a proposal to remove ONE_PLY was defeated by the suggestion to “give it a few more months.” So… it seems like time to remove this distraction from the community. See the pull request here: https://github.com/official-stockfish/Stockfish/pull/2289
2019-09-28 14:27:23 -06:00
thisThread->nmpMinPly = ss->ply + 3 * (depth-R) / 4;
thisThread->nmpColor = us;
Value v = search<NonPV>(pos, ss, beta-1, beta, depth-R, false);
thisThread->nmpMinPly = 0;
if (v >= beta)
return nullValue;
}
}
2008-08-31 23:59:13 -06:00
probCutBeta = beta + 209 - 44 * improving;
Maximize usage of transposition table in probcut Probcut is a heuristic that wasn't changed a lot in past years, all attempts to change it using information / writing info to transposition table failed. This patch has a number of differences that can be summarized as follows: * For TT write/read we use depth - 3. Because probcut search is depth - 4 but we actually do the move prior to it so effectively we do depth - 3 search; * In any case of depth of eval from transposition table being >= depth - 3 we either produce cutoff or refuse to even do probcut search, this is allowing us to write info of probcut to transposition table because we know that we wouldn't be overwriting some deeper data with our depth - 3 search - this is an important aspect of this patch; * For some not really known reason this patch completely ignores tte->bound() - which was the case for previous patch that made probcut interact with TT, maybe 2) is the reason, although it's unproven. A first version of this patch passed STC and LTC passed STC https://tests.stockfishchess.org/tests/view/5f05908a59f6f03532894613 LLR: 2.95 (-2.94,2.94) {-0.50,1.50} Total: 95776 W: 18300 L: 17973 D: 59503 Ptnml(0-2): 1646, 10944, 22377, 11279, 1642 passed LTC https://tests.stockfishchess.org/tests/view/5f06b54059f6f035328946bb LLR: 2.94 (-2.94,2.94) {0.25,1.75} Total: 57128 W: 7266 L: 6938 D: 42924 Ptnml(0-2): 372, 5163, 17217, 5389, 423 However, an additional bugfix was needed to avoid checking a condition on ttMove if was not available. This passed non-regression bounds on top of the first version: at STC https://tests.stockfishchess.org/tests/view/5f080e5059f6f03532894766 LLR: 2.94 (-2.94,2.94) {-1.50,0.50} Total: 14096 W: 2800 L: 2628 D: 8668 Ptnml(0-2): 225, 1620, 3238, 1688, 277 at LTC https://tests.stockfishchess.org/tests/view/5f0836a559f6f0353289479c LLR: 2.95 (-2.94,2.94) {-1.50,0.50} Total: 25352 W: 3228 L: 3139 D: 18985 Ptnml(0-2): 175, 2350, 7549, 2415, 187 closes https://github.com/official-stockfish/Stockfish/pull/2804 Bench 4540940
2020-07-10 15:06:55 -06:00
// Step 9. ProbCut (~4 Elo)
// If we have a good enough capture and a reduced search returns a value
// much above beta, we can (almost) safely prune the previous move.
if ( !PvNode
&& depth > 4
Maximize usage of transposition table in probcut Probcut is a heuristic that wasn't changed a lot in past years, all attempts to change it using information / writing info to transposition table failed. This patch has a number of differences that can be summarized as follows: * For TT write/read we use depth - 3. Because probcut search is depth - 4 but we actually do the move prior to it so effectively we do depth - 3 search; * In any case of depth of eval from transposition table being >= depth - 3 we either produce cutoff or refuse to even do probcut search, this is allowing us to write info of probcut to transposition table because we know that we wouldn't be overwriting some deeper data with our depth - 3 search - this is an important aspect of this patch; * For some not really known reason this patch completely ignores tte->bound() - which was the case for previous patch that made probcut interact with TT, maybe 2) is the reason, although it's unproven. A first version of this patch passed STC and LTC passed STC https://tests.stockfishchess.org/tests/view/5f05908a59f6f03532894613 LLR: 2.95 (-2.94,2.94) {-0.50,1.50} Total: 95776 W: 18300 L: 17973 D: 59503 Ptnml(0-2): 1646, 10944, 22377, 11279, 1642 passed LTC https://tests.stockfishchess.org/tests/view/5f06b54059f6f035328946bb LLR: 2.94 (-2.94,2.94) {0.25,1.75} Total: 57128 W: 7266 L: 6938 D: 42924 Ptnml(0-2): 372, 5163, 17217, 5389, 423 However, an additional bugfix was needed to avoid checking a condition on ttMove if was not available. This passed non-regression bounds on top of the first version: at STC https://tests.stockfishchess.org/tests/view/5f080e5059f6f03532894766 LLR: 2.94 (-2.94,2.94) {-1.50,0.50} Total: 14096 W: 2800 L: 2628 D: 8668 Ptnml(0-2): 225, 1620, 3238, 1688, 277 at LTC https://tests.stockfishchess.org/tests/view/5f0836a559f6f0353289479c LLR: 2.95 (-2.94,2.94) {-1.50,0.50} Total: 25352 W: 3228 L: 3139 D: 18985 Ptnml(0-2): 175, 2350, 7549, 2415, 187 closes https://github.com/official-stockfish/Stockfish/pull/2804 Bench 4540940
2020-07-10 15:06:55 -06:00
&& abs(beta) < VALUE_TB_WIN_IN_MAX_PLY
// if value from transposition table is lower than probCutBeta, don't attempt probCut
// there and in further interactions with transposition table cutoff depth is set to depth - 3
// because probCut search has depth set to depth - 4 but we also do a move before it
// so effective depth is equal to depth - 3
&& !( ss->ttHit
&& tte->depth() >= depth - 3
Maximize usage of transposition table in probcut Probcut is a heuristic that wasn't changed a lot in past years, all attempts to change it using information / writing info to transposition table failed. This patch has a number of differences that can be summarized as follows: * For TT write/read we use depth - 3. Because probcut search is depth - 4 but we actually do the move prior to it so effectively we do depth - 3 search; * In any case of depth of eval from transposition table being >= depth - 3 we either produce cutoff or refuse to even do probcut search, this is allowing us to write info of probcut to transposition table because we know that we wouldn't be overwriting some deeper data with our depth - 3 search - this is an important aspect of this patch; * For some not really known reason this patch completely ignores tte->bound() - which was the case for previous patch that made probcut interact with TT, maybe 2) is the reason, although it's unproven. A first version of this patch passed STC and LTC passed STC https://tests.stockfishchess.org/tests/view/5f05908a59f6f03532894613 LLR: 2.95 (-2.94,2.94) {-0.50,1.50} Total: 95776 W: 18300 L: 17973 D: 59503 Ptnml(0-2): 1646, 10944, 22377, 11279, 1642 passed LTC https://tests.stockfishchess.org/tests/view/5f06b54059f6f035328946bb LLR: 2.94 (-2.94,2.94) {0.25,1.75} Total: 57128 W: 7266 L: 6938 D: 42924 Ptnml(0-2): 372, 5163, 17217, 5389, 423 However, an additional bugfix was needed to avoid checking a condition on ttMove if was not available. This passed non-regression bounds on top of the first version: at STC https://tests.stockfishchess.org/tests/view/5f080e5059f6f03532894766 LLR: 2.94 (-2.94,2.94) {-1.50,0.50} Total: 14096 W: 2800 L: 2628 D: 8668 Ptnml(0-2): 225, 1620, 3238, 1688, 277 at LTC https://tests.stockfishchess.org/tests/view/5f0836a559f6f0353289479c LLR: 2.95 (-2.94,2.94) {-1.50,0.50} Total: 25352 W: 3228 L: 3139 D: 18985 Ptnml(0-2): 175, 2350, 7549, 2415, 187 closes https://github.com/official-stockfish/Stockfish/pull/2804 Bench 4540940
2020-07-10 15:06:55 -06:00
&& ttValue != VALUE_NONE
&& ttValue < probCutBeta))
{
assert(probCutBeta < VALUE_INFINITE);
MovePicker mp(pos, ttMove, probCutBeta - ss->staticEval, &captureHistory);
bool ttPv = ss->ttPv;
ss->ttPv = false;
while ((move = mp.next_move()) != MOVE_NONE)
if (move != excludedMove && pos.legal(move))
{
assert(pos.capture_or_promotion(move));
assert(depth >= 5);
captureOrPromotion = true;
ss->currentMove = move;
ss->continuationHistory = &thisThread->continuationHistory[ss->inCheck]
[captureOrPromotion]
[pos.moved_piece(move)]
[to_sq(move)];
pos.do_move(move, st);
// Perform a preliminary qsearch to verify that the move holds
value = -qsearch<NonPV>(pos, ss+1, -probCutBeta, -probCutBeta+1);
// If the qsearch held, perform the regular search
if (value >= probCutBeta)
value = -search<NonPV>(pos, ss+1, -probCutBeta, -probCutBeta+1, depth - 4, !cutNode);
pos.undo_move(move);
if (value >= probCutBeta)
Maximize usage of transposition table in probcut Probcut is a heuristic that wasn't changed a lot in past years, all attempts to change it using information / writing info to transposition table failed. This patch has a number of differences that can be summarized as follows: * For TT write/read we use depth - 3. Because probcut search is depth - 4 but we actually do the move prior to it so effectively we do depth - 3 search; * In any case of depth of eval from transposition table being >= depth - 3 we either produce cutoff or refuse to even do probcut search, this is allowing us to write info of probcut to transposition table because we know that we wouldn't be overwriting some deeper data with our depth - 3 search - this is an important aspect of this patch; * For some not really known reason this patch completely ignores tte->bound() - which was the case for previous patch that made probcut interact with TT, maybe 2) is the reason, although it's unproven. A first version of this patch passed STC and LTC passed STC https://tests.stockfishchess.org/tests/view/5f05908a59f6f03532894613 LLR: 2.95 (-2.94,2.94) {-0.50,1.50} Total: 95776 W: 18300 L: 17973 D: 59503 Ptnml(0-2): 1646, 10944, 22377, 11279, 1642 passed LTC https://tests.stockfishchess.org/tests/view/5f06b54059f6f035328946bb LLR: 2.94 (-2.94,2.94) {0.25,1.75} Total: 57128 W: 7266 L: 6938 D: 42924 Ptnml(0-2): 372, 5163, 17217, 5389, 423 However, an additional bugfix was needed to avoid checking a condition on ttMove if was not available. This passed non-regression bounds on top of the first version: at STC https://tests.stockfishchess.org/tests/view/5f080e5059f6f03532894766 LLR: 2.94 (-2.94,2.94) {-1.50,0.50} Total: 14096 W: 2800 L: 2628 D: 8668 Ptnml(0-2): 225, 1620, 3238, 1688, 277 at LTC https://tests.stockfishchess.org/tests/view/5f0836a559f6f0353289479c LLR: 2.95 (-2.94,2.94) {-1.50,0.50} Total: 25352 W: 3228 L: 3139 D: 18985 Ptnml(0-2): 175, 2350, 7549, 2415, 187 closes https://github.com/official-stockfish/Stockfish/pull/2804 Bench 4540940
2020-07-10 15:06:55 -06:00
{
// if transposition table doesn't have equal or more deep info write probCut data into it
if ( !(ss->ttHit
&& tte->depth() >= depth - 3
&& ttValue != VALUE_NONE))
tte->save(posKey, value_to_tt(value, ss->ply), ttPv,
BOUND_LOWER,
depth - 3, move, ss->staticEval);
return value;
Maximize usage of transposition table in probcut Probcut is a heuristic that wasn't changed a lot in past years, all attempts to change it using information / writing info to transposition table failed. This patch has a number of differences that can be summarized as follows: * For TT write/read we use depth - 3. Because probcut search is depth - 4 but we actually do the move prior to it so effectively we do depth - 3 search; * In any case of depth of eval from transposition table being >= depth - 3 we either produce cutoff or refuse to even do probcut search, this is allowing us to write info of probcut to transposition table because we know that we wouldn't be overwriting some deeper data with our depth - 3 search - this is an important aspect of this patch; * For some not really known reason this patch completely ignores tte->bound() - which was the case for previous patch that made probcut interact with TT, maybe 2) is the reason, although it's unproven. A first version of this patch passed STC and LTC passed STC https://tests.stockfishchess.org/tests/view/5f05908a59f6f03532894613 LLR: 2.95 (-2.94,2.94) {-0.50,1.50} Total: 95776 W: 18300 L: 17973 D: 59503 Ptnml(0-2): 1646, 10944, 22377, 11279, 1642 passed LTC https://tests.stockfishchess.org/tests/view/5f06b54059f6f035328946bb LLR: 2.94 (-2.94,2.94) {0.25,1.75} Total: 57128 W: 7266 L: 6938 D: 42924 Ptnml(0-2): 372, 5163, 17217, 5389, 423 However, an additional bugfix was needed to avoid checking a condition on ttMove if was not available. This passed non-regression bounds on top of the first version: at STC https://tests.stockfishchess.org/tests/view/5f080e5059f6f03532894766 LLR: 2.94 (-2.94,2.94) {-1.50,0.50} Total: 14096 W: 2800 L: 2628 D: 8668 Ptnml(0-2): 225, 1620, 3238, 1688, 277 at LTC https://tests.stockfishchess.org/tests/view/5f0836a559f6f0353289479c LLR: 2.95 (-2.94,2.94) {-1.50,0.50} Total: 25352 W: 3228 L: 3139 D: 18985 Ptnml(0-2): 175, 2350, 7549, 2415, 187 closes https://github.com/official-stockfish/Stockfish/pull/2804 Bench 4540940
2020-07-10 15:06:55 -06:00
}
}
ss->ttPv = ttPv;
}
// Step 10. If the position is not in TT, decrease depth by 2 or 1 depending on node type
if ( PvNode
&& depth >= 6
&& !ttMove)
depth -= 2;
if ( cutNode
&& depth >= 9
&& !ttMove)
depth--;
moves_loop: // When in check, search starts here
int rangeReduction = 0;
// Step 11. A small Probcut idea, when we are in check
probCutBeta = beta + 409;
if ( ss->inCheck
&& !PvNode
&& depth >= 4
&& ttCapture
&& (tte->bound() & BOUND_LOWER)
&& tte->depth() >= depth - 3
&& ttValue >= probCutBeta
&& abs(ttValue) <= VALUE_KNOWN_WIN
&& abs(beta) <= VALUE_KNOWN_WIN
)
return probCutBeta;
const PieceToHistory* contHist[] = { (ss-1)->continuationHistory, (ss-2)->continuationHistory,
nullptr , (ss-4)->continuationHistory,
nullptr , (ss-6)->continuationHistory };
Move countermove = thisThread->counterMoves[pos.piece_on(prevSq)][prevSq];
MovePicker mp(pos, ttMove, depth, &thisThread->mainHistory,
&thisThread->lowPlyHistory,
&captureHistory,
contHist,
countermove,
ss->killers,
ss->ply);
value = bestValue;
singularQuietLMR = moveCountPruning = false;
// Indicate PvNodes that will probably fail low if the node was searched
// at a depth equal or greater than the current depth, and the result of this search was a fail low.
bool likelyFailLow = PvNode
&& ttMove
&& (tte->bound() & BOUND_UPPER)
&& tte->depth() >= depth;
// Step 12. Loop through all pseudo-legal moves until no moves remain
// or a beta cutoff occurs.
while ((move = mp.next_move(moveCountPruning)) != MOVE_NONE)
{
assert(is_ok(move));
if (move == excludedMove)
continue;
// At root obey the "searchmoves" option and skip moves not listed in Root
// Move List. As a consequence any illegal move is also skipped. In MultiPV
Tablebases root ranking This patch corrects both MultiPV behaviour and "go searchmoves" behaviour for tablebases. We change the logic of table base probing at root positions from filtering to ranking. The ranking code is much more straightforward than the current filtering code (this is a simplification), and also more versatile. If the root is a TB position, each root move is probed and assigned a TB score and a TB rank. The TB score is the Value to be displayed to the user for that move (unless the search finds a mate score), while the TB rank determines which moves should appear higher in a multi-pv search. In game play, the engine will always pick a move with the highest rank. Ranks run from -1000 to +1000: 901 to 1000 : TB win 900 : normally a TB win, in rare cases this could be a draw 1 to 899 : cursed TB wins 0 : draw -1 to -899 : blessed TB losses -900 : normally a TB loss, in rare cases this could be a draw -901 to -1000 : TB loss Normally all winning moves get rank 1000 (to let the search pick the best among them). The exception is if there has been a first repetition. In that case, moves are ranked strictly by DTZ so that the engine will play a move that lowers DTZ (and therefore cannot repeat the position a second time). Losing moves get rank -1000 unless they have relatively high DTZ, meaning they have some drawing chances. Those get ranks towards -901 (when they cross -900 the draw is certain). Closes https://github.com/official-stockfish/Stockfish/pull/1467 No functional change (without tablebases).
2018-04-18 10:38:38 -06:00
// mode we also skip PV moves which have been already searched and those
// of lower "TB rank" if we are in a TB root position.
if (rootNode && !std::count(thisThread->rootMoves.begin() + thisThread->pvIdx,
thisThread->rootMoves.begin() + thisThread->pvLast, move))
continue;
// Check for legality
if (!rootNode && !pos.legal(move))
continue;
ss->moveCount = ++moveCount;
if (rootNode && thisThread == Threads.main() && Time.elapsed() > 3000)
Eliminate ONE_PLY Simplification that eliminates ONE_PLY, based on a suggestion in the forum that support for fractional plies has never been used, and @mcostalba's openness to the idea of eliminating it. We lose a little bit of type safety by making Depth an integer, but in return we simplify the code in search.cpp quite significantly. No functional change ------------------------------------------ The argument favoring eliminating ONE_PLY: * The term “ONE_PLY” comes up in a lot of forum posts (474 to date) https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:relevance * There is occasionally a commit that breaks invariance of the code with respect to ONE_PLY https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:date/fishcooking/ZIPdYj6k0fk/KdNGcPWeBgAJ * To prevent such commits, there is a Travis CI hack that doubles ONE_PLY and rechecks bench * Sustaining ONE_PLY has, alas, not resulted in any improvements to the engine, despite many individuals testing many experiments over 5 years. The strongest argument in favor of preserving ONE_PLY comes from @locutus: “If we use par example ONE_PLY=256 the parameter space is increases by the factor 256. So it seems very unlikely that the optimal setting is in the subspace of ONE_PLY=1.” There is a strong theoretical impediment to fractional depth systems: the transposition table uses depth to determine when a stored result is good enough to supply an answer for a current search. If you have fractional depths, then different pathways to the position can be at fractionally different depths. In the end, there are three separate times when a proposal to remove ONE_PLY was defeated by the suggestion to “give it a few more months.” So… it seems like time to remove this distraction from the community. See the pull request here: https://github.com/official-stockfish/Stockfish/pull/2289
2019-09-28 14:27:23 -06:00
sync_cout << "info depth " << depth
<< " currmove " << UCI::move(move, pos.is_chess960())
<< " currmovenumber " << moveCount + thisThread->pvIdx << sync_endl;
if (PvNode)
(ss+1)->pv = nullptr;
Eliminate ONE_PLY Simplification that eliminates ONE_PLY, based on a suggestion in the forum that support for fractional plies has never been used, and @mcostalba's openness to the idea of eliminating it. We lose a little bit of type safety by making Depth an integer, but in return we simplify the code in search.cpp quite significantly. No functional change ------------------------------------------ The argument favoring eliminating ONE_PLY: * The term “ONE_PLY” comes up in a lot of forum posts (474 to date) https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:relevance * There is occasionally a commit that breaks invariance of the code with respect to ONE_PLY https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:date/fishcooking/ZIPdYj6k0fk/KdNGcPWeBgAJ * To prevent such commits, there is a Travis CI hack that doubles ONE_PLY and rechecks bench * Sustaining ONE_PLY has, alas, not resulted in any improvements to the engine, despite many individuals testing many experiments over 5 years. The strongest argument in favor of preserving ONE_PLY comes from @locutus: “If we use par example ONE_PLY=256 the parameter space is increases by the factor 256. So it seems very unlikely that the optimal setting is in the subspace of ONE_PLY=1.” There is a strong theoretical impediment to fractional depth systems: the transposition table uses depth to determine when a stored result is good enough to supply an answer for a current search. If you have fractional depths, then different pathways to the position can be at fractionally different depths. In the end, there are three separate times when a proposal to remove ONE_PLY was defeated by the suggestion to “give it a few more months.” So… it seems like time to remove this distraction from the community. See the pull request here: https://github.com/official-stockfish/Stockfish/pull/2289
2019-09-28 14:27:23 -06:00
extension = 0;
captureOrPromotion = pos.capture_or_promotion(move);
movedPiece = pos.moved_piece(move);
givesCheck = pos.gives_check(move);
// Calculate new depth for this move
newDepth = depth - 1;
// Step 13. Pruning at shallow depth (~200 Elo). Depth conditions are important for mate finding.
if ( !rootNode
&& pos.non_pawn_material(us)
Fix for incorrect VALUE_MATE_IN_MAX_PLY usage. Fixes #2533, fixes #2543, fixes #2423. the code that prevents false mate announcements depending on the TT state (GHI), incorrectly used VALUE_MATE_IN_MAX_PLY. The latter constant, however, also includes, counterintuitively, the TB win range. This patch fixes that, by restoring the behavior for TB win scores, while retaining the false mate correctness, and improving the mate finding ability. In particular no alse mates are announced with the poisened hash testcase ``` position fen 8/8/8/3k4/8/8/6K1/7R w - - 0 1 go depth 40 position fen 8/8/8/3k4/8/8/6K1/7R w - - 76 1 go depth 20 ucinewgame ``` mates are found with the testcases reported in #2543 ``` position fen 4k3/3pp3/8/8/8/8/2PPP3/4K3 w - - 0 1 setoption name Hash value 1024 go depth 55 ucinewgame ``` and ``` position fen 4k3/4p3/8/8/8/8/3PP3/4K3 w - - 0 1 setoption name Hash value 1024 go depth 45 ucinewgame ``` furthermore, on the mate finding benchmark (ChestUCI_23102018.epd), performance improves over master, roughly reaching performance with the false mate protection reverted ``` Analyzing 6566 mate positions for best and found mates: ----------------best ---------------found nodes master revert fixed master revert fixed 16000000 4233 4236 4235 5200 5201 5199 32000000 4583 4585 4585 5417 5424 5418 64000000 4852 4853 4855 5575 5584 5579 128000000 5071 5068 5066 5710 5720 5716 256000000 5280 5282 5279 5819 5827 5826 512000000 5471 5468 5468 5919 5935 5932 ``` On a testcase with TB enabled, progress is made consistently, contrary to master ``` setoption name SyzygyPath value ../../../syzygy/3-4-5/ setoption name Hash value 2048 position fen 1R6/3k4/8/K2p4/4n3/2P5/8/8 w - - 0 1 go depth 58 ucinewgame ``` The PR (prior to a rewrite for clarity) passed STC: LLR: 2.94 (-2.94,2.94) {-1.50,0.50} Total: 65405 W: 12454 L: 12384 D: 40567 Ptnml(0-2): 920, 7256, 16285, 7286, 944 http://tests.stockfishchess.org/tests/view/5e441a3be70d848499f63d15 passed LTC: LLR: 2.94 (-2.94,2.94) {-1.50,0.50} Total: 27096 W: 3477 L: 3413 D: 20206 Ptnml(0-2): 128, 2215, 8776, 2292, 122 http://tests.stockfishchess.org/tests/view/5e44e277e70d848499f63d63 The incorrectly named VALUE_MATE_IN_MAX_PLY and VALUE_MATED_IN_MAX_PLY were renamed into VALUE_TB_WIN_IN_MAX_PLY and VALUE_TB_LOSS_IN_MAX_PLY, and correclty defined VALUE_MATE_IN_MAX_PLY and VALUE_MATED_IN_MAX_PLY were introduced. One further (corner case) mistake using these constants was fixed (go mate X), which could lead to a premature return if X > MAX_PLY / 2, but TB were present. Thanks to @svivanov72 for one of the reports and help fixing the issue. closes https://github.com/official-stockfish/Stockfish/pull/2552 Bench: 4932981
2020-02-11 12:42:32 -07:00
&& bestValue > VALUE_TB_LOSS_IN_MAX_PLY)
{
// Skip quiet moves if movecount exceeds our FutilityMoveCount threshold
moveCountPruning = moveCount >= futility_move_count(improving, depth);
// Reduced depth of the next LMR search
int lmrDepth = std::max(newDepth - reduction(improving, depth, moveCount, rangeReduction > 2), 0);
if ( captureOrPromotion
|| givesCheck)
{
// Capture history based pruning when the move doesn't give check
if ( !givesCheck
&& lmrDepth < 1
&& captureHistory[movedPiece][to_sq(move)][type_of(pos.piece_on(to_sq(move)))] < 0)
continue;
// SEE based pruning
if (!pos.see_ge(move, Value(-218) * depth)) // (~25 Elo)
continue;
}
else
{
// Continuation history based pruning (~20 Elo)
if (lmrDepth < 5
&& (*contHist[0])[movedPiece][to_sq(move)]
+ (*contHist[1])[movedPiece][to_sq(move)]
+ (*contHist[3])[movedPiece][to_sq(move)] < -3000 * depth + 3000)
continue;
// Futility pruning: parent node (~5 Elo)
if ( !ss->inCheck
&& lmrDepth < 8
&& ss->staticEval + 172 + 145 * lmrDepth <= alpha)
continue;
// Prune moves with negative SEE (~20 Elo)
if (!pos.see_ge(move, Value(-21 * lmrDepth * lmrDepth - 21 * lmrDepth)))
continue;
}
}
// Step 14. Extensions (~75 Elo)
2008-08-31 23:59:13 -06:00
// Singular extension search (~70 Elo). If all moves but one fail low on a
// search of (alpha-s, beta-s), and just one fails high on (alpha, beta),
// then that move is singular and should be extended. To verify this we do
// a reduced search on all the other moves but the ttMove and if the
// result is lower than ttValue minus a margin, then we will extend the ttMove.
if ( !rootNode
&& depth >= 7
&& move == ttMove
&& !excludedMove // Avoid recursive singular search
/* && ttValue != VALUE_NONE Already implicit in the next condition */
&& abs(ttValue) < VALUE_KNOWN_WIN
&& (tte->bound() & BOUND_LOWER)
&& tte->depth() >= depth - 3)
{
Value singularBeta = ttValue - 3 * depth;
Depth singularDepth = (depth - 1) / 2;
ss->excludedMove = move;
value = search<NonPV>(pos, ss, singularBeta - 1, singularBeta, singularDepth, cutNode);
ss->excludedMove = MOVE_NONE;
if (value < singularBeta)
{
Eliminate ONE_PLY Simplification that eliminates ONE_PLY, based on a suggestion in the forum that support for fractional plies has never been used, and @mcostalba's openness to the idea of eliminating it. We lose a little bit of type safety by making Depth an integer, but in return we simplify the code in search.cpp quite significantly. No functional change ------------------------------------------ The argument favoring eliminating ONE_PLY: * The term “ONE_PLY” comes up in a lot of forum posts (474 to date) https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:relevance * There is occasionally a commit that breaks invariance of the code with respect to ONE_PLY https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:date/fishcooking/ZIPdYj6k0fk/KdNGcPWeBgAJ * To prevent such commits, there is a Travis CI hack that doubles ONE_PLY and rechecks bench * Sustaining ONE_PLY has, alas, not resulted in any improvements to the engine, despite many individuals testing many experiments over 5 years. The strongest argument in favor of preserving ONE_PLY comes from @locutus: “If we use par example ONE_PLY=256 the parameter space is increases by the factor 256. So it seems very unlikely that the optimal setting is in the subspace of ONE_PLY=1.” There is a strong theoretical impediment to fractional depth systems: the transposition table uses depth to determine when a stored result is good enough to supply an answer for a current search. If you have fractional depths, then different pathways to the position can be at fractionally different depths. In the end, there are three separate times when a proposal to remove ONE_PLY was defeated by the suggestion to “give it a few more months.” So… it seems like time to remove this distraction from the community. See the pull request here: https://github.com/official-stockfish/Stockfish/pull/2289
2019-09-28 14:27:23 -06:00
extension = 1;
singularQuietLMR = !ttCapture;
Detect search explosions This patch detects some search explosions (due to double extensions in search.cpp) which can happen in some pathological positions, and takes measures to ensure progress in search even for these pathological situations. While a small number of double extensions can be useful during search (for example to resolve a tactical sequence), a sustained regime of double extensions leads to search explosion and a non-finishing search. See the discussion in https://github.com/official-stockfish/Stockfish/pull/3544 and the issue https://github.com/official-stockfish/Stockfish/issues/3532 . The implemented algorithm is the following: a) at each node during search, store the current depth in the stack. Double extensions are by definition levels of the stack where the depth at ply N is strictly higher than depth at ply N-1. b) during search, calculate for each thread a running average of the number of double extensions in the last 4096 visited nodes. c) if one thread has more than 2% of double extensions for a sustained period of time (6 millions consecutive nodes, or about 4 seconds on my iMac), we decide that this thread is in an explosion state and we calm down this thread by preventing it to do any double extension for the next 6 millions nodes. To calculate the running averages, we also introduced a auxiliary class generalizing the computations of ttHitAverage variable we already had in code. The implementation uses an exponential moving average of period 4096 and resolution 1/1024, and all computations are done with integers for efficiency. ----------- Example where the patch solves a search explosion: ``` ./stockfish ucinewgame position fen 8/Pk6/8/1p6/8/P1K5/8/6B1 w - - 37 130 go infinite ``` This algorithm does not affect search in normal, non-pathological positions. We verified, for instance, that the usual bench is unchanged up to depth 20 at least, and that the node numbers are unchanged for a search of the starting position at depth 32. ------------- See https://github.com/official-stockfish/Stockfish/pull/3714 Bench: 5575265
2021-09-23 15:19:06 -06:00
// Avoid search explosion by limiting the number of double extensions
if ( !PvNode
&& value < singularBeta - 75
&& ss->doubleExtensions <= 6)
extension = 2;
}
// Multi-cut pruning
// Our ttMove is assumed to fail high, and now we failed high also on a reduced
// search without the ttMove. So we assume this expected Cut-node is not singular,
// that multiple moves fail high, and we can prune the whole subtree by returning
// a soft bound.
else if (singularBeta >= beta)
return singularBeta;
// If the eval of ttMove is greater than beta, we reduce it (negative extension)
else if (ttValue >= beta)
extension = -2;
}
// Capture extensions for PvNodes and cutNodes
else if ( (PvNode || cutNode)
&& captureOrPromotion
&& moveCount != 1)
extension = 1;
// Check extensions
else if ( givesCheck
&& depth > 6
&& abs(ss->staticEval) > 100)
extension = 1;
// Quiet ttMove extensions
else if ( PvNode
&& move == ttMove
&& move == ss->killers[0]
&& (*contHist[0])[movedPiece][to_sq(move)] >= 10000)
extension = 1;
// Add extension to new depth
newDepth += extension;
ss->doubleExtensions = (ss-1)->doubleExtensions + (extension == 2);
2008-08-31 23:59:13 -06:00
// Speculative prefetch as early as possible
prefetch(TT.first_entry(pos.key_after(move)));
// Update the current move (this must be done after singular extension search)
ss->currentMove = move;
ss->continuationHistory = &thisThread->continuationHistory[ss->inCheck]
[captureOrPromotion]
[movedPiece]
[to_sq(move)];
// Step 15. Make the move
pos.do_move(move, st, givesCheck);
// Step 16. Late moves reduction / extension (LMR, ~200 Elo)
// We use various heuristics for the sons of a node after the first son has
// been searched. In general we would like to reduce them, but there are many
// cases where we extend a son if it has good chances to be "interesting".
Eliminate ONE_PLY Simplification that eliminates ONE_PLY, based on a suggestion in the forum that support for fractional plies has never been used, and @mcostalba's openness to the idea of eliminating it. We lose a little bit of type safety by making Depth an integer, but in return we simplify the code in search.cpp quite significantly. No functional change ------------------------------------------ The argument favoring eliminating ONE_PLY: * The term “ONE_PLY” comes up in a lot of forum posts (474 to date) https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:relevance * There is occasionally a commit that breaks invariance of the code with respect to ONE_PLY https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:date/fishcooking/ZIPdYj6k0fk/KdNGcPWeBgAJ * To prevent such commits, there is a Travis CI hack that doubles ONE_PLY and rechecks bench * Sustaining ONE_PLY has, alas, not resulted in any improvements to the engine, despite many individuals testing many experiments over 5 years. The strongest argument in favor of preserving ONE_PLY comes from @locutus: “If we use par example ONE_PLY=256 the parameter space is increases by the factor 256. So it seems very unlikely that the optimal setting is in the subspace of ONE_PLY=1.” There is a strong theoretical impediment to fractional depth systems: the transposition table uses depth to determine when a stored result is good enough to supply an answer for a current search. If you have fractional depths, then different pathways to the position can be at fractionally different depths. In the end, there are three separate times when a proposal to remove ONE_PLY was defeated by the suggestion to “give it a few more months.” So… it seems like time to remove this distraction from the community. See the pull request here: https://github.com/official-stockfish/Stockfish/pull/2289
2019-09-28 14:27:23 -06:00
if ( depth >= 3
&& moveCount > 1 + 2 * rootNode
&& ( !ss->ttPv
|| !captureOrPromotion
|| (cutNode && (ss-1)->moveCount > 1)))
{
Depth r = reduction(improving, depth, moveCount, rangeReduction > 2);
// Decrease reduction if on the PV (~2 Elo)
if ( PvNode
&& bestMoveCount <= 3)
r--;
// Decrease reduction if position is or has been on the PV
// and node is not likely to fail low. (~3 Elo)
if ( ss->ttPv
&& !likelyFailLow)
Eliminate ONE_PLY Simplification that eliminates ONE_PLY, based on a suggestion in the forum that support for fractional plies has never been used, and @mcostalba's openness to the idea of eliminating it. We lose a little bit of type safety by making Depth an integer, but in return we simplify the code in search.cpp quite significantly. No functional change ------------------------------------------ The argument favoring eliminating ONE_PLY: * The term “ONE_PLY” comes up in a lot of forum posts (474 to date) https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:relevance * There is occasionally a commit that breaks invariance of the code with respect to ONE_PLY https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:date/fishcooking/ZIPdYj6k0fk/KdNGcPWeBgAJ * To prevent such commits, there is a Travis CI hack that doubles ONE_PLY and rechecks bench * Sustaining ONE_PLY has, alas, not resulted in any improvements to the engine, despite many individuals testing many experiments over 5 years. The strongest argument in favor of preserving ONE_PLY comes from @locutus: “If we use par example ONE_PLY=256 the parameter space is increases by the factor 256. So it seems very unlikely that the optimal setting is in the subspace of ONE_PLY=1.” There is a strong theoretical impediment to fractional depth systems: the transposition table uses depth to determine when a stored result is good enough to supply an answer for a current search. If you have fractional depths, then different pathways to the position can be at fractionally different depths. In the end, there are three separate times when a proposal to remove ONE_PLY was defeated by the suggestion to “give it a few more months.” So… it seems like time to remove this distraction from the community. See the pull request here: https://github.com/official-stockfish/Stockfish/pull/2289
2019-09-28 14:27:23 -06:00
r -= 2;
// Increase reduction at root and non-PV nodes when the best move does not change frequently
if ( (rootNode || !PvNode)
&& thisThread->bestMoveChanges <= 2)
r++;
// Decrease reduction if opponent's move count is high (~1 Elo)
if ((ss-1)->moveCount > 13)
Eliminate ONE_PLY Simplification that eliminates ONE_PLY, based on a suggestion in the forum that support for fractional plies has never been used, and @mcostalba's openness to the idea of eliminating it. We lose a little bit of type safety by making Depth an integer, but in return we simplify the code in search.cpp quite significantly. No functional change ------------------------------------------ The argument favoring eliminating ONE_PLY: * The term “ONE_PLY” comes up in a lot of forum posts (474 to date) https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:relevance * There is occasionally a commit that breaks invariance of the code with respect to ONE_PLY https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:date/fishcooking/ZIPdYj6k0fk/KdNGcPWeBgAJ * To prevent such commits, there is a Travis CI hack that doubles ONE_PLY and rechecks bench * Sustaining ONE_PLY has, alas, not resulted in any improvements to the engine, despite many individuals testing many experiments over 5 years. The strongest argument in favor of preserving ONE_PLY comes from @locutus: “If we use par example ONE_PLY=256 the parameter space is increases by the factor 256. So it seems very unlikely that the optimal setting is in the subspace of ONE_PLY=1.” There is a strong theoretical impediment to fractional depth systems: the transposition table uses depth to determine when a stored result is good enough to supply an answer for a current search. If you have fractional depths, then different pathways to the position can be at fractionally different depths. In the end, there are three separate times when a proposal to remove ONE_PLY was defeated by the suggestion to “give it a few more months.” So… it seems like time to remove this distraction from the community. See the pull request here: https://github.com/official-stockfish/Stockfish/pull/2289
2019-09-28 14:27:23 -06:00
r--;
// Decrease reduction if ttMove has been singularly extended (~1 Elo)
if (singularQuietLMR)
r--;
// Increase reduction for cut nodes (~3 Elo)
if (cutNode && move != ss->killers[0])
r += 2;
// Increase reduction if ttMove is a capture (~3 Elo)
if (ttCapture)
r++;
ss->statScore = thisThread->mainHistory[us][from_to(move)]
+ (*contHist[0])[movedPiece][to_sq(move)]
+ (*contHist[1])[movedPiece][to_sq(move)]
+ (*contHist[3])[movedPiece][to_sq(move)]
- 4923;
// Decrease/increase reduction for moves with a good/bad history (~30 Elo)
r -= ss->statScore / 14721;
// In general we want to cap the LMR depth search at newDepth. But if reductions
// are really negative and movecount is low, we allow this move to be searched
// deeper than the first move (this may lead to hidden double extensions).
int deeper = r >= -1 ? 0
: moveCount <= 5 ? 2
: PvNode && depth > 6 ? 1
: cutNode && moveCount <= 7 ? 1
: 0;
Detect search explosions This patch detects some search explosions (due to double extensions in search.cpp) which can happen in some pathological positions, and takes measures to ensure progress in search even for these pathological situations. While a small number of double extensions can be useful during search (for example to resolve a tactical sequence), a sustained regime of double extensions leads to search explosion and a non-finishing search. See the discussion in https://github.com/official-stockfish/Stockfish/pull/3544 and the issue https://github.com/official-stockfish/Stockfish/issues/3532 . The implemented algorithm is the following: a) at each node during search, store the current depth in the stack. Double extensions are by definition levels of the stack where the depth at ply N is strictly higher than depth at ply N-1. b) during search, calculate for each thread a running average of the number of double extensions in the last 4096 visited nodes. c) if one thread has more than 2% of double extensions for a sustained period of time (6 millions consecutive nodes, or about 4 seconds on my iMac), we decide that this thread is in an explosion state and we calm down this thread by preventing it to do any double extension for the next 6 millions nodes. To calculate the running averages, we also introduced a auxiliary class generalizing the computations of ttHitAverage variable we already had in code. The implementation uses an exponential moving average of period 4096 and resolution 1/1024, and all computations are done with integers for efficiency. ----------- Example where the patch solves a search explosion: ``` ./stockfish ucinewgame position fen 8/Pk6/8/1p6/8/P1K5/8/6B1 w - - 37 130 go infinite ``` This algorithm does not affect search in normal, non-pathological positions. We verified, for instance, that the usual bench is unchanged up to depth 20 at least, and that the node numbers are unchanged for a search of the starting position at depth 32. ------------- See https://github.com/official-stockfish/Stockfish/pull/3714 Bench: 5575265
2021-09-23 15:19:06 -06:00
Depth d = std::clamp(newDepth - r, 1, newDepth + deeper);
value = -search<NonPV>(pos, ss+1, -(alpha+1), -alpha, d, true);
// Range reductions (~3 Elo)
if (ss->staticEval - value < 30 && depth > 7)
rangeReduction++;
// If the son is reduced and fails high it will be re-searched at full depth
doFullDepthSearch = value > alpha && d < newDepth;
didLMR = true;
}
else
{
doFullDepthSearch = !PvNode || moveCount > 1;
didLMR = false;
}
// Step 17. Full depth search when LMR is skipped or fails high
if (doFullDepthSearch)
{
value = -search<NonPV>(pos, ss+1, -(alpha+1), -alpha, newDepth, !cutNode);
// If the move passed LMR update its stats
if (didLMR && !captureOrPromotion)
{
int bonus = value > alpha ? stat_bonus(newDepth)
: -stat_bonus(newDepth);
update_continuation_histories(ss, movedPiece, to_sq(move), bonus);
}
}
// For PV nodes only, do a full PV search on the first move or after a fail
// high (in the latter case search only if value < beta), otherwise let the
// parent node fail low with value <= alpha and try another move.
if (PvNode && (moveCount == 1 || (value > alpha && (rootNode || value < beta))))
{
(ss+1)->pv = pv;
(ss+1)->pv[0] = MOVE_NONE;
value = -search<PV>(pos, ss+1, -beta, -alpha,
std::min(maxNextDepth, newDepth), false);
}
// Step 18. Undo move
pos.undo_move(move);
2008-08-31 23:59:13 -06:00
assert(value > -VALUE_INFINITE && value < VALUE_INFINITE);
// Step 19. Check for a new best move
// Finished searching the move. If a stop occurred, the return value of
// the search cannot be trusted, and we return immediately without
// updating best move, PV and TT.
if (Threads.stop.load(std::memory_order_relaxed))
return VALUE_ZERO;
if (rootNode)
{
RootMove& rm = *std::find(thisThread->rootMoves.begin(),
thisThread->rootMoves.end(), move);
// PV move or new best move?
if (moveCount == 1 || value > alpha)
{
rm.score = value;
rm.selDepth = thisThread->selDepth;
rm.pv.resize(1);
assert((ss+1)->pv);
for (Move* m = (ss+1)->pv; *m != MOVE_NONE; ++m)
rm.pv.push_back(*m);
// We record how often the best move has been changed in each iteration.
// This information is used for time management and LMR. In MultiPV mode,
// we must take care to only do this for the first PV line.
if ( moveCount > 1
&& !thisThread->pvIdx)
++thisThread->bestMoveChanges;
}
else
// All other moves but the PV are set to the lowest value: this
// is not a problem when sorting because the sort is stable and the
// move position in the list is preserved - just the PV is pushed up.
rm.score = -VALUE_INFINITE;
}
if (value > bestValue)
{
bestValue = value;
if (value > alpha)
{
bestMove = move;
if (PvNode && !rootNode) // Update pv even in fail-high case
update_pv(ss->pv, move, (ss+1)->pv);
if (PvNode && value < beta) // Update alpha! Always alpha < beta
{
alpha = value;
bestMoveCount++;
}
else
{
assert(value >= beta); // Fail high
break;
}
}
}
// If the move is worse than some previously searched move, remember it to update its stats later
if (move != bestMove)
{
if (captureOrPromotion && captureCount < 32)
capturesSearched[captureCount++] = move;
else if (!captureOrPromotion && quietCount < 64)
quietsSearched[quietCount++] = move;
}
2008-08-31 23:59:13 -06:00
}
// The following condition would detect a stop only after move loop has been
// completed. But in this case bestValue is valid because we have fully
// searched our subtree, and we can anyhow save the result in TT.
/*
if (Threads.stop)
return VALUE_DRAW;
*/
// Step 20. Check for mate and stalemate
// All legal moves have been searched and if there are no legal moves, it
// must be a mate or a stalemate. If we are in a singular extension search then
// return a fail low score.
assert(moveCount || !ss->inCheck || excludedMove || !MoveList<LEGAL>(pos).size());
if (!moveCount)
bestValue = excludedMove ? alpha :
ss->inCheck ? mated_in(ss->ply)
: VALUE_DRAW;
// If there is a move which produces search value greater than alpha we update stats of searched moves
else if (bestMove)
update_all_stats(pos, ss, bestMove, bestValue, beta, prevSq,
Revert 5 recent patches Revert 5 patches which were merged, but lead to a regression test that showed negative Elo gain: http://tests.stockfishchess.org/tests/view/5e307251ab2d69d58394fdb9 This was discussed in depth in: https://github.com/official-stockfish/Stockfish/issues/2531 Each patch was removed and tested as a simplification, full list below, and the whole combo as well. After the revert the regression test showed a neutral result: http://tests.stockfishchess.org/tests/view/5e334851708b13464ceea33c As a result of this experience, the SPRT testing bounds will be made more strict. Reverted patches: 1 Dynamic Complexity 6d0eabd5fe2961551477820ab7619e2c31e01ffd : STC 10+0.1 https://tests.stockfishchess.org/tests/view/5e31fcacec661e2e6a340d08 : LLR: 2.97 (-2.94,2.94) {-1.50,0.50} Total: 38130 W: 7326 L: 7189 D: 23615 Ptnml(0-2): 677, 4346, 8843, 4545, 646 LTC 60+0.6 https://tests.stockfishchess.org/tests/view/5e32c18fec661e2e6a340d73 : LLR: 2.94 (-2.94,2.94) {-1.50,0.50} Total: 38675 W: 4941 L: 4866 D: 28868 Ptnml(0-2): 270, 3556, 11429, 3584, 291 3 More bonus for bestMoves on past PV nodes 71e0b5385e2717679a57c6b77d8c7ac5fff3b89f : STC 10+0.1 https://tests.stockfishchess.org/tests/view/5e31fe93ec661e2e6a340d10 : LLR: 2.95 (-2.94,2.94) {-1.50,0.50} Total: 46100 W: 8853 L: 8727 D: 28520 Ptnml(0-2): 796, 5297, 10749, 5387, 813 LTC 60+0.6 https://tests.stockfishchess.org/tests/view/5e32c187ec661e2e6a340d71 : LLR: 2.96 (-2.94,2.94) {-1.50,0.50} Total: 16920 W: 2161 L: 2055 D: 12704 Ptnml(0-2): 115, 1498, 5006, 1569, 130 4 Tweak Restricted Piece Bonus 0ae00454ba6928d181b46103e5c83e6d58fcebe5 : STC 10+0.1 https://tests.stockfishchess.org/tests/view/5e31fefaec661e2e6a340d15 : LLR: 2.94 (-2.94,2.94) {-1.50,0.50} Total: 88328 W: 17060 L: 16997 D: 54271 Ptnml(0-2): 1536, 10446, 20169, 10422, 1581 LTC 60+0.6 https://tests.stockfishchess.org/tests/view/5e32c17aec661e2e6a340d6f : LLR: 2.95 (-2.94,2.94) {-1.50,0.50} Total: 34784 W: 4551 L: 4466 D: 25767 Ptnml(0-2): 255, 3279, 10061, 3345, 262 5 History update for pruned captures 01b6088af39902001d2d6844561b6a2faa549282 : STC 10+0.1 https://tests.stockfishchess.org/tests/view/5e31ff5eec661e2e6a340d1a : LLR: 2.94 (-2.94,2.94) {-1.50,0.50} Total: 29541 W: 5735 L: 5588 D: 18218 Ptnml(0-2): 483, 3445, 6820, 3469, 545 LTC 60+0.6 https://tests.stockfishchess.org/tests/view/5e32c196ec661e2e6a340d75 : LLR: 2.94 (-2.94,2.94) {-1.50,0.50} Total: 22177 W: 2854 L: 2757 D: 16566 Ptnml(0-2): 143, 2005, 6555, 2055, 164 6 Tweak trapped rook penalty 18fc21eba0368fd5e3c4c4b8ee1000c9ac445425 : STC 10+0.1 https://tests.stockfishchess.org/tests/view/5e31ffb1ec661e2e6a340d1c : LLR: 2.95 (-2.94,2.94) {-1.50,0.50} Total: 24476 W: 4727 L: 4569 D: 15180 Ptnml(0-2): 390, 2834, 5659, 2933, 417 LTC 60+0.6 https://tests.stockfishchess.org/tests/view/5e32c19eec661e2e6a340d77 : LLR: 2.95 (-2.94,2.94) {-1.50,0.50} Total: 97332 W: 12492 L: 12466 D: 72374 Ptnml(0-2): 690, 9107, 28738, 9034, 720 All 5 as one simplification : LTC 60+0.6 https://tests.stockfishchess.org/tests/view/5e334098708b13464ceea330 : LLR: 2.94 (-2.94,2.94) {-1.50,0.50} Total: 7829 W: 1079 L: 964 D: 5786 Ptnml(0-2): 52, 690, 2281, 781, 65 Bench: 5153165
2020-01-30 13:44:04 -07:00
quietsSearched, quietCount, capturesSearched, captureCount, depth);
// Bonus for prior countermove that caused the fail low
Eliminate ONE_PLY Simplification that eliminates ONE_PLY, based on a suggestion in the forum that support for fractional plies has never been used, and @mcostalba's openness to the idea of eliminating it. We lose a little bit of type safety by making Depth an integer, but in return we simplify the code in search.cpp quite significantly. No functional change ------------------------------------------ The argument favoring eliminating ONE_PLY: * The term “ONE_PLY” comes up in a lot of forum posts (474 to date) https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:relevance * There is occasionally a commit that breaks invariance of the code with respect to ONE_PLY https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:date/fishcooking/ZIPdYj6k0fk/KdNGcPWeBgAJ * To prevent such commits, there is a Travis CI hack that doubles ONE_PLY and rechecks bench * Sustaining ONE_PLY has, alas, not resulted in any improvements to the engine, despite many individuals testing many experiments over 5 years. The strongest argument in favor of preserving ONE_PLY comes from @locutus: “If we use par example ONE_PLY=256 the parameter space is increases by the factor 256. So it seems very unlikely that the optimal setting is in the subspace of ONE_PLY=1.” There is a strong theoretical impediment to fractional depth systems: the transposition table uses depth to determine when a stored result is good enough to supply an answer for a current search. If you have fractional depths, then different pathways to the position can be at fractionally different depths. In the end, there are three separate times when a proposal to remove ONE_PLY was defeated by the suggestion to “give it a few more months.” So… it seems like time to remove this distraction from the community. See the pull request here: https://github.com/official-stockfish/Stockfish/pull/2289
2019-09-28 14:27:23 -06:00
else if ( (depth >= 3 || PvNode)
&& !priorCapture)
update_continuation_histories(ss-1, pos.piece_on(prevSq), prevSq, stat_bonus(depth) * (1 + (PvNode || cutNode)));
if (PvNode)
bestValue = std::min(bestValue, maxValue);
// If no good move is found and the previous position was ttPv, then the previous
// opponent move is probably good and the new position is added to the search tree.
if (bestValue <= alpha)
ss->ttPv = ss->ttPv || ((ss-1)->ttPv && depth > 3);
// Otherwise, a counter move has been found and if the position is the last leaf
// in the search tree, remove the position from the search tree.
else if (depth > 3)
ss->ttPv = ss->ttPv && (ss+1)->ttPv;
// Write gathered information in transposition table
if (!excludedMove && !(rootNode && thisThread->pvIdx))
tte->save(posKey, value_to_tt(bestValue, ss->ply), ss->ttPv,
bestValue >= beta ? BOUND_LOWER :
PvNode && bestMove ? BOUND_EXACT : BOUND_UPPER,
depth, bestMove, ss->staticEval);
assert(bestValue > -VALUE_INFINITE && bestValue < VALUE_INFINITE);
2008-08-31 23:59:13 -06:00
return bestValue;
}
// qsearch() is the quiescence search function, which is called by the main search
// function with zero depth, or recursively with further decreasing depth per call.
template <NodeType nodeType>
Value qsearch(Position& pos, Stack* ss, Value alpha, Value beta, Depth depth) {
2008-08-31 23:59:13 -06:00
static_assert(nodeType != Root);
constexpr bool PvNode = nodeType == PV;
assert(alpha >= -VALUE_INFINITE && alpha < beta && beta <= VALUE_INFINITE);
assert(PvNode || (alpha == beta - 1));
Eliminate ONE_PLY Simplification that eliminates ONE_PLY, based on a suggestion in the forum that support for fractional plies has never been used, and @mcostalba's openness to the idea of eliminating it. We lose a little bit of type safety by making Depth an integer, but in return we simplify the code in search.cpp quite significantly. No functional change ------------------------------------------ The argument favoring eliminating ONE_PLY: * The term “ONE_PLY” comes up in a lot of forum posts (474 to date) https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:relevance * There is occasionally a commit that breaks invariance of the code with respect to ONE_PLY https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:date/fishcooking/ZIPdYj6k0fk/KdNGcPWeBgAJ * To prevent such commits, there is a Travis CI hack that doubles ONE_PLY and rechecks bench * Sustaining ONE_PLY has, alas, not resulted in any improvements to the engine, despite many individuals testing many experiments over 5 years. The strongest argument in favor of preserving ONE_PLY comes from @locutus: “If we use par example ONE_PLY=256 the parameter space is increases by the factor 256. So it seems very unlikely that the optimal setting is in the subspace of ONE_PLY=1.” There is a strong theoretical impediment to fractional depth systems: the transposition table uses depth to determine when a stored result is good enough to supply an answer for a current search. If you have fractional depths, then different pathways to the position can be at fractionally different depths. In the end, there are three separate times when a proposal to remove ONE_PLY was defeated by the suggestion to “give it a few more months.” So… it seems like time to remove this distraction from the community. See the pull request here: https://github.com/official-stockfish/Stockfish/pull/2289
2019-09-28 14:27:23 -06:00
assert(depth <= 0);
2008-08-31 23:59:13 -06:00
Move pv[MAX_PLY+1];
StateInfo st;
ASSERT_ALIGNED(&st, Eval::NNUE::CacheLineSize);
TTEntry* tte;
Key posKey;
Move ttMove, move, bestMove;
Depth ttDepth;
Value bestValue, value, ttValue, futilityValue, futilityBase, oldAlpha;
bool pvHit, givesCheck, captureOrPromotion;
int moveCount;
if (PvNode)
{
oldAlpha = alpha; // To flag BOUND_EXACT when eval above alpha and no available moves
(ss+1)->pv = pv;
ss->pv[0] = MOVE_NONE;
}
Thread* thisThread = pos.this_thread();
bestMove = MOVE_NONE;
ss->inCheck = pos.checkers();
moveCount = 0;
2008-08-31 23:59:13 -06:00
// Check for an immediate draw or maximum ply reached
if ( pos.is_draw(ss->ply)
|| ss->ply >= MAX_PLY)
return (ss->ply >= MAX_PLY && !ss->inCheck) ? evaluate(pos) : VALUE_DRAW;
assert(0 <= ss->ply && ss->ply < MAX_PLY);
// Decide whether or not to include checks: this fixes also the type of
// TT entry depth that we are going to use. Note that in qsearch we use
// only two types of depth in TT: DEPTH_QS_CHECKS or DEPTH_QS_NO_CHECKS.
ttDepth = ss->inCheck || depth >= DEPTH_QS_CHECKS ? DEPTH_QS_CHECKS
: DEPTH_QS_NO_CHECKS;
// Transposition table lookup
posKey = pos.key();
tte = TT.probe(posKey, ss->ttHit);
ttValue = ss->ttHit ? value_from_tt(tte->value(), ss->ply, pos.rule50_count()) : VALUE_NONE;
ttMove = ss->ttHit ? tte->move() : MOVE_NONE;
pvHit = ss->ttHit && tte->is_pv();
if ( !PvNode
&& ss->ttHit
&& tte->depth() >= ttDepth
&& ttValue != VALUE_NONE // Only in case of TT access race
&& (ttValue >= beta ? (tte->bound() & BOUND_LOWER)
: (tte->bound() & BOUND_UPPER)))
return ttValue;
// Evaluate the position statically
if (ss->inCheck)
{
ss->staticEval = VALUE_NONE;
bestValue = futilityBase = -VALUE_INFINITE;
}
else
{
if (ss->ttHit)
{
// Never assume anything about values stored in TT
if ((ss->staticEval = bestValue = tte->eval()) == VALUE_NONE)
ss->staticEval = bestValue = evaluate(pos);
// Can ttValue be used as a better position evaluation?
if ( ttValue != VALUE_NONE
&& (tte->bound() & (ttValue > bestValue ? BOUND_LOWER : BOUND_UPPER)))
bestValue = ttValue;
}
else
// In case of null move search use previous static eval with a different sign
ss->staticEval = bestValue =
(ss-1)->currentMove != MOVE_NULL ? evaluate(pos)
: -(ss-1)->staticEval;
// Stand pat. Return immediately if static value is at least beta
if (bestValue >= beta)
{
// Save gathered info in transposition table
if (!ss->ttHit)
tte->save(posKey, value_to_tt(bestValue, ss->ply), false, BOUND_LOWER,
DEPTH_NONE, MOVE_NONE, ss->staticEval);
return bestValue;
}
if (PvNode && bestValue > alpha)
alpha = bestValue;
futilityBase = bestValue + 155;
}
const PieceToHistory* contHist[] = { (ss-1)->continuationHistory, (ss-2)->continuationHistory,
nullptr , (ss-4)->continuationHistory,
nullptr , (ss-6)->continuationHistory };
2008-08-31 23:59:13 -06:00
// Initialize a MovePicker object for the current position, and prepare
// to search the moves. Because the depth is <= 0 here, only captures,
// queen promotions, and other checks (only if depth >= DEPTH_QS_CHECKS)
// will be generated.
MovePicker mp(pos, ttMove, depth, &thisThread->mainHistory,
&thisThread->captureHistory,
contHist,
to_sq((ss-1)->currentMove));
2008-08-31 23:59:13 -06:00
// Loop through the moves until no moves remain or a beta cutoff occurs
while ((move = mp.next_move()) != MOVE_NONE)
{
assert(is_ok(move));
// Check for legality
if (!pos.legal(move))
continue;
givesCheck = pos.gives_check(move);
captureOrPromotion = pos.capture_or_promotion(move);
moveCount++;
// Futility pruning and moveCount pruning
if ( bestValue > VALUE_TB_LOSS_IN_MAX_PLY
&& !givesCheck
&& futilityBase > -VALUE_KNOWN_WIN
&& type_of(move) != PROMOTION)
{
if (moveCount > 2)
continue;
futilityValue = futilityBase + PieceValue[EG][pos.piece_on(to_sq(move))];
if (futilityValue <= alpha)
{
bestValue = std::max(bestValue, futilityValue);
continue;
}
if (futilityBase <= alpha && !pos.see_ge(move, VALUE_ZERO + 1))
{
bestValue = std::max(bestValue, futilityBase);
continue;
}
2008-08-31 23:59:13 -06:00
}
// Do not search moves with negative SEE values
if ( bestValue > VALUE_TB_LOSS_IN_MAX_PLY
&& !pos.see_ge(move))
continue;
2008-08-31 23:59:13 -06:00
// Speculative prefetch as early as possible
prefetch(TT.first_entry(pos.key_after(move)));
ss->currentMove = move;
ss->continuationHistory = &thisThread->continuationHistory[ss->inCheck]
[captureOrPromotion]
[pos.moved_piece(move)]
[to_sq(move)];
// Continuation history based pruning
if ( !captureOrPromotion
&& bestValue > VALUE_TB_LOSS_IN_MAX_PLY
&& (*contHist[0])[pos.moved_piece(move)][to_sq(move)] < CounterMovePruneThreshold
&& (*contHist[1])[pos.moved_piece(move)][to_sq(move)] < CounterMovePruneThreshold)
continue;
// Make and search the move
pos.do_move(move, st, givesCheck);
value = -qsearch<nodeType>(pos, ss+1, -beta, -alpha, depth - 1);
pos.undo_move(move);
2008-08-31 23:59:13 -06:00
assert(value > -VALUE_INFINITE && value < VALUE_INFINITE);
// Check for a new best move
if (value > bestValue)
{
bestValue = value;
if (value > alpha)
{
bestMove = move;
if (PvNode) // Update pv even in fail-high case
update_pv(ss->pv, move, (ss+1)->pv);
if (PvNode && value < beta) // Update alpha here!
alpha = value;
else
break; // Fail high
}
}
2008-08-31 23:59:13 -06:00
}
// All legal moves have been searched. A special case: if we're in check
// and no legal moves were found, it is checkmate.
if (ss->inCheck && bestValue == -VALUE_INFINITE)
{
assert(!MoveList<LEGAL>(pos).size());
return mated_in(ss->ply); // Plies to mate from the root
}
2008-08-31 23:59:13 -06:00
// Save gathered info in transposition table
tte->save(posKey, value_to_tt(bestValue, ss->ply), pvHit,
bestValue >= beta ? BOUND_LOWER :
PvNode && bestValue > oldAlpha ? BOUND_EXACT : BOUND_UPPER,
ttDepth, bestMove, ss->staticEval);
assert(bestValue > -VALUE_INFINITE && bestValue < VALUE_INFINITE);
2008-08-31 23:59:13 -06:00
return bestValue;
}
Fix for incorrect VALUE_MATE_IN_MAX_PLY usage. Fixes #2533, fixes #2543, fixes #2423. the code that prevents false mate announcements depending on the TT state (GHI), incorrectly used VALUE_MATE_IN_MAX_PLY. The latter constant, however, also includes, counterintuitively, the TB win range. This patch fixes that, by restoring the behavior for TB win scores, while retaining the false mate correctness, and improving the mate finding ability. In particular no alse mates are announced with the poisened hash testcase ``` position fen 8/8/8/3k4/8/8/6K1/7R w - - 0 1 go depth 40 position fen 8/8/8/3k4/8/8/6K1/7R w - - 76 1 go depth 20 ucinewgame ``` mates are found with the testcases reported in #2543 ``` position fen 4k3/3pp3/8/8/8/8/2PPP3/4K3 w - - 0 1 setoption name Hash value 1024 go depth 55 ucinewgame ``` and ``` position fen 4k3/4p3/8/8/8/8/3PP3/4K3 w - - 0 1 setoption name Hash value 1024 go depth 45 ucinewgame ``` furthermore, on the mate finding benchmark (ChestUCI_23102018.epd), performance improves over master, roughly reaching performance with the false mate protection reverted ``` Analyzing 6566 mate positions for best and found mates: ----------------best ---------------found nodes master revert fixed master revert fixed 16000000 4233 4236 4235 5200 5201 5199 32000000 4583 4585 4585 5417 5424 5418 64000000 4852 4853 4855 5575 5584 5579 128000000 5071 5068 5066 5710 5720 5716 256000000 5280 5282 5279 5819 5827 5826 512000000 5471 5468 5468 5919 5935 5932 ``` On a testcase with TB enabled, progress is made consistently, contrary to master ``` setoption name SyzygyPath value ../../../syzygy/3-4-5/ setoption name Hash value 2048 position fen 1R6/3k4/8/K2p4/4n3/2P5/8/8 w - - 0 1 go depth 58 ucinewgame ``` The PR (prior to a rewrite for clarity) passed STC: LLR: 2.94 (-2.94,2.94) {-1.50,0.50} Total: 65405 W: 12454 L: 12384 D: 40567 Ptnml(0-2): 920, 7256, 16285, 7286, 944 http://tests.stockfishchess.org/tests/view/5e441a3be70d848499f63d15 passed LTC: LLR: 2.94 (-2.94,2.94) {-1.50,0.50} Total: 27096 W: 3477 L: 3413 D: 20206 Ptnml(0-2): 128, 2215, 8776, 2292, 122 http://tests.stockfishchess.org/tests/view/5e44e277e70d848499f63d63 The incorrectly named VALUE_MATE_IN_MAX_PLY and VALUE_MATED_IN_MAX_PLY were renamed into VALUE_TB_WIN_IN_MAX_PLY and VALUE_TB_LOSS_IN_MAX_PLY, and correclty defined VALUE_MATE_IN_MAX_PLY and VALUE_MATED_IN_MAX_PLY were introduced. One further (corner case) mistake using these constants was fixed (go mate X), which could lead to a premature return if X > MAX_PLY / 2, but TB were present. Thanks to @svivanov72 for one of the reports and help fixing the issue. closes https://github.com/official-stockfish/Stockfish/pull/2552 Bench: 4932981
2020-02-11 12:42:32 -07:00
// value_to_tt() adjusts a mate or TB score from "plies to mate from the root" to
// "plies to mate from the current position". Standard scores are unchanged.
// The function is called before storing a value in the transposition table.
Value value_to_tt(Value v, int ply) {
assert(v != VALUE_NONE);
Fix for incorrect VALUE_MATE_IN_MAX_PLY usage. Fixes #2533, fixes #2543, fixes #2423. the code that prevents false mate announcements depending on the TT state (GHI), incorrectly used VALUE_MATE_IN_MAX_PLY. The latter constant, however, also includes, counterintuitively, the TB win range. This patch fixes that, by restoring the behavior for TB win scores, while retaining the false mate correctness, and improving the mate finding ability. In particular no alse mates are announced with the poisened hash testcase ``` position fen 8/8/8/3k4/8/8/6K1/7R w - - 0 1 go depth 40 position fen 8/8/8/3k4/8/8/6K1/7R w - - 76 1 go depth 20 ucinewgame ``` mates are found with the testcases reported in #2543 ``` position fen 4k3/3pp3/8/8/8/8/2PPP3/4K3 w - - 0 1 setoption name Hash value 1024 go depth 55 ucinewgame ``` and ``` position fen 4k3/4p3/8/8/8/8/3PP3/4K3 w - - 0 1 setoption name Hash value 1024 go depth 45 ucinewgame ``` furthermore, on the mate finding benchmark (ChestUCI_23102018.epd), performance improves over master, roughly reaching performance with the false mate protection reverted ``` Analyzing 6566 mate positions for best and found mates: ----------------best ---------------found nodes master revert fixed master revert fixed 16000000 4233 4236 4235 5200 5201 5199 32000000 4583 4585 4585 5417 5424 5418 64000000 4852 4853 4855 5575 5584 5579 128000000 5071 5068 5066 5710 5720 5716 256000000 5280 5282 5279 5819 5827 5826 512000000 5471 5468 5468 5919 5935 5932 ``` On a testcase with TB enabled, progress is made consistently, contrary to master ``` setoption name SyzygyPath value ../../../syzygy/3-4-5/ setoption name Hash value 2048 position fen 1R6/3k4/8/K2p4/4n3/2P5/8/8 w - - 0 1 go depth 58 ucinewgame ``` The PR (prior to a rewrite for clarity) passed STC: LLR: 2.94 (-2.94,2.94) {-1.50,0.50} Total: 65405 W: 12454 L: 12384 D: 40567 Ptnml(0-2): 920, 7256, 16285, 7286, 944 http://tests.stockfishchess.org/tests/view/5e441a3be70d848499f63d15 passed LTC: LLR: 2.94 (-2.94,2.94) {-1.50,0.50} Total: 27096 W: 3477 L: 3413 D: 20206 Ptnml(0-2): 128, 2215, 8776, 2292, 122 http://tests.stockfishchess.org/tests/view/5e44e277e70d848499f63d63 The incorrectly named VALUE_MATE_IN_MAX_PLY and VALUE_MATED_IN_MAX_PLY were renamed into VALUE_TB_WIN_IN_MAX_PLY and VALUE_TB_LOSS_IN_MAX_PLY, and correclty defined VALUE_MATE_IN_MAX_PLY and VALUE_MATED_IN_MAX_PLY were introduced. One further (corner case) mistake using these constants was fixed (go mate X), which could lead to a premature return if X > MAX_PLY / 2, but TB were present. Thanks to @svivanov72 for one of the reports and help fixing the issue. closes https://github.com/official-stockfish/Stockfish/pull/2552 Bench: 4932981
2020-02-11 12:42:32 -07:00
return v >= VALUE_TB_WIN_IN_MAX_PLY ? v + ply
: v <= VALUE_TB_LOSS_IN_MAX_PLY ? v - ply : v;
}
// value_from_tt() is the inverse of value_to_tt(): it adjusts a mate or TB score
// from the transposition table (which refers to the plies to mate/be mated from
// current position) to "plies to mate/be mated (TB win/loss) from the root". However,
// for mate scores, to avoid potentially false mate scores related to the 50 moves rule
// and the graph history interaction, we return an optimal TB score instead.
Fix incorrect mate score. Current master 648c7ec25db2040c0af34dd846dfa3f57af5ad0a will generate an incorrect mate score for: ``` setoption name Hash value 8 setoption name Threads value 1 position fen 8/1p2KP2/1p4q1/1Pp5/2P5/N1Pp1k2/3P4/1N6 b - - 76 40 go depth 49 ``` even though the position is a draw. Generally, SF tries to display only proven mate scores, so this is a bug. This was posted http://www.talkchess.com/forum3/viewtopic.php?f=2&t=72166 by Uri Blass, with the correct analysis that this must be related to the 50 moves draw rule being ignored somewhere. Indeed, this is possible as positions and there eval are stored in the TT, without reference to the 50mr counter. Depending on the search path followed a position can thus be mate or draw in the TT (GHI or Graph history interaction). Therefore, to prove mate lines, the TT content has to be used with care. Rather than ignoring TT content in general or for mate scores (which impact search or mate finding), it is possible to be more selective. In particular, @WOnder93 suggested to only ignore the TT if the 50mr draw ply is closer than the mate ply. This patch implements this idea, by clamping the eval in the TT to +-VALUE_MATED_IN_MAX_PLY. This retains the TTmove, but causes a research of these lines (with the current 50mr counter) as needed. This patch hardly ever affects search (as indicated by the unchanged bench), but fixes the testcase. As the conditions are very specific, also mate finding will almost never be less efficient (testing welcome). It was also shown to pass STC and LTC non-regression testing, in a form using if/then/else instead of ternary operators: STC: LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 93605 W: 15346 L: 15340 D: 62919 http://tests.stockfishchess.org/tests/view/5db45bb00ebc5908127538d4 LTC: LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 33873 W: 7359 L: 7261 D: 19253 http://tests.stockfishchess.org/tests/view/5db4c8940ebc5902d6b146fc closes https://github.com/official-stockfish/Stockfish/issues/2370 Bench: 4362323
2019-10-26 08:34:19 -06:00
Value value_from_tt(Value v, int ply, int r50c) {
Fix for incorrect VALUE_MATE_IN_MAX_PLY usage. Fixes #2533, fixes #2543, fixes #2423. the code that prevents false mate announcements depending on the TT state (GHI), incorrectly used VALUE_MATE_IN_MAX_PLY. The latter constant, however, also includes, counterintuitively, the TB win range. This patch fixes that, by restoring the behavior for TB win scores, while retaining the false mate correctness, and improving the mate finding ability. In particular no alse mates are announced with the poisened hash testcase ``` position fen 8/8/8/3k4/8/8/6K1/7R w - - 0 1 go depth 40 position fen 8/8/8/3k4/8/8/6K1/7R w - - 76 1 go depth 20 ucinewgame ``` mates are found with the testcases reported in #2543 ``` position fen 4k3/3pp3/8/8/8/8/2PPP3/4K3 w - - 0 1 setoption name Hash value 1024 go depth 55 ucinewgame ``` and ``` position fen 4k3/4p3/8/8/8/8/3PP3/4K3 w - - 0 1 setoption name Hash value 1024 go depth 45 ucinewgame ``` furthermore, on the mate finding benchmark (ChestUCI_23102018.epd), performance improves over master, roughly reaching performance with the false mate protection reverted ``` Analyzing 6566 mate positions for best and found mates: ----------------best ---------------found nodes master revert fixed master revert fixed 16000000 4233 4236 4235 5200 5201 5199 32000000 4583 4585 4585 5417 5424 5418 64000000 4852 4853 4855 5575 5584 5579 128000000 5071 5068 5066 5710 5720 5716 256000000 5280 5282 5279 5819 5827 5826 512000000 5471 5468 5468 5919 5935 5932 ``` On a testcase with TB enabled, progress is made consistently, contrary to master ``` setoption name SyzygyPath value ../../../syzygy/3-4-5/ setoption name Hash value 2048 position fen 1R6/3k4/8/K2p4/4n3/2P5/8/8 w - - 0 1 go depth 58 ucinewgame ``` The PR (prior to a rewrite for clarity) passed STC: LLR: 2.94 (-2.94,2.94) {-1.50,0.50} Total: 65405 W: 12454 L: 12384 D: 40567 Ptnml(0-2): 920, 7256, 16285, 7286, 944 http://tests.stockfishchess.org/tests/view/5e441a3be70d848499f63d15 passed LTC: LLR: 2.94 (-2.94,2.94) {-1.50,0.50} Total: 27096 W: 3477 L: 3413 D: 20206 Ptnml(0-2): 128, 2215, 8776, 2292, 122 http://tests.stockfishchess.org/tests/view/5e44e277e70d848499f63d63 The incorrectly named VALUE_MATE_IN_MAX_PLY and VALUE_MATED_IN_MAX_PLY were renamed into VALUE_TB_WIN_IN_MAX_PLY and VALUE_TB_LOSS_IN_MAX_PLY, and correclty defined VALUE_MATE_IN_MAX_PLY and VALUE_MATED_IN_MAX_PLY were introduced. One further (corner case) mistake using these constants was fixed (go mate X), which could lead to a premature return if X > MAX_PLY / 2, but TB were present. Thanks to @svivanov72 for one of the reports and help fixing the issue. closes https://github.com/official-stockfish/Stockfish/pull/2552 Bench: 4932981
2020-02-11 12:42:32 -07:00
if (v == VALUE_NONE)
return VALUE_NONE;
if (v >= VALUE_TB_WIN_IN_MAX_PLY) // TB win or better
{
if (v >= VALUE_MATE_IN_MAX_PLY && VALUE_MATE - v > 99 - r50c)
return VALUE_MATE_IN_MAX_PLY - 1; // do not return a potentially false mate score
return v - ply;
}
if (v <= VALUE_TB_LOSS_IN_MAX_PLY) // TB loss or worse
{
if (v <= VALUE_MATED_IN_MAX_PLY && VALUE_MATE + v > 99 - r50c)
return VALUE_MATED_IN_MAX_PLY + 1; // do not return a potentially false mate score
return v + ply;
}
return v;
}
// update_pv() adds current move and appends child pv[]
void update_pv(Move* pv, Move move, Move* childPv) {
for (*pv++ = move; childPv && *childPv != MOVE_NONE; )
*pv++ = *childPv++;
*pv = MOVE_NONE;
}
// update_all_stats() updates stats at the end of search() when a bestMove is found
void update_all_stats(const Position& pos, Stack* ss, Move bestMove, Value bestValue, Value beta, Square prevSq,
Revert 5 recent patches Revert 5 patches which were merged, but lead to a regression test that showed negative Elo gain: http://tests.stockfishchess.org/tests/view/5e307251ab2d69d58394fdb9 This was discussed in depth in: https://github.com/official-stockfish/Stockfish/issues/2531 Each patch was removed and tested as a simplification, full list below, and the whole combo as well. After the revert the regression test showed a neutral result: http://tests.stockfishchess.org/tests/view/5e334851708b13464ceea33c As a result of this experience, the SPRT testing bounds will be made more strict. Reverted patches: 1 Dynamic Complexity 6d0eabd5fe2961551477820ab7619e2c31e01ffd : STC 10+0.1 https://tests.stockfishchess.org/tests/view/5e31fcacec661e2e6a340d08 : LLR: 2.97 (-2.94,2.94) {-1.50,0.50} Total: 38130 W: 7326 L: 7189 D: 23615 Ptnml(0-2): 677, 4346, 8843, 4545, 646 LTC 60+0.6 https://tests.stockfishchess.org/tests/view/5e32c18fec661e2e6a340d73 : LLR: 2.94 (-2.94,2.94) {-1.50,0.50} Total: 38675 W: 4941 L: 4866 D: 28868 Ptnml(0-2): 270, 3556, 11429, 3584, 291 3 More bonus for bestMoves on past PV nodes 71e0b5385e2717679a57c6b77d8c7ac5fff3b89f : STC 10+0.1 https://tests.stockfishchess.org/tests/view/5e31fe93ec661e2e6a340d10 : LLR: 2.95 (-2.94,2.94) {-1.50,0.50} Total: 46100 W: 8853 L: 8727 D: 28520 Ptnml(0-2): 796, 5297, 10749, 5387, 813 LTC 60+0.6 https://tests.stockfishchess.org/tests/view/5e32c187ec661e2e6a340d71 : LLR: 2.96 (-2.94,2.94) {-1.50,0.50} Total: 16920 W: 2161 L: 2055 D: 12704 Ptnml(0-2): 115, 1498, 5006, 1569, 130 4 Tweak Restricted Piece Bonus 0ae00454ba6928d181b46103e5c83e6d58fcebe5 : STC 10+0.1 https://tests.stockfishchess.org/tests/view/5e31fefaec661e2e6a340d15 : LLR: 2.94 (-2.94,2.94) {-1.50,0.50} Total: 88328 W: 17060 L: 16997 D: 54271 Ptnml(0-2): 1536, 10446, 20169, 10422, 1581 LTC 60+0.6 https://tests.stockfishchess.org/tests/view/5e32c17aec661e2e6a340d6f : LLR: 2.95 (-2.94,2.94) {-1.50,0.50} Total: 34784 W: 4551 L: 4466 D: 25767 Ptnml(0-2): 255, 3279, 10061, 3345, 262 5 History update for pruned captures 01b6088af39902001d2d6844561b6a2faa549282 : STC 10+0.1 https://tests.stockfishchess.org/tests/view/5e31ff5eec661e2e6a340d1a : LLR: 2.94 (-2.94,2.94) {-1.50,0.50} Total: 29541 W: 5735 L: 5588 D: 18218 Ptnml(0-2): 483, 3445, 6820, 3469, 545 LTC 60+0.6 https://tests.stockfishchess.org/tests/view/5e32c196ec661e2e6a340d75 : LLR: 2.94 (-2.94,2.94) {-1.50,0.50} Total: 22177 W: 2854 L: 2757 D: 16566 Ptnml(0-2): 143, 2005, 6555, 2055, 164 6 Tweak trapped rook penalty 18fc21eba0368fd5e3c4c4b8ee1000c9ac445425 : STC 10+0.1 https://tests.stockfishchess.org/tests/view/5e31ffb1ec661e2e6a340d1c : LLR: 2.95 (-2.94,2.94) {-1.50,0.50} Total: 24476 W: 4727 L: 4569 D: 15180 Ptnml(0-2): 390, 2834, 5659, 2933, 417 LTC 60+0.6 https://tests.stockfishchess.org/tests/view/5e32c19eec661e2e6a340d77 : LLR: 2.95 (-2.94,2.94) {-1.50,0.50} Total: 97332 W: 12492 L: 12466 D: 72374 Ptnml(0-2): 690, 9107, 28738, 9034, 720 All 5 as one simplification : LTC 60+0.6 https://tests.stockfishchess.org/tests/view/5e334098708b13464ceea330 : LLR: 2.94 (-2.94,2.94) {-1.50,0.50} Total: 7829 W: 1079 L: 964 D: 5786 Ptnml(0-2): 52, 690, 2281, 781, 65 Bench: 5153165
2020-01-30 13:44:04 -07:00
Move* quietsSearched, int quietCount, Move* capturesSearched, int captureCount, Depth depth) {
int bonus1, bonus2;
Color us = pos.side_to_move();
Thread* thisThread = pos.this_thread();
CapturePieceToHistory& captureHistory = thisThread->captureHistory;
Piece moved_piece = pos.moved_piece(bestMove);
PieceType captured = type_of(pos.piece_on(to_sq(bestMove)));
bonus1 = stat_bonus(depth + 1);
bonus2 = bestValue > beta + PawnValueMg ? bonus1 // larger bonus
: stat_bonus(depth); // smaller bonus
if (!pos.capture_or_promotion(bestMove))
{
// Increase stats for the best move in case it was a quiet move
update_quiet_stats(pos, ss, bestMove, bonus2, depth);
// Decrease stats for all non-best quiet moves
for (int i = 0; i < quietCount; ++i)
{
thisThread->mainHistory[us][from_to(quietsSearched[i])] << -bonus2;
update_continuation_histories(ss, pos.moved_piece(quietsSearched[i]), to_sq(quietsSearched[i]), -bonus2);
}
}
else
// Increase stats for the best move in case it was a capture move
captureHistory[moved_piece][to_sq(bestMove)][captured] << bonus1;
// Extra penalty for a quiet early move that was not a TT move or
// main killer move in previous ply when it gets refuted.
if ( ((ss-1)->moveCount == 1 + (ss-1)->ttHit || ((ss-1)->currentMove == (ss-1)->killers[0]))
&& !pos.captured_piece())
update_continuation_histories(ss-1, pos.piece_on(prevSq), prevSq, -bonus1);
// Decrease stats for all non-best capture moves
for (int i = 0; i < captureCount; ++i)
{
moved_piece = pos.moved_piece(capturesSearched[i]);
captured = type_of(pos.piece_on(to_sq(capturesSearched[i])));
captureHistory[moved_piece][to_sq(capturesSearched[i])][captured] << -bonus1;
}
}
// update_continuation_histories() updates histories of the move pairs formed
// by moves at ply -1, -2, -4, and -6 with current move.
void update_continuation_histories(Stack* ss, Piece pc, Square to, int bonus) {
for (int i : {1, 2, 4, 6})
{
// Only update first 2 continuation histories if we are in check
if (ss->inCheck && i > 2)
break;
if (is_ok((ss-i)->currentMove))
(*(ss-i)->continuationHistory)[pc][to] << bonus;
}
}
// update_quiet_stats() updates move sorting heuristics
void update_quiet_stats(const Position& pos, Stack* ss, Move move, int bonus, int depth) {
// Update killers
if (ss->killers[0] != move)
{
ss->killers[1] = ss->killers[0];
ss->killers[0] = move;
}
Color us = pos.side_to_move();
Thread* thisThread = pos.this_thread();
thisThread->mainHistory[us][from_to(move)] << bonus;
update_continuation_histories(ss, pos.moved_piece(move), to_sq(move), bonus);
// Penalty for reversed move in case of moved piece not being a pawn
if (type_of(pos.moved_piece(move)) != PAWN)
thisThread->mainHistory[us][from_to(reverse_move(move))] << -bonus;
// Update countermove history
if (is_ok((ss-1)->currentMove))
{
Square prevSq = to_sq((ss-1)->currentMove);
thisThread->counterMoves[pos.piece_on(prevSq)][prevSq] = move;
}
// Update low ply history
if (depth > 11 && ss->ply < MAX_LPH)
thisThread->lowPlyHistory[ss->ply][from_to(move)] << stat_bonus(depth - 7);
}
// When playing with strength handicap, choose best move among a set of RootMoves
// using a statistical rule dependent on 'level'. Idea by Heinz van Saanen.
Move Skill::pick_best(size_t multiPV) {
const RootMoves& rootMoves = Threads.main()->rootMoves;
static PRNG rng(now()); // PRNG sequence should be non-deterministic
// RootMoves are already sorted by score in descending order
Value topScore = rootMoves[0].score;
int delta = std::min(topScore - rootMoves[multiPV - 1].score, PawnValueMg);
int maxScore = -VALUE_INFINITE;
double weakness = 120 - 2 * level;
// Choose best move. For each move score we add two terms, both dependent on
// weakness. One is deterministic and bigger for weaker levels, and one is
// random. Then we choose the move with the resulting highest score.
for (size_t i = 0; i < multiPV; ++i)
{
// This is our magic formula
int push = int(( weakness * int(topScore - rootMoves[i].score)
+ delta * (rng.rand<unsigned>() % int(weakness))) / 128);
if (rootMoves[i].score + push >= maxScore)
{
maxScore = rootMoves[i].score + push;
best = rootMoves[i].pv[0];
}
}
return best;
}
} // namespace
/// MainThread::check_time() is used to print debug info and, more importantly,
/// to detect when we are out of available time and thus stop the search.
void MainThread::check_time() {
if (--callsCnt > 0)
return;
// When using nodes, ensure checking rate is not lower than 0.1% of nodes
callsCnt = Limits.nodes ? std::min(1024, int(Limits.nodes / 1024)) : 1024;
static TimePoint lastInfoTime = now();
TimePoint elapsed = Time.elapsed();
TimePoint tick = Limits.startTime + elapsed;
if (tick - lastInfoTime >= 1000)
{
lastInfoTime = tick;
dbg_print();
}
// We should not stop pondering until told so by the GUI
if (ponder)
return;
if ( (Limits.use_time_management() && (elapsed > Time.maximum() - 10 || stopOnPonderhit))
|| (Limits.movetime && elapsed >= Limits.movetime)
|| (Limits.nodes && Threads.nodes_searched() >= (uint64_t)Limits.nodes))
Threads.stop = true;
}
/// UCI::pv() formats PV information according to the UCI protocol. UCI requires
/// that all (if any) unsearched PV lines are sent using a previous search score.
string UCI::pv(const Position& pos, Depth depth, Value alpha, Value beta) {
std::stringstream ss;
TimePoint elapsed = Time.elapsed() + 1;
const RootMoves& rootMoves = pos.this_thread()->rootMoves;
size_t pvIdx = pos.this_thread()->pvIdx;
size_t multiPV = std::min((size_t)Options["MultiPV"], rootMoves.size());
uint64_t nodesSearched = Threads.nodes_searched();
uint64_t tbHits = Threads.tb_hits() + (TB::RootInTB ? rootMoves.size() : 0);
for (size_t i = 0; i < multiPV; ++i)
{
bool updated = rootMoves[i].score != -VALUE_INFINITE;
if (depth == 1 && !updated && i > 0)
continue;
Depth d = updated ? depth : std::max(1, depth - 1);
Value v = updated ? rootMoves[i].score : rootMoves[i].previousScore;
2015-01-18 00:05:05 -07:00
if (v == -VALUE_INFINITE)
v = VALUE_ZERO;
Fix for incorrect VALUE_MATE_IN_MAX_PLY usage. Fixes #2533, fixes #2543, fixes #2423. the code that prevents false mate announcements depending on the TT state (GHI), incorrectly used VALUE_MATE_IN_MAX_PLY. The latter constant, however, also includes, counterintuitively, the TB win range. This patch fixes that, by restoring the behavior for TB win scores, while retaining the false mate correctness, and improving the mate finding ability. In particular no alse mates are announced with the poisened hash testcase ``` position fen 8/8/8/3k4/8/8/6K1/7R w - - 0 1 go depth 40 position fen 8/8/8/3k4/8/8/6K1/7R w - - 76 1 go depth 20 ucinewgame ``` mates are found with the testcases reported in #2543 ``` position fen 4k3/3pp3/8/8/8/8/2PPP3/4K3 w - - 0 1 setoption name Hash value 1024 go depth 55 ucinewgame ``` and ``` position fen 4k3/4p3/8/8/8/8/3PP3/4K3 w - - 0 1 setoption name Hash value 1024 go depth 45 ucinewgame ``` furthermore, on the mate finding benchmark (ChestUCI_23102018.epd), performance improves over master, roughly reaching performance with the false mate protection reverted ``` Analyzing 6566 mate positions for best and found mates: ----------------best ---------------found nodes master revert fixed master revert fixed 16000000 4233 4236 4235 5200 5201 5199 32000000 4583 4585 4585 5417 5424 5418 64000000 4852 4853 4855 5575 5584 5579 128000000 5071 5068 5066 5710 5720 5716 256000000 5280 5282 5279 5819 5827 5826 512000000 5471 5468 5468 5919 5935 5932 ``` On a testcase with TB enabled, progress is made consistently, contrary to master ``` setoption name SyzygyPath value ../../../syzygy/3-4-5/ setoption name Hash value 2048 position fen 1R6/3k4/8/K2p4/4n3/2P5/8/8 w - - 0 1 go depth 58 ucinewgame ``` The PR (prior to a rewrite for clarity) passed STC: LLR: 2.94 (-2.94,2.94) {-1.50,0.50} Total: 65405 W: 12454 L: 12384 D: 40567 Ptnml(0-2): 920, 7256, 16285, 7286, 944 http://tests.stockfishchess.org/tests/view/5e441a3be70d848499f63d15 passed LTC: LLR: 2.94 (-2.94,2.94) {-1.50,0.50} Total: 27096 W: 3477 L: 3413 D: 20206 Ptnml(0-2): 128, 2215, 8776, 2292, 122 http://tests.stockfishchess.org/tests/view/5e44e277e70d848499f63d63 The incorrectly named VALUE_MATE_IN_MAX_PLY and VALUE_MATED_IN_MAX_PLY were renamed into VALUE_TB_WIN_IN_MAX_PLY and VALUE_TB_LOSS_IN_MAX_PLY, and correclty defined VALUE_MATE_IN_MAX_PLY and VALUE_MATED_IN_MAX_PLY were introduced. One further (corner case) mistake using these constants was fixed (go mate X), which could lead to a premature return if X > MAX_PLY / 2, but TB were present. Thanks to @svivanov72 for one of the reports and help fixing the issue. closes https://github.com/official-stockfish/Stockfish/pull/2552 Bench: 4932981
2020-02-11 12:42:32 -07:00
bool tb = TB::RootInTB && abs(v) < VALUE_MATE_IN_MAX_PLY;
v = tb ? rootMoves[i].tbScore : v;
if (ss.rdbuf()->in_avail()) // Not at first line
ss << "\n";
ss << "info"
Eliminate ONE_PLY Simplification that eliminates ONE_PLY, based on a suggestion in the forum that support for fractional plies has never been used, and @mcostalba's openness to the idea of eliminating it. We lose a little bit of type safety by making Depth an integer, but in return we simplify the code in search.cpp quite significantly. No functional change ------------------------------------------ The argument favoring eliminating ONE_PLY: * The term “ONE_PLY” comes up in a lot of forum posts (474 to date) https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:relevance * There is occasionally a commit that breaks invariance of the code with respect to ONE_PLY https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:date/fishcooking/ZIPdYj6k0fk/KdNGcPWeBgAJ * To prevent such commits, there is a Travis CI hack that doubles ONE_PLY and rechecks bench * Sustaining ONE_PLY has, alas, not resulted in any improvements to the engine, despite many individuals testing many experiments over 5 years. The strongest argument in favor of preserving ONE_PLY comes from @locutus: “If we use par example ONE_PLY=256 the parameter space is increases by the factor 256. So it seems very unlikely that the optimal setting is in the subspace of ONE_PLY=1.” There is a strong theoretical impediment to fractional depth systems: the transposition table uses depth to determine when a stored result is good enough to supply an answer for a current search. If you have fractional depths, then different pathways to the position can be at fractionally different depths. In the end, there are three separate times when a proposal to remove ONE_PLY was defeated by the suggestion to “give it a few more months.” So… it seems like time to remove this distraction from the community. See the pull request here: https://github.com/official-stockfish/Stockfish/pull/2289
2019-09-28 14:27:23 -06:00
<< " depth " << d
<< " seldepth " << rootMoves[i].selDepth
<< " multipv " << i + 1
<< " score " << UCI::value(v);
if (Options["UCI_ShowWDL"])
ss << UCI::wdl(v, pos.game_ply());
if (!tb && i == pvIdx)
ss << (v >= beta ? " lowerbound" : v <= alpha ? " upperbound" : "");
ss << " nodes " << nodesSearched
<< " nps " << nodesSearched * 1000 / elapsed;
2015-01-31 05:04:15 -07:00
if (elapsed > 1000) // Earlier makes little sense
ss << " hashfull " << TT.hashfull();
ss << " tbhits " << tbHits
<< " time " << elapsed
<< " pv";
for (Move m : rootMoves[i].pv)
ss << " " << UCI::move(m, pos.is_chess960());
}
return ss.str();
}
2008-08-31 23:59:13 -06:00
/// RootMove::extract_ponder_from_tt() is called in case we have no ponder move
/// before exiting the search, for instance, in case we stop the search during a
/// fail high at root. We try hard to have a ponder move to return to the GUI,
/// otherwise in case of 'ponder on' we have nothing to think on.
bool RootMove::extract_ponder_from_tt(Position& pos) {
StateInfo st;
ASSERT_ALIGNED(&st, Eval::NNUE::CacheLineSize);
bool ttHit;
assert(pv.size() == 1);
if (pv[0] == MOVE_NONE)
return false;
pos.do_move(pv[0], st);
TTEntry* tte = TT.probe(pos.key(), ttHit);
if (ttHit)
{
Move m = tte->move(); // Local copy to be SMP safe
if (MoveList<LEGAL>(pos).contains(m))
pv.push_back(m);
}
pos.undo_move(pv[0]);
return pv.size() > 1;
}
Tablebases root ranking This patch corrects both MultiPV behaviour and "go searchmoves" behaviour for tablebases. We change the logic of table base probing at root positions from filtering to ranking. The ranking code is much more straightforward than the current filtering code (this is a simplification), and also more versatile. If the root is a TB position, each root move is probed and assigned a TB score and a TB rank. The TB score is the Value to be displayed to the user for that move (unless the search finds a mate score), while the TB rank determines which moves should appear higher in a multi-pv search. In game play, the engine will always pick a move with the highest rank. Ranks run from -1000 to +1000: 901 to 1000 : TB win 900 : normally a TB win, in rare cases this could be a draw 1 to 899 : cursed TB wins 0 : draw -1 to -899 : blessed TB losses -900 : normally a TB loss, in rare cases this could be a draw -901 to -1000 : TB loss Normally all winning moves get rank 1000 (to let the search pick the best among them). The exception is if there has been a first repetition. In that case, moves are ranked strictly by DTZ so that the engine will play a move that lowers DTZ (and therefore cannot repeat the position a second time). Losing moves get rank -1000 unless they have relatively high DTZ, meaning they have some drawing chances. Those get ranks towards -901 (when they cross -900 the draw is certain). Closes https://github.com/official-stockfish/Stockfish/pull/1467 No functional change (without tablebases).
2018-04-18 10:38:38 -06:00
void Tablebases::rank_root_moves(Position& pos, Search::RootMoves& rootMoves) {
RootInTB = false;
Allow UCI parameters to be double Change the operators of the Option type in uci.h to accept floating point numbers in double precision on input as the numerical type for the "spin" values of the UCI protocol. The output of Stockfish after the "uci" command is unaffected. This change is compatible with all the existing GUI (as they will continue sending integers that we can interpret as doubles in SF), and allows us to pass double parameters to Stockfish in the console via the "setoption" command. This will be useful if we implement another tuner as an alternative for SPSA. Closes https://github.com/official-stockfish/Stockfish/pull/1556 No functional change. --------------------- A example of the new functionality in action in the branch `tune_float2'`: https://github.com/snicolet/Stockfish/commit/876c322d0f20ee232da977b4d3489c4cc929765e I have added the following lines in ucioptions.cpp: ```C++ void on_pi(const Option& o) { double x = Options["PI"]; // or double x = o; std::cerr << "received value is x = " << x << std::endl; } ... o["PI"] << Option(3.1415926, -10000000, 10000000, on_pi); ``` Then I can change the value of Pi in Stockfish via the command line, and check that Stockfish understands a floating point: ```` > ./stockfish > setoption name PI value 2.7182818284 received value is x = 2.71828 ```` On output, the default value of Pi is truncated to 3 (to remain compatible with the UCI protocol and GUIs): ```` > uci [...] option name SyzygyProbeLimit type spin default 6 min 0 max 6 option name PI type spin default 3 min -10000000 max 10000000 uciok ````
2018-04-18 20:16:19 -06:00
UseRule50 = bool(Options["Syzygy50MoveRule"]);
Eliminate ONE_PLY Simplification that eliminates ONE_PLY, based on a suggestion in the forum that support for fractional plies has never been used, and @mcostalba's openness to the idea of eliminating it. We lose a little bit of type safety by making Depth an integer, but in return we simplify the code in search.cpp quite significantly. No functional change ------------------------------------------ The argument favoring eliminating ONE_PLY: * The term “ONE_PLY” comes up in a lot of forum posts (474 to date) https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:relevance * There is occasionally a commit that breaks invariance of the code with respect to ONE_PLY https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:date/fishcooking/ZIPdYj6k0fk/KdNGcPWeBgAJ * To prevent such commits, there is a Travis CI hack that doubles ONE_PLY and rechecks bench * Sustaining ONE_PLY has, alas, not resulted in any improvements to the engine, despite many individuals testing many experiments over 5 years. The strongest argument in favor of preserving ONE_PLY comes from @locutus: “If we use par example ONE_PLY=256 the parameter space is increases by the factor 256. So it seems very unlikely that the optimal setting is in the subspace of ONE_PLY=1.” There is a strong theoretical impediment to fractional depth systems: the transposition table uses depth to determine when a stored result is good enough to supply an answer for a current search. If you have fractional depths, then different pathways to the position can be at fractionally different depths. In the end, there are three separate times when a proposal to remove ONE_PLY was defeated by the suggestion to “give it a few more months.” So… it seems like time to remove this distraction from the community. See the pull request here: https://github.com/official-stockfish/Stockfish/pull/2289
2019-09-28 14:27:23 -06:00
ProbeDepth = int(Options["SyzygyProbeDepth"]);
Allow UCI parameters to be double Change the operators of the Option type in uci.h to accept floating point numbers in double precision on input as the numerical type for the "spin" values of the UCI protocol. The output of Stockfish after the "uci" command is unaffected. This change is compatible with all the existing GUI (as they will continue sending integers that we can interpret as doubles in SF), and allows us to pass double parameters to Stockfish in the console via the "setoption" command. This will be useful if we implement another tuner as an alternative for SPSA. Closes https://github.com/official-stockfish/Stockfish/pull/1556 No functional change. --------------------- A example of the new functionality in action in the branch `tune_float2'`: https://github.com/snicolet/Stockfish/commit/876c322d0f20ee232da977b4d3489c4cc929765e I have added the following lines in ucioptions.cpp: ```C++ void on_pi(const Option& o) { double x = Options["PI"]; // or double x = o; std::cerr << "received value is x = " << x << std::endl; } ... o["PI"] << Option(3.1415926, -10000000, 10000000, on_pi); ``` Then I can change the value of Pi in Stockfish via the command line, and check that Stockfish understands a floating point: ```` > ./stockfish > setoption name PI value 2.7182818284 received value is x = 2.71828 ```` On output, the default value of Pi is truncated to 3 (to remain compatible with the UCI protocol and GUIs): ```` > uci [...] option name SyzygyProbeLimit type spin default 6 min 0 max 6 option name PI type spin default 3 min -10000000 max 10000000 uciok ````
2018-04-18 20:16:19 -06:00
Cardinality = int(Options["SyzygyProbeLimit"]);
Tablebases root ranking This patch corrects both MultiPV behaviour and "go searchmoves" behaviour for tablebases. We change the logic of table base probing at root positions from filtering to ranking. The ranking code is much more straightforward than the current filtering code (this is a simplification), and also more versatile. If the root is a TB position, each root move is probed and assigned a TB score and a TB rank. The TB score is the Value to be displayed to the user for that move (unless the search finds a mate score), while the TB rank determines which moves should appear higher in a multi-pv search. In game play, the engine will always pick a move with the highest rank. Ranks run from -1000 to +1000: 901 to 1000 : TB win 900 : normally a TB win, in rare cases this could be a draw 1 to 899 : cursed TB wins 0 : draw -1 to -899 : blessed TB losses -900 : normally a TB loss, in rare cases this could be a draw -901 to -1000 : TB loss Normally all winning moves get rank 1000 (to let the search pick the best among them). The exception is if there has been a first repetition. In that case, moves are ranked strictly by DTZ so that the engine will play a move that lowers DTZ (and therefore cannot repeat the position a second time). Losing moves get rank -1000 unless they have relatively high DTZ, meaning they have some drawing chances. Those get ranks towards -901 (when they cross -900 the draw is certain). Closes https://github.com/official-stockfish/Stockfish/pull/1467 No functional change (without tablebases).
2018-04-18 10:38:38 -06:00
bool dtz_available = true;
Tablebases root ranking This patch corrects both MultiPV behaviour and "go searchmoves" behaviour for tablebases. We change the logic of table base probing at root positions from filtering to ranking. The ranking code is much more straightforward than the current filtering code (this is a simplification), and also more versatile. If the root is a TB position, each root move is probed and assigned a TB score and a TB rank. The TB score is the Value to be displayed to the user for that move (unless the search finds a mate score), while the TB rank determines which moves should appear higher in a multi-pv search. In game play, the engine will always pick a move with the highest rank. Ranks run from -1000 to +1000: 901 to 1000 : TB win 900 : normally a TB win, in rare cases this could be a draw 1 to 899 : cursed TB wins 0 : draw -1 to -899 : blessed TB losses -900 : normally a TB loss, in rare cases this could be a draw -901 to -1000 : TB loss Normally all winning moves get rank 1000 (to let the search pick the best among them). The exception is if there has been a first repetition. In that case, moves are ranked strictly by DTZ so that the engine will play a move that lowers DTZ (and therefore cannot repeat the position a second time). Losing moves get rank -1000 unless they have relatively high DTZ, meaning they have some drawing chances. Those get ranks towards -901 (when they cross -900 the draw is certain). Closes https://github.com/official-stockfish/Stockfish/pull/1467 No functional change (without tablebases).
2018-04-18 10:38:38 -06:00
// Tables with fewer pieces than SyzygyProbeLimit are searched with
// ProbeDepth == DEPTH_ZERO
if (Cardinality > MaxCardinality)
{
Cardinality = MaxCardinality;
Eliminate ONE_PLY Simplification that eliminates ONE_PLY, based on a suggestion in the forum that support for fractional plies has never been used, and @mcostalba's openness to the idea of eliminating it. We lose a little bit of type safety by making Depth an integer, but in return we simplify the code in search.cpp quite significantly. No functional change ------------------------------------------ The argument favoring eliminating ONE_PLY: * The term “ONE_PLY” comes up in a lot of forum posts (474 to date) https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:relevance * There is occasionally a commit that breaks invariance of the code with respect to ONE_PLY https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:date/fishcooking/ZIPdYj6k0fk/KdNGcPWeBgAJ * To prevent such commits, there is a Travis CI hack that doubles ONE_PLY and rechecks bench * Sustaining ONE_PLY has, alas, not resulted in any improvements to the engine, despite many individuals testing many experiments over 5 years. The strongest argument in favor of preserving ONE_PLY comes from @locutus: “If we use par example ONE_PLY=256 the parameter space is increases by the factor 256. So it seems very unlikely that the optimal setting is in the subspace of ONE_PLY=1.” There is a strong theoretical impediment to fractional depth systems: the transposition table uses depth to determine when a stored result is good enough to supply an answer for a current search. If you have fractional depths, then different pathways to the position can be at fractionally different depths. In the end, there are three separate times when a proposal to remove ONE_PLY was defeated by the suggestion to “give it a few more months.” So… it seems like time to remove this distraction from the community. See the pull request here: https://github.com/official-stockfish/Stockfish/pull/2289
2019-09-28 14:27:23 -06:00
ProbeDepth = 0;
}
Tablebases root ranking This patch corrects both MultiPV behaviour and "go searchmoves" behaviour for tablebases. We change the logic of table base probing at root positions from filtering to ranking. The ranking code is much more straightforward than the current filtering code (this is a simplification), and also more versatile. If the root is a TB position, each root move is probed and assigned a TB score and a TB rank. The TB score is the Value to be displayed to the user for that move (unless the search finds a mate score), while the TB rank determines which moves should appear higher in a multi-pv search. In game play, the engine will always pick a move with the highest rank. Ranks run from -1000 to +1000: 901 to 1000 : TB win 900 : normally a TB win, in rare cases this could be a draw 1 to 899 : cursed TB wins 0 : draw -1 to -899 : blessed TB losses -900 : normally a TB loss, in rare cases this could be a draw -901 to -1000 : TB loss Normally all winning moves get rank 1000 (to let the search pick the best among them). The exception is if there has been a first repetition. In that case, moves are ranked strictly by DTZ so that the engine will play a move that lowers DTZ (and therefore cannot repeat the position a second time). Losing moves get rank -1000 unless they have relatively high DTZ, meaning they have some drawing chances. Those get ranks towards -901 (when they cross -900 the draw is certain). Closes https://github.com/official-stockfish/Stockfish/pull/1467 No functional change (without tablebases).
2018-04-18 10:38:38 -06:00
if (Cardinality >= popcount(pos.pieces()) && !pos.can_castle(ANY_CASTLING))
{
// Rank moves using DTZ tables
RootInTB = root_probe(pos, rootMoves);
Tablebases root ranking This patch corrects both MultiPV behaviour and "go searchmoves" behaviour for tablebases. We change the logic of table base probing at root positions from filtering to ranking. The ranking code is much more straightforward than the current filtering code (this is a simplification), and also more versatile. If the root is a TB position, each root move is probed and assigned a TB score and a TB rank. The TB score is the Value to be displayed to the user for that move (unless the search finds a mate score), while the TB rank determines which moves should appear higher in a multi-pv search. In game play, the engine will always pick a move with the highest rank. Ranks run from -1000 to +1000: 901 to 1000 : TB win 900 : normally a TB win, in rare cases this could be a draw 1 to 899 : cursed TB wins 0 : draw -1 to -899 : blessed TB losses -900 : normally a TB loss, in rare cases this could be a draw -901 to -1000 : TB loss Normally all winning moves get rank 1000 (to let the search pick the best among them). The exception is if there has been a first repetition. In that case, moves are ranked strictly by DTZ so that the engine will play a move that lowers DTZ (and therefore cannot repeat the position a second time). Losing moves get rank -1000 unless they have relatively high DTZ, meaning they have some drawing chances. Those get ranks towards -901 (when they cross -900 the draw is certain). Closes https://github.com/official-stockfish/Stockfish/pull/1467 No functional change (without tablebases).
2018-04-18 10:38:38 -06:00
if (!RootInTB)
{
// DTZ tables are missing; try to rank moves using WDL tables
dtz_available = false;
RootInTB = root_probe_wdl(pos, rootMoves);
}
}
if (RootInTB)
{
Tablebases root ranking This patch corrects both MultiPV behaviour and "go searchmoves" behaviour for tablebases. We change the logic of table base probing at root positions from filtering to ranking. The ranking code is much more straightforward than the current filtering code (this is a simplification), and also more versatile. If the root is a TB position, each root move is probed and assigned a TB score and a TB rank. The TB score is the Value to be displayed to the user for that move (unless the search finds a mate score), while the TB rank determines which moves should appear higher in a multi-pv search. In game play, the engine will always pick a move with the highest rank. Ranks run from -1000 to +1000: 901 to 1000 : TB win 900 : normally a TB win, in rare cases this could be a draw 1 to 899 : cursed TB wins 0 : draw -1 to -899 : blessed TB losses -900 : normally a TB loss, in rare cases this could be a draw -901 to -1000 : TB loss Normally all winning moves get rank 1000 (to let the search pick the best among them). The exception is if there has been a first repetition. In that case, moves are ranked strictly by DTZ so that the engine will play a move that lowers DTZ (and therefore cannot repeat the position a second time). Losing moves get rank -1000 unless they have relatively high DTZ, meaning they have some drawing chances. Those get ranks towards -901 (when they cross -900 the draw is certain). Closes https://github.com/official-stockfish/Stockfish/pull/1467 No functional change (without tablebases).
2018-04-18 10:38:38 -06:00
// Sort moves according to TB rank
std::stable_sort(rootMoves.begin(), rootMoves.end(),
[](const RootMove &a, const RootMove &b) { return a.tbRank > b.tbRank; } );
Tablebases root ranking This patch corrects both MultiPV behaviour and "go searchmoves" behaviour for tablebases. We change the logic of table base probing at root positions from filtering to ranking. The ranking code is much more straightforward than the current filtering code (this is a simplification), and also more versatile. If the root is a TB position, each root move is probed and assigned a TB score and a TB rank. The TB score is the Value to be displayed to the user for that move (unless the search finds a mate score), while the TB rank determines which moves should appear higher in a multi-pv search. In game play, the engine will always pick a move with the highest rank. Ranks run from -1000 to +1000: 901 to 1000 : TB win 900 : normally a TB win, in rare cases this could be a draw 1 to 899 : cursed TB wins 0 : draw -1 to -899 : blessed TB losses -900 : normally a TB loss, in rare cases this could be a draw -901 to -1000 : TB loss Normally all winning moves get rank 1000 (to let the search pick the best among them). The exception is if there has been a first repetition. In that case, moves are ranked strictly by DTZ so that the engine will play a move that lowers DTZ (and therefore cannot repeat the position a second time). Losing moves get rank -1000 unless they have relatively high DTZ, meaning they have some drawing chances. Those get ranks towards -901 (when they cross -900 the draw is certain). Closes https://github.com/official-stockfish/Stockfish/pull/1467 No functional change (without tablebases).
2018-04-18 10:38:38 -06:00
// Probe during search only if DTZ is not available and we are winning
if (dtz_available || rootMoves[0].tbScore <= VALUE_DRAW)
Cardinality = 0;
}
else
{
// Clean up if root_probe() and root_probe_wdl() have failed
for (auto& m : rootMoves)
m.tbRank = 0;
}
}
} // namespace Stockfish