1
0
Fork 0
stockfish/src/search.cpp

1860 lines
66 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-2008 Tord Romstad (Glaurung author)
Copyright (C) 2008-2015 Marco Costalba, Joona Kiiski, Tord Romstad
Copyright (C) 2015-2019 Marco Costalba, Joona Kiiski, Gary Linscott, Tord Romstad
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 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 };
Use exploration rate for reductions This patch measures how frequently search is exploring new configurations. This is done be computing a running average of ttHit. The ttHitAverage rate is somewhat low (e.g. 30% for startpos) in the normal case, while it can be very high if no progress is made (e.g. 90% for the fortress I used for testing). This information can be used to influence search. In this patch, by adjusting reductions if the rate > 50%. A first version (using a low ttHitAverageResolution and this 50% threshold) passed testing: STC LLR: 2.96 (-2.94,2.94) [-1.50,4.50] Total: 26425 W: 5837 L: 5650 D: 14938 http://tests.stockfishchess.org/tests/view/5dcede8b0ebc5902563258fa LTC LLR: 2.96 (-2.94,2.94) [0.00,3.50] Total: 32313 W: 5392 L: 5128 D: 21793 http://tests.stockfishchess.org/tests/view/5dcefb1f0ebc590256325c0e However, as discussed in pull request 2414, using a larger ttHitAverageResolution gives a better approximation of the underlying distributions. This needs a slight adjustment for the threshold as the new distributions are shifted a bit compared to the older ones, and this threshold seemingly is sensitive (we used 0.53125 here). https://github.com/official-stockfish/Stockfish/pull/2414 This final version also passed testing, and is used for the patch: STC LLR: 2.95 (-2.94,2.94) [-1.50,4.50] Total: 16025 W: 3555 L: 3399 D: 9071 http://tests.stockfishchess.org/tests/view/5dd070b90ebc5902579e20c2 LTC LLR: 2.96 (-2.94,2.94) [0.00,3.50] Total: 37576 W: 6277 L: 5998 D: 25301 http://tests.stockfishchess.org/tests/view/5dd0f58e6f544e798086f224 Closes https://github.com/official-stockfish/Stockfish/pull/2414 Bench: 4989584
2019-11-15 10:16:27 -07:00
constexpr uint64_t ttHitAverageWindow = 4096;
constexpr uint64_t ttHitAverageResolution = 1024;
// Razor and futility margins
constexpr int RazorMargin = 661;
Value futility_margin(Depth d, bool improving) {
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
return Value(198 * (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) {
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 + 520) / 1024 + (!i && r > 999);
}
constexpr int futility_move_count(bool improving, Depth depth) {
return (5 + depth * depth) * (1 + improving) / 2 - 1;
}
// 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 d > 17 ? -8 : 22 * d * d + 151 * d - 140;
}
// Add a small random component to draw evaluations to avoid 3fold-blindness
Value value_draw(Thread* thisThread) {
return VALUE_DRAW + Value(2 * (thisThread->nodes & 1) - 1);
}
// Skill structure is used to implement strength limit
struct Skill {
explicit Skill(int l) : level(l) {}
bool enabled() const { return level < 20; }
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
bool time_to_pick(Depth depth) const { return depth == 1 + level; }
Move pick_best(size_t multiPV);
int level;
Move best = MOVE_NONE;
};
// Breadcrumbs are used to mark nodes as being searched by a given thread
Introduce coordination between searching threads (#2204) this patch improves threading performance by introducing some coordination between threads. The observation is that threading is an area where a lot of Elo can potentially be gained: https://github.com/glinscott/fishtest/wiki/UsefulData#elo-from-threading At STC, 8 threads gain roughly 320 Elo, vs sequential at the same time, however, loses 66 Elo against a single thread with 8x more time. This 66 Elo should be partially recoverable with improved threading. To improve threading, this patch introduces some LMR at nodes that are already being searched by other threads. This requires some coordination between threads, avoiding however synchronisation. To do so, threads leave a trail of breadcrumbs to mark the nodes they are searching. These breadcrumbs are stored in a small hash table, which is only probed at low plies (currently ply < 8). A couple of variants of this patch passed both STC and LTC threaded tests. I picked the simpler, more robust version. I expect that further tests can find further improvements. STC (5+0.05 @ 8 threads): LLR: 2.95 (-2.94,2.94) [0.50,4.50] Total: 26209 W: 5359 L: 5079 D: 15771 http://tests.stockfishchess.org/tests/view/5d0a9b030ebc5925cf0a8e6f LTC (20+0.2 @ 8 threads): LLR: 2.96 (-2.94,2.94) [0.00,3.50] Total: 34832 W: 5650 L: 5382 D: 23800 http://tests.stockfishchess.org/tests/view/5d0c67a20ebc5925cf0aafa7 other passed/tested variants: http://tests.stockfishchess.org/tests/view/5d0a9b030ebc5925cf0a8e6f http://tests.stockfishchess.org/tests/view/5d0c67ca0ebc5925cf0aafa9 http://tests.stockfishchess.org/tests/view/5d0c67810ebc5925cf0aafa3 http://tests.stockfishchess.org/tests/view/5d0958ca0ebc5925cf0a74c6 For the sequential code there is no change in bench, and an earlier version of this patch passed a non-regression test. STC (10+0.1 @ 1 thread) LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 10471 W: 2364 L: 2220 D: 5887 http://tests.stockfishchess.org/tests/view/5d087ee20ebc5925cf0a6381 passed the additional non-regression tests at 2 and 4 threads 20+0.2 TC. The code was rebased on master prior to testing. 2 threads: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 218863 W: 40927 L: 41153 D: 136783 http://tests.stockfishchess.org/tests/view/5d18c6c30ebc5925cf0b9566 4threads: LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 16839 W: 3017 L: 2889 D: 10933 http://tests.stockfishchess.org/tests/view/5d18c6ea0ebc5925cf0b9568 No functional change.
2019-07-01 06:07:23 -06:00
struct Breadcrumb {
std::atomic<Thread*> thread;
std::atomic<Key> key;
};
std::array<Breadcrumb, 1024> breadcrumbs;
// ThreadHolding structure keeps track of which thread left breadcrumbs at the given
// node for potential reductions. A free node will be marked upon entering the moves
// loop by the constructor, and unmarked upon leaving that loop by the destructor.
Introduce coordination between searching threads (#2204) this patch improves threading performance by introducing some coordination between threads. The observation is that threading is an area where a lot of Elo can potentially be gained: https://github.com/glinscott/fishtest/wiki/UsefulData#elo-from-threading At STC, 8 threads gain roughly 320 Elo, vs sequential at the same time, however, loses 66 Elo against a single thread with 8x more time. This 66 Elo should be partially recoverable with improved threading. To improve threading, this patch introduces some LMR at nodes that are already being searched by other threads. This requires some coordination between threads, avoiding however synchronisation. To do so, threads leave a trail of breadcrumbs to mark the nodes they are searching. These breadcrumbs are stored in a small hash table, which is only probed at low plies (currently ply < 8). A couple of variants of this patch passed both STC and LTC threaded tests. I picked the simpler, more robust version. I expect that further tests can find further improvements. STC (5+0.05 @ 8 threads): LLR: 2.95 (-2.94,2.94) [0.50,4.50] Total: 26209 W: 5359 L: 5079 D: 15771 http://tests.stockfishchess.org/tests/view/5d0a9b030ebc5925cf0a8e6f LTC (20+0.2 @ 8 threads): LLR: 2.96 (-2.94,2.94) [0.00,3.50] Total: 34832 W: 5650 L: 5382 D: 23800 http://tests.stockfishchess.org/tests/view/5d0c67a20ebc5925cf0aafa7 other passed/tested variants: http://tests.stockfishchess.org/tests/view/5d0a9b030ebc5925cf0a8e6f http://tests.stockfishchess.org/tests/view/5d0c67ca0ebc5925cf0aafa9 http://tests.stockfishchess.org/tests/view/5d0c67810ebc5925cf0aafa3 http://tests.stockfishchess.org/tests/view/5d0958ca0ebc5925cf0a74c6 For the sequential code there is no change in bench, and an earlier version of this patch passed a non-regression test. STC (10+0.1 @ 1 thread) LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 10471 W: 2364 L: 2220 D: 5887 http://tests.stockfishchess.org/tests/view/5d087ee20ebc5925cf0a6381 passed the additional non-regression tests at 2 and 4 threads 20+0.2 TC. The code was rebased on master prior to testing. 2 threads: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 218863 W: 40927 L: 41153 D: 136783 http://tests.stockfishchess.org/tests/view/5d18c6c30ebc5925cf0b9566 4threads: LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 16839 W: 3017 L: 2889 D: 10933 http://tests.stockfishchess.org/tests/view/5d18c6ea0ebc5925cf0b9568 No functional change.
2019-07-01 06:07:23 -06:00
struct ThreadHolding {
explicit ThreadHolding(Thread* thisThread, Key posKey, int ply) {
location = ply < 8 ? &breadcrumbs[posKey & (breadcrumbs.size() - 1)] : nullptr;
otherThread = false;
owning = false;
if (location)
{
// See if another already marked this location, if not, mark it ourselves
Introduce coordination between searching threads (#2204) this patch improves threading performance by introducing some coordination between threads. The observation is that threading is an area where a lot of Elo can potentially be gained: https://github.com/glinscott/fishtest/wiki/UsefulData#elo-from-threading At STC, 8 threads gain roughly 320 Elo, vs sequential at the same time, however, loses 66 Elo against a single thread with 8x more time. This 66 Elo should be partially recoverable with improved threading. To improve threading, this patch introduces some LMR at nodes that are already being searched by other threads. This requires some coordination between threads, avoiding however synchronisation. To do so, threads leave a trail of breadcrumbs to mark the nodes they are searching. These breadcrumbs are stored in a small hash table, which is only probed at low plies (currently ply < 8). A couple of variants of this patch passed both STC and LTC threaded tests. I picked the simpler, more robust version. I expect that further tests can find further improvements. STC (5+0.05 @ 8 threads): LLR: 2.95 (-2.94,2.94) [0.50,4.50] Total: 26209 W: 5359 L: 5079 D: 15771 http://tests.stockfishchess.org/tests/view/5d0a9b030ebc5925cf0a8e6f LTC (20+0.2 @ 8 threads): LLR: 2.96 (-2.94,2.94) [0.00,3.50] Total: 34832 W: 5650 L: 5382 D: 23800 http://tests.stockfishchess.org/tests/view/5d0c67a20ebc5925cf0aafa7 other passed/tested variants: http://tests.stockfishchess.org/tests/view/5d0a9b030ebc5925cf0a8e6f http://tests.stockfishchess.org/tests/view/5d0c67ca0ebc5925cf0aafa9 http://tests.stockfishchess.org/tests/view/5d0c67810ebc5925cf0aafa3 http://tests.stockfishchess.org/tests/view/5d0958ca0ebc5925cf0a74c6 For the sequential code there is no change in bench, and an earlier version of this patch passed a non-regression test. STC (10+0.1 @ 1 thread) LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 10471 W: 2364 L: 2220 D: 5887 http://tests.stockfishchess.org/tests/view/5d087ee20ebc5925cf0a6381 passed the additional non-regression tests at 2 and 4 threads 20+0.2 TC. The code was rebased on master prior to testing. 2 threads: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 218863 W: 40927 L: 41153 D: 136783 http://tests.stockfishchess.org/tests/view/5d18c6c30ebc5925cf0b9566 4threads: LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 16839 W: 3017 L: 2889 D: 10933 http://tests.stockfishchess.org/tests/view/5d18c6ea0ebc5925cf0b9568 No functional change.
2019-07-01 06:07:23 -06:00
Thread* tmp = (*location).thread.load(std::memory_order_relaxed);
if (tmp == nullptr)
{
(*location).thread.store(thisThread, std::memory_order_relaxed);
(*location).key.store(posKey, std::memory_order_relaxed);
owning = true;
}
else if ( tmp != thisThread
&& (*location).key.load(std::memory_order_relaxed) == posKey)
otherThread = true;
}
}
~ThreadHolding() {
if (owning) // Free the marked location
Introduce coordination between searching threads (#2204) this patch improves threading performance by introducing some coordination between threads. The observation is that threading is an area where a lot of Elo can potentially be gained: https://github.com/glinscott/fishtest/wiki/UsefulData#elo-from-threading At STC, 8 threads gain roughly 320 Elo, vs sequential at the same time, however, loses 66 Elo against a single thread with 8x more time. This 66 Elo should be partially recoverable with improved threading. To improve threading, this patch introduces some LMR at nodes that are already being searched by other threads. This requires some coordination between threads, avoiding however synchronisation. To do so, threads leave a trail of breadcrumbs to mark the nodes they are searching. These breadcrumbs are stored in a small hash table, which is only probed at low plies (currently ply < 8). A couple of variants of this patch passed both STC and LTC threaded tests. I picked the simpler, more robust version. I expect that further tests can find further improvements. STC (5+0.05 @ 8 threads): LLR: 2.95 (-2.94,2.94) [0.50,4.50] Total: 26209 W: 5359 L: 5079 D: 15771 http://tests.stockfishchess.org/tests/view/5d0a9b030ebc5925cf0a8e6f LTC (20+0.2 @ 8 threads): LLR: 2.96 (-2.94,2.94) [0.00,3.50] Total: 34832 W: 5650 L: 5382 D: 23800 http://tests.stockfishchess.org/tests/view/5d0c67a20ebc5925cf0aafa7 other passed/tested variants: http://tests.stockfishchess.org/tests/view/5d0a9b030ebc5925cf0a8e6f http://tests.stockfishchess.org/tests/view/5d0c67ca0ebc5925cf0aafa9 http://tests.stockfishchess.org/tests/view/5d0c67810ebc5925cf0aafa3 http://tests.stockfishchess.org/tests/view/5d0958ca0ebc5925cf0a74c6 For the sequential code there is no change in bench, and an earlier version of this patch passed a non-regression test. STC (10+0.1 @ 1 thread) LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 10471 W: 2364 L: 2220 D: 5887 http://tests.stockfishchess.org/tests/view/5d087ee20ebc5925cf0a6381 passed the additional non-regression tests at 2 and 4 threads 20+0.2 TC. The code was rebased on master prior to testing. 2 threads: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 218863 W: 40927 L: 41153 D: 136783 http://tests.stockfishchess.org/tests/view/5d18c6c30ebc5925cf0b9566 4threads: LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 16839 W: 3017 L: 2889 D: 10933 http://tests.stockfishchess.org/tests/view/5d18c6ea0ebc5925cf0b9568 No functional change.
2019-07-01 06:07:23 -06:00
(*location).thread.store(nullptr, std::memory_order_relaxed);
}
bool marked() { return otherThread; }
private:
Breadcrumb* location;
bool otherThread, owning;
};
template <NodeType NT>
Value search(Position& pos, Stack* ss, Value alpha, Value beta, Depth depth, bool cutNode);
template <NodeType NT>
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);
void update_all_stats(const Position& pos, Stack* ss, Move bestMove, Value bestValue, Value beta, Square prevSq,
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;
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((23.4 + 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();
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
{
for (Thread* th : Threads)
{
th->bestMoveChanges = 0;
if (th != this)
th->start_searching();
}
Thread::search(); // Let's 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
for (Thread* th : Threads)
if (th != this)
th->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;
// Check if there are threads with a better score than main thread
if ( Options["MultiPV"] == 1
&& !Limits.depth
UCI_Elo implementation (#2225) This exploits the recent fractional Skill Level, and is a result from some discussion in #2221 and the older #758. Basically, if UCI_LimitStrength is set, it will internally convert UCI_Elo to a matching fractional Skill Level. The Elo estimate is based on games at TC 60+0.6, Hash 64Mb, 8moves_v3.pgn, rated with Ordo, anchored to goldfish1.13 (CCRL 40/4 ~2000). Note that this is mostly about internal consistency, the anchoring to CCRL is a bit weak, e.g. within this tournament, goldfish and sungorus only have a 200Elo difference, their rating difference on CCRL is 300Elo. I propose that we continue to expose 'Skill Level' as an UCI option, for backwards compatibility. The result of a tournament under those conditions are given by the following table, where the player name reflects the UCI_Elo. # PLAYER : RATING ERROR POINTS PLAYED (%) CFS(%) 1 Elo2837 : 2792.2 50.8 536.5 711 75 100 2 Elo2745 : 2739.0 49.0 487.5 711 69 100 3 Elo2654 : 2666.4 49.2 418.0 711 59 100 4 Elo2562 : 2604.5 38.5 894.5 1383 65 100 5 Elo2471 : 2515.2 38.1 651.5 924 71 100 6 Elo2380 : 2365.9 35.4 478.5 924 52 100 7 Elo2289 : 2290.0 28.0 864.0 1596 54 100 8 sungorus1.4 : 2204.9 27.8 680.5 1596 43 60 9 Elo2197 : 2201.1 30.1 523.5 924 57 100 10 Elo2106 : 2103.8 24.5 730.5 1428 51 100 11 Elo2014 : 2030.5 30.3 377.5 756 50 98 12 goldfish1.13 : 2000.0 ---- 511.0 1428 36 100 13 Elo1923 : 1928.5 30.9 641.5 1260 51 100 14 Elo1831 : 1829.0 42.1 370.5 756 49 100 15 Elo1740 : 1738.3 42.9 277.5 756 37 100 16 Elo1649 : 1625.0 42.1 525.5 1260 42 100 17 Elo1558 : 1521.5 49.9 298.0 756 39 100 18 Elo1467 : 1471.3 51.3 246.5 756 33 100 19 Elo1375 : 1407.1 51.9 183.0 756 24 --- It can be observed that all set Elos correspond within the error bars with the observed Ordo rating. No functional change
2019-07-14 06:47:50 -06:00
&& !(Skill(Options["Skill Level"]).enabled() || Options["UCI_LimitStrength"])
&& rootMoves[0].pv[0] != MOVE_NONE)
{
std::map<Move, int64_t> votes;
Introduce voting system for best move selection Introduce voting system for best move selction in multi-threads mode. Joint work with Stefan Geschwentner, based on ideas introduced by Michael Stembera. Moves are upvoted by every thread using the margin to the minimum score across threads and the completed depth. First thread voting for the winner move is selected as best thread. Passed STC, LTC. A further LTC test with only 4 threads failed with positive score. A LTC with 31 threads was stopped with LLR 0.77 after 25k games to avoid use of excessive resources (equivalent to 1.5M STC games). Similar ideas were proposed by Michael Stembera 2 years ago #507, #508. This implementation seems simpler and more understandable, the results slightly more promising. Further possible work: 1) Tweak of the formula using for assigning votes. 2) Use a different baseline for the score dependent part: maximum score or winning probability could make more sense. 3) Assign votes in `Thread::Search` as iterations are completed and use voting results to stop search. 4) Select best thread as the threads voting for best move with the highest completed depth or, alternatively, vote on PV moves. Link to SPRT tests [stopped LTC, 31 threads 20+0.02](http://tests.stockfishchess.org/tests/view/5b61dc090ebc5902bdb95192) LLR: 0.77 (-2.94,2.94) [0.00,5.00] Total: 25602 W: 3977 L: 3850 D: 17775 Elo: 1.70 [-0.68,4.07] (95%) [passed LTC, 8 threads 20+0.02](http://tests.stockfishchess.org/tests/view/5b5df5180ebc5902bdb9162d) LLR: 2.96 (-2.94,2.94) [0.00,5.00] Total: 44478 W: 7602 L: 7300 D: 29576 Elo: 1.92 [-0.29,3.94] (95%) [failed LTC, 4 threads 20+0.02](http://tests.stockfishchess.org/tests/view/5b5f39ef0ebc5902bdb92792) LLR: -2.94 (-2.94,2.94) [0.00,5.00] Total: 29922 W: 5286 L: 5285 D: 19351 Elo: 0.48 [-1.98,3.10] (95%) [passed STC, 4 threads 5+0.05](http://tests.stockfishchess.org/tests/view/5b5dbf0f0ebc5902bdb9131c) LLR: 2.97 (-2.94,2.94) [0.00,5.00] Total: 9108 W: 2033 L: 1858 D: 5217 Elo: 6.11 [1.26,10.89] (95%) No functional change (in simple threat mode)
2018-07-04 13:54:38 -06:00
Value minScore = this->rootMoves[0].score;
Bug fix: always choose shortest mate in multithread mode In current master, with the voting scheme the best thread selection may pick a non mate or not the shortest mate thread. This patch fixes this bug. Formatting suggestion by Jörg Oster. Related past pull requests: https://github.com/official-stockfish/Stockfish/pull/1074 https://github.com/official-stockfish/Stockfish/pull/1215 Passed a [-4..0] verification test with 3 threads: LLR: 2.95 (-2.94,2.94) [-4.00,0.00] Total: 57158 W: 11374 L: 11424 D: 34360 http://tests.stockfishchess.org/tests/view/5d22deb30ebc5925cf0caefd Closes https://github.com/official-stockfish/Stockfish/pull/2226 No functional change (in single threaded mode) ---------------------------------------------------- Comment by Jörg Oster Just one sample output to demonstrate the effect of this patch. 5 Threads, 1 GB Hash +---+---+---+---+---+---+---+---+ | r | | b | | | r | k | | +---+---+---+---+---+---+---+---+ | | | | n | | p | b | | +---+---+---+---+---+---+---+---+ | | | p | | p | | p | | +---+---+---+---+---+---+---+---+ | p | | | | | | P | | +---+---+---+---+---+---+---+---+ | P | p | | | B | | N | Q | +---+---+---+---+---+---+---+---+ | | q | | | | | P | | +---+---+---+---+---+---+---+---+ | | | R | | | P | | | +---+---+---+---+---+---+---+---+ | | | | R | | | K | | +---+---+---+---+---+---+---+---+ Fen: r1b2rk1/3n1pb1/2p1p1p1/p5P1/Pp2B1NQ/1q4P1/2R2P2/3R2K1 w - - 8 34 Key: 38B4CA1067D4F477 Checkers: ucinewgame isready readyok go mate 17 searchmoves d1d7 info depth 65 seldepth 36 multipv 1 score mate 18 nodes 785875935 nps 8650448 hashfull 1000 tbhits 0 time 90848 pv d1d7 c8d7 g4f6 g7f6 g5f6 b3a3 g1g2 a3a1 h4g5 a1f6 g5f6 e6e5 c2c1 d7h3 g2h3 a8a6 h3g2 c6c5 f6a6 g8g7 c1c5 f7f6 a6e6 f8f7 c5c8 f6f5 e4d5 g7h6 e6f7 f5f4 f7e7 f4f3 d5f3 b4b3 c8h8 info depth 63 seldepth 36 multipv 1 score mate 17 nodes 785875935 nps 8650448 hashfull 1000 tbhits 0 time 90848 pv d1d7 c8d7 g4f6 g7f6 g5f6 b3a3 g1g2 a3a1 h4g5 a1f6 g5f6 e6e5 c2c1 d7h3 g2h3 a8a6 c1d1 b4b3 h3g2 c6c5 f6a6 g8g7 d1d7 g7g8 a6f6 b3b2 e4g6 b2b1q g6f7 f8f7 f6f7 g8h8 f7g7 bestmove d1d7 ponder c8d7
2019-07-07 19:36:57 -06:00
// Find out minimum score
for (Thread* th: Threads)
Introduce voting system for best move selection Introduce voting system for best move selction in multi-threads mode. Joint work with Stefan Geschwentner, based on ideas introduced by Michael Stembera. Moves are upvoted by every thread using the margin to the minimum score across threads and the completed depth. First thread voting for the winner move is selected as best thread. Passed STC, LTC. A further LTC test with only 4 threads failed with positive score. A LTC with 31 threads was stopped with LLR 0.77 after 25k games to avoid use of excessive resources (equivalent to 1.5M STC games). Similar ideas were proposed by Michael Stembera 2 years ago #507, #508. This implementation seems simpler and more understandable, the results slightly more promising. Further possible work: 1) Tweak of the formula using for assigning votes. 2) Use a different baseline for the score dependent part: maximum score or winning probability could make more sense. 3) Assign votes in `Thread::Search` as iterations are completed and use voting results to stop search. 4) Select best thread as the threads voting for best move with the highest completed depth or, alternatively, vote on PV moves. Link to SPRT tests [stopped LTC, 31 threads 20+0.02](http://tests.stockfishchess.org/tests/view/5b61dc090ebc5902bdb95192) LLR: 0.77 (-2.94,2.94) [0.00,5.00] Total: 25602 W: 3977 L: 3850 D: 17775 Elo: 1.70 [-0.68,4.07] (95%) [passed LTC, 8 threads 20+0.02](http://tests.stockfishchess.org/tests/view/5b5df5180ebc5902bdb9162d) LLR: 2.96 (-2.94,2.94) [0.00,5.00] Total: 44478 W: 7602 L: 7300 D: 29576 Elo: 1.92 [-0.29,3.94] (95%) [failed LTC, 4 threads 20+0.02](http://tests.stockfishchess.org/tests/view/5b5f39ef0ebc5902bdb92792) LLR: -2.94 (-2.94,2.94) [0.00,5.00] Total: 29922 W: 5286 L: 5285 D: 19351 Elo: 0.48 [-1.98,3.10] (95%) [passed STC, 4 threads 5+0.05](http://tests.stockfishchess.org/tests/view/5b5dbf0f0ebc5902bdb9131c) LLR: 2.97 (-2.94,2.94) [0.00,5.00] Total: 9108 W: 2033 L: 1858 D: 5217 Elo: 6.11 [1.26,10.89] (95%) No functional change (in simple threat mode)
2018-07-04 13:54:38 -06:00
minScore = std::min(minScore, th->rootMoves[0].score);
// Vote according to score and depth, and select the best thread
for (Thread* th : Threads)
{
votes[th->rootMoves[0].pv[0]] +=
(th->rootMoves[0].score - minScore + 14) * int(th->completedDepth);
Introduce voting system for best move selection Introduce voting system for best move selction in multi-threads mode. Joint work with Stefan Geschwentner, based on ideas introduced by Michael Stembera. Moves are upvoted by every thread using the margin to the minimum score across threads and the completed depth. First thread voting for the winner move is selected as best thread. Passed STC, LTC. A further LTC test with only 4 threads failed with positive score. A LTC with 31 threads was stopped with LLR 0.77 after 25k games to avoid use of excessive resources (equivalent to 1.5M STC games). Similar ideas were proposed by Michael Stembera 2 years ago #507, #508. This implementation seems simpler and more understandable, the results slightly more promising. Further possible work: 1) Tweak of the formula using for assigning votes. 2) Use a different baseline for the score dependent part: maximum score or winning probability could make more sense. 3) Assign votes in `Thread::Search` as iterations are completed and use voting results to stop search. 4) Select best thread as the threads voting for best move with the highest completed depth or, alternatively, vote on PV moves. Link to SPRT tests [stopped LTC, 31 threads 20+0.02](http://tests.stockfishchess.org/tests/view/5b61dc090ebc5902bdb95192) LLR: 0.77 (-2.94,2.94) [0.00,5.00] Total: 25602 W: 3977 L: 3850 D: 17775 Elo: 1.70 [-0.68,4.07] (95%) [passed LTC, 8 threads 20+0.02](http://tests.stockfishchess.org/tests/view/5b5df5180ebc5902bdb9162d) LLR: 2.96 (-2.94,2.94) [0.00,5.00] Total: 44478 W: 7602 L: 7300 D: 29576 Elo: 1.92 [-0.29,3.94] (95%) [failed LTC, 4 threads 20+0.02](http://tests.stockfishchess.org/tests/view/5b5f39ef0ebc5902bdb92792) LLR: -2.94 (-2.94,2.94) [0.00,5.00] Total: 29922 W: 5286 L: 5285 D: 19351 Elo: 0.48 [-1.98,3.10] (95%) [passed STC, 4 threads 5+0.05](http://tests.stockfishchess.org/tests/view/5b5dbf0f0ebc5902bdb9131c) LLR: 2.97 (-2.94,2.94) [0.00,5.00] Total: 9108 W: 2033 L: 1858 D: 5217 Elo: 6.11 [1.26,10.89] (95%) No functional change (in simple threat mode)
2018-07-04 13:54:38 -06:00
Bug fix: always choose shortest mate in multithread mode In current master, with the voting scheme the best thread selection may pick a non mate or not the shortest mate thread. This patch fixes this bug. Formatting suggestion by Jörg Oster. Related past pull requests: https://github.com/official-stockfish/Stockfish/pull/1074 https://github.com/official-stockfish/Stockfish/pull/1215 Passed a [-4..0] verification test with 3 threads: LLR: 2.95 (-2.94,2.94) [-4.00,0.00] Total: 57158 W: 11374 L: 11424 D: 34360 http://tests.stockfishchess.org/tests/view/5d22deb30ebc5925cf0caefd Closes https://github.com/official-stockfish/Stockfish/pull/2226 No functional change (in single threaded mode) ---------------------------------------------------- Comment by Jörg Oster Just one sample output to demonstrate the effect of this patch. 5 Threads, 1 GB Hash +---+---+---+---+---+---+---+---+ | r | | b | | | r | k | | +---+---+---+---+---+---+---+---+ | | | | n | | p | b | | +---+---+---+---+---+---+---+---+ | | | p | | p | | p | | +---+---+---+---+---+---+---+---+ | p | | | | | | P | | +---+---+---+---+---+---+---+---+ | P | p | | | B | | N | Q | +---+---+---+---+---+---+---+---+ | | q | | | | | P | | +---+---+---+---+---+---+---+---+ | | | R | | | P | | | +---+---+---+---+---+---+---+---+ | | | | R | | | K | | +---+---+---+---+---+---+---+---+ Fen: r1b2rk1/3n1pb1/2p1p1p1/p5P1/Pp2B1NQ/1q4P1/2R2P2/3R2K1 w - - 8 34 Key: 38B4CA1067D4F477 Checkers: ucinewgame isready readyok go mate 17 searchmoves d1d7 info depth 65 seldepth 36 multipv 1 score mate 18 nodes 785875935 nps 8650448 hashfull 1000 tbhits 0 time 90848 pv d1d7 c8d7 g4f6 g7f6 g5f6 b3a3 g1g2 a3a1 h4g5 a1f6 g5f6 e6e5 c2c1 d7h3 g2h3 a8a6 h3g2 c6c5 f6a6 g8g7 c1c5 f7f6 a6e6 f8f7 c5c8 f6f5 e4d5 g7h6 e6f7 f5f4 f7e7 f4f3 d5f3 b4b3 c8h8 info depth 63 seldepth 36 multipv 1 score mate 17 nodes 785875935 nps 8650448 hashfull 1000 tbhits 0 time 90848 pv d1d7 c8d7 g4f6 g7f6 g5f6 b3a3 g1g2 a3a1 h4g5 a1f6 g5f6 e6e5 c2c1 d7h3 g2h3 a8a6 c1d1 b4b3 h3g2 c6c5 f6a6 g8g7 d1d7 g7g8 a6f6 b3b2 e4g6 b2b1q g6f7 f8f7 f6f7 g8h8 f7g7 bestmove d1d7 ponder c8d7
2019-07-07 19:36:57 -06:00
if (bestThread->rootMoves[0].score >= VALUE_MATE_IN_MAX_PLY)
{
// Make sure we pick the shortest mate
if (th->rootMoves[0].score > bestThread->rootMoves[0].score)
bestThread = th;
}
else if ( th->rootMoves[0].score >= VALUE_MATE_IN_MAX_PLY
|| votes[th->rootMoves[0].pv[0]] > votes[bestThread->rootMoves[0].pv[0]])
bestThread = th;
}
}
previousScore = 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 statScores 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
ss->pv = pv;
bestValue = delta = alpha = -VALUE_INFINITE;
beta = VALUE_INFINITE;
if (mainThread)
{
if (mainThread->previousScore == 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->previousScore;
}
size_t multiPV = Options["MultiPV"];
UCI_Elo implementation (#2225) This exploits the recent fractional Skill Level, and is a result from some discussion in #2221 and the older #758. Basically, if UCI_LimitStrength is set, it will internally convert UCI_Elo to a matching fractional Skill Level. The Elo estimate is based on games at TC 60+0.6, Hash 64Mb, 8moves_v3.pgn, rated with Ordo, anchored to goldfish1.13 (CCRL 40/4 ~2000). Note that this is mostly about internal consistency, the anchoring to CCRL is a bit weak, e.g. within this tournament, goldfish and sungorus only have a 200Elo difference, their rating difference on CCRL is 300Elo. I propose that we continue to expose 'Skill Level' as an UCI option, for backwards compatibility. The result of a tournament under those conditions are given by the following table, where the player name reflects the UCI_Elo. # PLAYER : RATING ERROR POINTS PLAYED (%) CFS(%) 1 Elo2837 : 2792.2 50.8 536.5 711 75 100 2 Elo2745 : 2739.0 49.0 487.5 711 69 100 3 Elo2654 : 2666.4 49.2 418.0 711 59 100 4 Elo2562 : 2604.5 38.5 894.5 1383 65 100 5 Elo2471 : 2515.2 38.1 651.5 924 71 100 6 Elo2380 : 2365.9 35.4 478.5 924 52 100 7 Elo2289 : 2290.0 28.0 864.0 1596 54 100 8 sungorus1.4 : 2204.9 27.8 680.5 1596 43 60 9 Elo2197 : 2201.1 30.1 523.5 924 57 100 10 Elo2106 : 2103.8 24.5 730.5 1428 51 100 11 Elo2014 : 2030.5 30.3 377.5 756 50 98 12 goldfish1.13 : 2000.0 ---- 511.0 1428 36 100 13 Elo1923 : 1928.5 30.9 641.5 1260 51 100 14 Elo1831 : 1829.0 42.1 370.5 756 49 100 15 Elo1740 : 1738.3 42.9 277.5 756 37 100 16 Elo1649 : 1625.0 42.1 525.5 1260 42 100 17 Elo1558 : 1521.5 49.9 298.0 756 39 100 18 Elo1467 : 1471.3 51.3 246.5 756 33 100 19 Elo1375 : 1407.1 51.9 183.0 756 24 --- It can be observed that all set Elos correspond within the error bars with the observed Ordo rating. No functional change
2019-07-14 06:47:50 -06:00
// Pick integer skill levels, but non-deterministically round up or down
// such that the average integer skill corresponds to the input floating point one.
UCI_Elo implementation (#2225) This exploits the recent fractional Skill Level, and is a result from some discussion in #2221 and the older #758. Basically, if UCI_LimitStrength is set, it will internally convert UCI_Elo to a matching fractional Skill Level. The Elo estimate is based on games at TC 60+0.6, Hash 64Mb, 8moves_v3.pgn, rated with Ordo, anchored to goldfish1.13 (CCRL 40/4 ~2000). Note that this is mostly about internal consistency, the anchoring to CCRL is a bit weak, e.g. within this tournament, goldfish and sungorus only have a 200Elo difference, their rating difference on CCRL is 300Elo. I propose that we continue to expose 'Skill Level' as an UCI option, for backwards compatibility. The result of a tournament under those conditions are given by the following table, where the player name reflects the UCI_Elo. # PLAYER : RATING ERROR POINTS PLAYED (%) CFS(%) 1 Elo2837 : 2792.2 50.8 536.5 711 75 100 2 Elo2745 : 2739.0 49.0 487.5 711 69 100 3 Elo2654 : 2666.4 49.2 418.0 711 59 100 4 Elo2562 : 2604.5 38.5 894.5 1383 65 100 5 Elo2471 : 2515.2 38.1 651.5 924 71 100 6 Elo2380 : 2365.9 35.4 478.5 924 52 100 7 Elo2289 : 2290.0 28.0 864.0 1596 54 100 8 sungorus1.4 : 2204.9 27.8 680.5 1596 43 60 9 Elo2197 : 2201.1 30.1 523.5 924 57 100 10 Elo2106 : 2103.8 24.5 730.5 1428 51 100 11 Elo2014 : 2030.5 30.3 377.5 756 50 98 12 goldfish1.13 : 2000.0 ---- 511.0 1428 36 100 13 Elo1923 : 1928.5 30.9 641.5 1260 51 100 14 Elo1831 : 1829.0 42.1 370.5 756 49 100 15 Elo1740 : 1738.3 42.9 277.5 756 37 100 16 Elo1649 : 1625.0 42.1 525.5 1260 42 100 17 Elo1558 : 1521.5 49.9 298.0 756 39 100 18 Elo1467 : 1471.3 51.3 246.5 756 33 100 19 Elo1375 : 1407.1 51.9 183.0 756 24 --- It can be observed that all set Elos correspond within the error bars with the observed Ordo rating. No functional change
2019-07-14 06:47:50 -06:00
// UCI_Elo is converted 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.
PRNG rng(now());
UCI_Elo implementation (#2225) This exploits the recent fractional Skill Level, and is a result from some discussion in #2221 and the older #758. Basically, if UCI_LimitStrength is set, it will internally convert UCI_Elo to a matching fractional Skill Level. The Elo estimate is based on games at TC 60+0.6, Hash 64Mb, 8moves_v3.pgn, rated with Ordo, anchored to goldfish1.13 (CCRL 40/4 ~2000). Note that this is mostly about internal consistency, the anchoring to CCRL is a bit weak, e.g. within this tournament, goldfish and sungorus only have a 200Elo difference, their rating difference on CCRL is 300Elo. I propose that we continue to expose 'Skill Level' as an UCI option, for backwards compatibility. The result of a tournament under those conditions are given by the following table, where the player name reflects the UCI_Elo. # PLAYER : RATING ERROR POINTS PLAYED (%) CFS(%) 1 Elo2837 : 2792.2 50.8 536.5 711 75 100 2 Elo2745 : 2739.0 49.0 487.5 711 69 100 3 Elo2654 : 2666.4 49.2 418.0 711 59 100 4 Elo2562 : 2604.5 38.5 894.5 1383 65 100 5 Elo2471 : 2515.2 38.1 651.5 924 71 100 6 Elo2380 : 2365.9 35.4 478.5 924 52 100 7 Elo2289 : 2290.0 28.0 864.0 1596 54 100 8 sungorus1.4 : 2204.9 27.8 680.5 1596 43 60 9 Elo2197 : 2201.1 30.1 523.5 924 57 100 10 Elo2106 : 2103.8 24.5 730.5 1428 51 100 11 Elo2014 : 2030.5 30.3 377.5 756 50 98 12 goldfish1.13 : 2000.0 ---- 511.0 1428 36 100 13 Elo1923 : 1928.5 30.9 641.5 1260 51 100 14 Elo1831 : 1829.0 42.1 370.5 756 49 100 15 Elo1740 : 1738.3 42.9 277.5 756 37 100 16 Elo1649 : 1625.0 42.1 525.5 1260 42 100 17 Elo1558 : 1521.5 49.9 298.0 756 39 100 18 Elo1467 : 1471.3 51.3 246.5 756 33 100 19 Elo1375 : 1407.1 51.9 183.0 756 24 --- It can be observed that all set Elos correspond within the error bars with the observed Ordo rating. No functional change
2019-07-14 06:47:50 -06:00
double floatLevel = Options["UCI_LimitStrength"] ?
clamp(std::pow((Options["UCI_Elo"] - 1346.6) / 143.4, 1 / 0.806), 0.0, 20.0) :
double(Options["Skill Level"]);
int intLevel = int(floatLevel) +
((floatLevel - int(floatLevel)) * 1024 > rng.rand<unsigned>() % 1024 ? 1 : 0);
Skill skill(intLevel);
// 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());
Use exploration rate for reductions This patch measures how frequently search is exploring new configurations. This is done be computing a running average of ttHit. The ttHitAverage rate is somewhat low (e.g. 30% for startpos) in the normal case, while it can be very high if no progress is made (e.g. 90% for the fortress I used for testing). This information can be used to influence search. In this patch, by adjusting reductions if the rate > 50%. A first version (using a low ttHitAverageResolution and this 50% threshold) passed testing: STC LLR: 2.96 (-2.94,2.94) [-1.50,4.50] Total: 26425 W: 5837 L: 5650 D: 14938 http://tests.stockfishchess.org/tests/view/5dcede8b0ebc5902563258fa LTC LLR: 2.96 (-2.94,2.94) [0.00,3.50] Total: 32313 W: 5392 L: 5128 D: 21793 http://tests.stockfishchess.org/tests/view/5dcefb1f0ebc590256325c0e However, as discussed in pull request 2414, using a larger ttHitAverageResolution gives a better approximation of the underlying distributions. This needs a slight adjustment for the threshold as the new distributions are shifted a bit compared to the older ones, and this threshold seemingly is sensitive (we used 0.53125 here). https://github.com/official-stockfish/Stockfish/pull/2414 This final version also passed testing, and is used for the patch: STC LLR: 2.95 (-2.94,2.94) [-1.50,4.50] Total: 16025 W: 3555 L: 3399 D: 9071 http://tests.stockfishchess.org/tests/view/5dd070b90ebc5902579e20c2 LTC LLR: 2.96 (-2.94,2.94) [0.00,3.50] Total: 37576 W: 6277 L: 5998 D: 25301 http://tests.stockfishchess.org/tests/view/5dd0f58e6f544e798086f224 Closes https://github.com/official-stockfish/Stockfish/pull/2414 Bench: 4989584
2019-11-15 10:16:27 -07:00
ttHitAverage = ttHitAverageWindow * ttHitAverageResolution / 2;
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
int ct = int(Options["Contempt"]) * PawnValueEg / 100; // From centipawns
// In analysis mode, adjust contempt in accordance with user preference
if (Limits.infinite || Options["UCI_AnalyseMode"])
ct = Options["Analysis Contempt"] == "Off" ? 0
: Options["Analysis Contempt"] == "Both" ? ct
: Options["Analysis Contempt"] == "White" && us == BLACK ? -ct
: Options["Analysis Contempt"] == "Black" && us == WHITE ? -ct
: ct;
// Evaluation score is from the white point of view
Use per-thread dynamic contempt We now use per-thread dynamic contempt. This patch has the following effects: * for Threads=1: **non-functional** * for Threads>1: * with MultiPV=1: **no regression, little to no ELO gain** * with MultiPV>1: **clear improvement over master** First, I tried testing at standard MultiPV=1 play with [0,5] bounds. This yielded 2 yellow and 1 red test: 5+0.05, Threads=5: LLR: -2.96 (-2.94,2.94) [0.00,5.00] Total: 82689 W: 16439 L: 16190 D: 50060 http://tests.stockfishchess.org/tests/view/5aa93a5a0ebc5902952892e6 5+0.05, Threads=8: LLR: -2.96 (-2.94,2.94) [0.00,5.00] Total: 27164 W: 4974 L: 4983 D: 17207 http://tests.stockfishchess.org/tests/view/5ab2639b0ebc5902a6fbefd5 5+0.5, Threads=16: LLR: -2.97 (-2.94,2.94) [0.00,5.00] Total: 41396 W: 7127 L: 7082 D: 27187 http://tests.stockfishchess.org/tests/view/5ab124220ebc59029516cb62 Then, I tested with Skill Level=17 (implicitly MutliPV=4), showing a clear improvement: 5+0.05, Threads=5: LLR: 2.96 (-2.94,2.94) [0.00,5.00] Total: 3498 W: 1316 L: 1135 D: 1047 http://tests.stockfishchess.org/tests/view/5ab4b6580ebc5902932aeca2 Next, I tested the patch with MultiPV=1 again, this time checking for non-regression ([-3, 1]): 5+0.5, Threads=5: LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 65575 W: 12786 L: 12745 D: 40044 http://tests.stockfishchess.org/tests/view/5ab4e8500ebc5902932aecb3 Finally, I ran some tests with fixed number of games, checking if reverting dynamic contempt gains more elo with Skill Level=17 (i.e. MultiPV) than applying the "prevScore" fix and this patch. These tests showed, that this patch gains 15 ELO when playing with Skill Level=17: 5+0.05, Threads=3, "revert dynamic contempt" vs. "WITHOUT this patch": ELO: -11.43 +-4.1 (95%) LOS: 0.0% Total: 20000 W: 7085 L: 7743 D: 5172 http://tests.stockfishchess.org/tests/view/5ab636450ebc590295d88536 5+0.05, Threads=3, "revert dynamic contempt" vs. "WITH this patch": ELO: -26.42 +-4.1 (95%) LOS: 0.0% Total: 20000 W: 6661 L: 8179 D: 5160 http://tests.stockfishchess.org/tests/view/5ab62e680ebc590295d88524 --- ***FAQ*** **Why should this be commited?** I believe that the gain for multi-thread MultiPV search is a sufficient justification for this otherwise neutral change. I also believe this implementation of dynamic contempt is more logical, although this may be just my opinion. **Why is per-thread contempt better at MultiPV?** A likely explanation for the gain in MultiPV mode is that during search each thread independently switches between rootMoves and via the shared contempt score skews each other's evaluation. **Why were the tests done with Skill Level=17?** This was originally suggested by @Hanamuke and the idea is that with Skill Level Stockfish sometimes plays also moves it thinks are slightly sub-optimal and thus the quality of all moves offered by the MultiPV search is checked by the test. **Why are the ELO differences so huge?** This is most likely because of the nature of Skill Level mode -- since it slower and weaker than normal mode, bugs in evaluation have much greater effect. --- Closes https://github.com/official-stockfish/Stockfish/pull/1515. No functional change -- in single thread mode.
2018-03-30 02:47:05 -06:00
contempt = (us == WHITE ? make_score(ct, ct / 2)
: -make_score(ct, ct / 2));
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
// 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
// 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 previousScore = rootMoves[pvIdx].previousScore;
Adjust aspiration window with eval This patch changes the base aspiration window size depending on the absolute value of the previous iteration score, increasing it away from zero. This stems from the observation that the further away from zero, the more likely the evaluation is to change significantly with more depth. Conversely, a tighter aspiration window is more efficient when close to zero. A beneficial side-effect is that analysis of won positions without a quick mate is less prone to waste nodes in repeated fail-high that change the eval by tiny steps. STC: LLR: 2.96 (-2.94,2.94) [0.50,4.50] Total: 60102 W: 13327 L: 12868 D: 33907 http://tests.stockfishchess.org/tests/view/5d9a70d40ebc5902b6cf39ba LTC: LLR: 2.95 (-2.94,2.94) [0.00,3.50] Total: 155553 W: 25745 L: 25141 D: 104667 http://tests.stockfishchess.org/tests/view/5d9a7ca30ebc5902b6cf4028 Future work : the values used in this patch were only a reasonable guess. Further testing should unveil more optimal values. However, the aspiration window is rather tight with a minimum of 21 internal units, so discrete integers put a practical limitation to such tweaking. More exotic experiments around the aspiration window parameters could also be tried, but efficient conditions to adjust the base aspiration window size or allow it to not be centered on the current evaluation are not obvious. The aspiration window increases after a fail-high or a fail-low is another avenue to explore for potential enhancements. Bench: 4043748
2019-10-07 11:02:33 -06:00
delta = Value(21 + abs(previousScore) / 128);
alpha = std::max(previousScore - delta,-VALUE_INFINITE);
beta = std::min(previousScore + 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 contempt based on root move's previousScore (dynamic contempt)
int dct = ct + (111 - ct / 2) * previousScore / (abs(previousScore) + 176);
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
contempt = (us == WHITE ? make_score(dct, dct / 2)
: -make_score(dct, dct / 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)
{
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 adjustedDepth = std::max(1, rootDepth - failedHighCnt);
bestValue = ::search<PV>(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
{
++rootMoves[pvIdx].bestMoveCount;
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 = (354 + 6 * (mainThread->previousScore - bestValue)
+ 6 * (mainThread->iterValue[iterIdx] - bestValue)) / 692.0;
fallingEval = clamp(fallingEval, 0.5, 1.5);
// If the bestMove is stable over several iterations, reduce time accordingly
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
timeReduction = lastBestMoveDepth + 9 < completedDepth ? 1.97 : 0.98;
double reduction = (1.36 + mainThread->previousTimeReduction) / (2.29 * 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 + totBestMoveChanges / Threads.size();
// Stop the search if we have only one legal move, or if available time elapsed
if ( rootMoves.size() == 1
|| Time.elapsed() > Time.optimum() * fallingEval * reduction * bestMoveInstability)
{
// 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;
}
}
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 NT>
Value search(Position& pos, Stack* ss, Value alpha, Value beta, Depth depth, bool cutNode) {
constexpr bool PvNode = NT == PV;
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
const bool rootNode = PvNode && ss->ply == 0;
// Check if we have an upcoming move which draws by repetition, or
// if the opponent had an alternative move earlier to this position.
if ( pos.rule50_count() >= 3
&& alpha < VALUE_DRAW
&& !rootNode
&& 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<NT>(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;
TTEntry* tte;
Key posKey;
Move ttMove, move, excludedMove, bestMove;
Depth extension, newDepth;
Value bestValue, value, ttValue, eval, maxValue;
bool ttHit, ttPv, inCheck, givesCheck, improving, didLMR, priorCapture;
bool captureOrPromotion, doFullDepthSearch, moveCountPruning, ttCapture, singularLMR;
Piece movedPiece;
int moveCount, captureCount, quietCount;
// Step 1. Initialize node
Thread* thisThread = pos.this_thread();
inCheck = pos.checkers();
priorCapture = pos.captured_piece();
Color us = pos.side_to_move();
moveCount = 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 && !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);
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
(ss+1)->ply = ss->ply + 1;
(ss+1)->excludedMove = bestMove = MOVE_NONE;
(ss+2)->killers[0] = (ss+2)->killers[1] = MOVE_NONE;
Square prevSq = to_sq((ss-1)->currentMove);
// 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+4)->statScore = 0;
else
(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 = pos.key() ^ Key(excludedMove << 16); // Isn't a very good hash
tte = TT.probe(posKey, ttHit);
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
ttValue = ttHit ? value_from_tt(tte->value(), ss->ply, pos.rule50_count()) : VALUE_NONE;
ttMove = rootNode ? thisThread->rootMoves[thisThread->pvIdx].pv[0]
: ttHit ? tte->move() : MOVE_NONE;
ttPv = PvNode || (ttHit && tte->is_pv());
Use exploration rate for reductions This patch measures how frequently search is exploring new configurations. This is done be computing a running average of ttHit. The ttHitAverage rate is somewhat low (e.g. 30% for startpos) in the normal case, while it can be very high if no progress is made (e.g. 90% for the fortress I used for testing). This information can be used to influence search. In this patch, by adjusting reductions if the rate > 50%. A first version (using a low ttHitAverageResolution and this 50% threshold) passed testing: STC LLR: 2.96 (-2.94,2.94) [-1.50,4.50] Total: 26425 W: 5837 L: 5650 D: 14938 http://tests.stockfishchess.org/tests/view/5dcede8b0ebc5902563258fa LTC LLR: 2.96 (-2.94,2.94) [0.00,3.50] Total: 32313 W: 5392 L: 5128 D: 21793 http://tests.stockfishchess.org/tests/view/5dcefb1f0ebc590256325c0e However, as discussed in pull request 2414, using a larger ttHitAverageResolution gives a better approximation of the underlying distributions. This needs a slight adjustment for the threshold as the new distributions are shifted a bit compared to the older ones, and this threshold seemingly is sensitive (we used 0.53125 here). https://github.com/official-stockfish/Stockfish/pull/2414 This final version also passed testing, and is used for the patch: STC LLR: 2.95 (-2.94,2.94) [-1.50,4.50] Total: 16025 W: 3555 L: 3399 D: 9071 http://tests.stockfishchess.org/tests/view/5dd070b90ebc5902579e20c2 LTC LLR: 2.96 (-2.94,2.94) [0.00,3.50] Total: 37576 W: 6277 L: 5998 D: 25301 http://tests.stockfishchess.org/tests/view/5dd0f58e6f544e798086f224 Closes https://github.com/official-stockfish/Stockfish/pull/2414 Bench: 4989584
2019-11-15 10:16:27 -07:00
// thisThread->ttHitAverage can be used to approximate the running average of ttHit
thisThread->ttHitAverage = (ttHitAverageWindow - 1) * thisThread->ttHitAverage / ttHitAverageWindow
+ ttHitAverageResolution * ttHit;
// At non-PV nodes we check for an early TT cutoff
if ( !PvNode
&& ttHit
&& tte->depth() >= depth
&& 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)
{
if (!pos.capture_or_promotion(ttMove))
update_quiet_stats(pos, ss, ttMove, stat_bonus(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 (!pos.capture_or_promotion(ttMove))
{
int penalty = -stat_bonus(depth);
thisThread->mainHistory[us][from_to(ttMove)] << penalty;
update_continuation_histories(ss, pos.moved_piece(ttMove), to_sq(ttMove), penalty);
}
}
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;
value = wdl < -drawScore ? -VALUE_MATE + MAX_PLY + ss->ply + 1
: wdl > drawScore ? VALUE_MATE - 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), 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
}
}
}
// Step 6. Static evaluation of the position
if (inCheck)
{
ss->staticEval = eval = VALUE_NONE;
improving = false;
goto moves_loop; // Skip early pruning when in check
}
else if (ttHit)
{
// Never assume anything about values stored in TT
ss->staticEval = eval = tte->eval();
if (eval == VALUE_NONE)
ss->staticEval = eval = evaluate(pos);
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
{
if ((ss-1)->currentMove != MOVE_NULL)
{
int bonus = -(ss-1)->statScore / 512;
ss->staticEval = eval = evaluate(pos) + bonus;
}
else
ss->staticEval = eval = -(ss-1)->staticEval + 2 * Eval::Tempo;
tte->save(posKey, VALUE_NONE, ttPv, BOUND_NONE, DEPTH_NONE, MOVE_NONE, eval);
2011-10-31 01:28:59 -06:00
}
2008-08-31 23:59:13 -06:00
// Step 7. Razoring (~2 Elo)
if ( !rootNode // The required rootNode PV handling is not available in qsearch
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 < 2
&& eval <= alpha - RazorMargin)
return qsearch<NT>(pos, ss, alpha, beta);
improving = ss->staticEval >= (ss-2)->staticEval
|| (ss-2)->staticEval == VALUE_NONE;
// Step 8. Futility pruning: child node (~30 Elo)
if ( !PvNode
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 < 7
&& eval - futility_margin(depth, improving) >= beta
&& eval < VALUE_KNOWN_WIN) // Do not return unproven wins
return eval;
Document Elo impact of various parts of search In order to understand better the impact of various techniques used in search, Elo estimates have been run at STC for 60000 games (statistical error ~1.8 Elo), disabling each feature in turn. This should help future improvements and simplifications to pick suitable targets. The list of tests is: step 7 : http://tests.stockfishchess.org/tests/view/5abcbb4b0ebc5902926cf1ca step 8 : http://tests.stockfishchess.org/tests/view/5abcbb680ebc5902926cf1cc step 9 : http://tests.stockfishchess.org/tests/view/5abcbb850ebc5902926cf1ce step 10 : http://tests.stockfishchess.org/tests/view/5abcbbeb0ebc5902926cf1d2 step 11 : http://tests.stockfishchess.org/tests/view/5abcbbbf0ebc5902926cf1d0 step 13 : http://tests.stockfishchess.org/tests/view/5abd03680ebc5902926cf20b step 13a: http://tests.stockfishchess.org/tests/view/5abd29660ebc5902926cf22a step 13b: http://tests.stockfishchess.org/tests/view/5abd29820ebc5902926cf22c step 14 : http://tests.stockfishchess.org/tests/view/5abd03860ebc5902926cf20f step 14a: http://tests.stockfishchess.org/tests/view/5abd2b6c0ebc5902926cf230 step 14b: http://tests.stockfishchess.org/tests/view/5abd2b8d0ebc5902926cf232 step 14c: http://tests.stockfishchess.org/tests/view/5abd2bad0ebc5902926cf234 step 14d: http://tests.stockfishchess.org/tests/view/5abd2bcf0ebc5902926cf236 step 14e: http://tests.stockfishchess.org/tests/view/5abd2bf10ebc5902926cf238 This patch documents this in the code. Note that it will be a waste to recompute these estimates often, even a couple of [0,5] patches are unlikely to change them by more than the error bars. The interest of the Elo annotations in the code is not in the details, but in high- lighting trends such as razoring (2 Elo) and singular extensions (60 Elo). These estimates should be recomputed at most once a year. Closes https://github.com/official-stockfish/Stockfish/pull/1522 No functional change.
2018-03-31 19:13:29 -06:00
// Step 9. Null move search with verification search (~40 Elo)
if ( !PvNode
&& (ss-1)->currentMove != MOVE_NULL
&& (ss-1)->statScore < 22661
&& eval >= beta
&& eval >= ss->staticEval
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
&& ss->staticEval >= beta - 33 * depth + 299 - improving * 30
&& !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
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 R = (835 + 70 * depth) / 256 + std::min(int(eval - beta) / 185, 3);
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 scores
if (nullValue >= VALUE_MATE_IN_MAX_PLY)
nullValue = beta;
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 (thisThread->nmpMinPly || (abs(beta) < VALUE_KNOWN_WIN && depth < 13))
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
// Step 10. ProbCut (~10 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
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 >= 5
&& abs(beta) < VALUE_MATE_IN_MAX_PLY)
{
Value raisedBeta = std::min(beta + 191 - 46 * improving, VALUE_INFINITE);
MovePicker mp(pos, ttMove, raisedBeta - ss->staticEval, &thisThread->captureHistory);
int probCutCount = 0;
while ( (move = mp.next_move()) != MOVE_NONE
&& probCutCount < 2 + 2 * cutNode)
if (move != excludedMove && pos.legal(move))
{
assert(pos.capture_or_promotion(move));
assert(depth >= 5);
captureOrPromotion = true;
probCutCount++;
ss->currentMove = move;
ss->continuationHistory = &thisThread->continuationHistory[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, -raisedBeta, -raisedBeta+1);
// If the qsearch held, perform the regular search
if (value >= raisedBeta)
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 = -search<NonPV>(pos, ss+1, -raisedBeta, -raisedBeta+1, depth - 4, !cutNode);
pos.undo_move(move);
if (value >= raisedBeta)
return value;
}
}
// Step 11. Internal iterative deepening (~2 Elo)
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 >= 7 && !ttMove)
{
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
search<NT>(pos, ss, alpha, beta, depth - 7, cutNode);
tte = TT.probe(posKey, ttHit);
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
ttValue = ttHit ? value_from_tt(tte->value(), ss->ply, pos.rule50_count()) : VALUE_NONE;
ttMove = ttHit ? tte->move() : MOVE_NONE;
2008-08-31 23:59:13 -06:00
}
moves_loop: // When in check, search starts from here
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->captureHistory,
contHist,
countermove,
ss->killers);
value = bestValue;
singularLMR = moveCountPruning = false;
ttCapture = ttMove && pos.capture_or_promotion(ttMove);
// Mark this node as being searched
Introduce coordination between searching threads (#2204) this patch improves threading performance by introducing some coordination between threads. The observation is that threading is an area where a lot of Elo can potentially be gained: https://github.com/glinscott/fishtest/wiki/UsefulData#elo-from-threading At STC, 8 threads gain roughly 320 Elo, vs sequential at the same time, however, loses 66 Elo against a single thread with 8x more time. This 66 Elo should be partially recoverable with improved threading. To improve threading, this patch introduces some LMR at nodes that are already being searched by other threads. This requires some coordination between threads, avoiding however synchronisation. To do so, threads leave a trail of breadcrumbs to mark the nodes they are searching. These breadcrumbs are stored in a small hash table, which is only probed at low plies (currently ply < 8). A couple of variants of this patch passed both STC and LTC threaded tests. I picked the simpler, more robust version. I expect that further tests can find further improvements. STC (5+0.05 @ 8 threads): LLR: 2.95 (-2.94,2.94) [0.50,4.50] Total: 26209 W: 5359 L: 5079 D: 15771 http://tests.stockfishchess.org/tests/view/5d0a9b030ebc5925cf0a8e6f LTC (20+0.2 @ 8 threads): LLR: 2.96 (-2.94,2.94) [0.00,3.50] Total: 34832 W: 5650 L: 5382 D: 23800 http://tests.stockfishchess.org/tests/view/5d0c67a20ebc5925cf0aafa7 other passed/tested variants: http://tests.stockfishchess.org/tests/view/5d0a9b030ebc5925cf0a8e6f http://tests.stockfishchess.org/tests/view/5d0c67ca0ebc5925cf0aafa9 http://tests.stockfishchess.org/tests/view/5d0c67810ebc5925cf0aafa3 http://tests.stockfishchess.org/tests/view/5d0958ca0ebc5925cf0a74c6 For the sequential code there is no change in bench, and an earlier version of this patch passed a non-regression test. STC (10+0.1 @ 1 thread) LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 10471 W: 2364 L: 2220 D: 5887 http://tests.stockfishchess.org/tests/view/5d087ee20ebc5925cf0a6381 passed the additional non-regression tests at 2 and 4 threads 20+0.2 TC. The code was rebased on master prior to testing. 2 threads: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 218863 W: 40927 L: 41153 D: 136783 http://tests.stockfishchess.org/tests/view/5d18c6c30ebc5925cf0b9566 4threads: LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 16839 W: 3017 L: 2889 D: 10933 http://tests.stockfishchess.org/tests/view/5d18c6ea0ebc5925cf0b9568 No functional change.
2019-07-01 06:07:23 -06:00
ThreadHolding th(thisThread, posKey, ss->ply);
// 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;
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 (~170 Elo)
if ( !rootNode
&& pos.non_pawn_material(us)
&& bestValue > VALUE_MATED_IN_MAX_PLY)
{
// Skip quiet moves if movecount exceeds our FutilityMoveCount threshold
moveCountPruning = moveCount >= futility_move_count(improving, depth);
if ( !captureOrPromotion
&& !givesCheck)
{
// Reduced depth of the next LMR search
int lmrDepth = std::max(newDepth - reduction(improving, depth, moveCount), 0);
// Countermoves based pruning (~20 Elo)
if ( lmrDepth < 4 + ((ss-1)->statScore > 0 || (ss-1)->moveCount == 1)
&& (*contHist[0])[movedPiece][to_sq(move)] < CounterMovePruneThreshold
&& (*contHist[1])[movedPiece][to_sq(move)] < CounterMovePruneThreshold)
continue;
// Futility pruning: parent node (~2 Elo)
if ( lmrDepth < 6
&& !inCheck
&& ss->staticEval + 250 + 211 * lmrDepth <= alpha)
continue;
// Prune moves with negative SEE (~10 Elo)
if (!pos.see_ge(move, Value(-(31 - std::min(lmrDepth, 18)) * lmrDepth * lmrDepth)))
continue;
}
else if (!pos.see_ge(move, Value(-199) * depth)) // (~20 Elo)
continue;
}
// Step 14. Extensions (~70 Elo)
2008-08-31 23:59:13 -06:00
// Singular extension search (~60 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.
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 >= 6
&& move == ttMove
&& !rootNode
&& !excludedMove // Avoid recursive singular search
/* && ttValue != VALUE_NONE Already implicit in the next condition */
&& abs(ttValue) < VALUE_KNOWN_WIN
&& (tte->bound() & BOUND_LOWER)
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
&& tte->depth() >= depth - 3
&& pos.legal(move))
{
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 singularBeta = ttValue - 2 * depth;
Depth halfDepth = depth / 2;
ss->excludedMove = move;
value = search<NonPV>(pos, ss, singularBeta - 1, singularBeta, halfDepth, 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;
singularLMR = true;
}
// 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;
}
// Check extension (~2 Elo)
else if ( givesCheck
&& (pos.is_discovery_check_on_king(~us, move) || pos.see_ge(move)))
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;
// Passed pawn extension
else if ( move == ss->killers[0]
&& pos.advanced_pawn_push(move)
&& pos.pawn_passed(us, to_sq(move)))
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;
// Last captures extension
else if ( PvNode
&& PieceValue[EG][pos.captured_piece()] > PawnValueEg
&& pos.non_pawn_material() <= 2 * RookValueMg)
extension = 1;
Extend castling independently of singular extension A curious feature of Stockfish's current extension code is its repeated use of "else if." In most cases, this makes no functional difference, because no more than one extension is applied; once one extension has been applied, the remaining ones can be safely ignored. However, if most singular extension search conditions are true, except "value < singularBeta", no non-singular extensions (e.g., castling) can be performed! Three tests were submitted, for three of Stockfish's four non-singular extensions. I excluded the shuffle extension, because historically there have been concerns about the fragility of its conditions, and I did not want to risk causing any serious search problems. - Modifying the passed pawn extension appeared roughly neutral at STC. At best, it appeared to be an improvement of less than 1 Elo. - Modifying check extension performed very poorly at STC - Modifying castling extension (this patch) produced a long "yellow" run at STC (insufficient to pass, but positive score) and a strong LTC. In simple terms, prior to this patch castling extension was occasionally not applied during search--on castling moves. The effect of this patch is to perform castling extension on more castling moves. It does so without adding any code complexity, simply by replacing an "else if" with "if" and reordering some existing code. STC: LLR: -2.96 (-2.94,2.94) [0.00,4.00] Total: 108114 W: 23877 L: 23615 D: 60622 http://tests.stockfishchess.org/tests/view/5d8d86bd0ebc590f3beb0c88 LTC: LLR: 2.96 (-2.94,2.94) [0.00,4.00] Total: 20862 W: 3517 L: 3298 D: 14047 http://tests.stockfishchess.org/tests/view/5d8d99cd0ebc590f3beb1899 Bench: 3728191 -------- Where do we go from here? - It seems strange to me that check extension performed so poorly -- clearly some of the singular extension conditions are also very important for check extension. I am not an expert in search, and I do not have any intuition about which of the eight conditions is/are the culprit. I will try a succession of eight STC tests to identify the relevant conditions, then try to replicate this PR for check extension. - Recent tests interacting with the castle extension may deserve retesting. I will shortly resubmit a few of my recent castling extension tweaks, rebased on this PR/commit. My deepest thanks to @noobpwnftw for the extraordinary CPU donation, and to all our other fishtest volunteers, who made it possible for a speculative LTC to pass in 70 minutes! Closes https://github.com/official-stockfish/Stockfish/pull/2331
2019-09-27 00:45:28 -06:00
// Castling extension
if (type_of(move) == CASTLING)
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;
// Add extension to new depth
newDepth += extension;
2008-08-31 23:59:13 -06:00
// Speculative prefetch as early as possible
prefetch(TT.first_entry(pos.key_after(move)));
// Check for legality just before making the move
if (!rootNode && !pos.legal(move))
{
ss->moveCount = --moveCount;
continue;
}
// Update the current move (this must be done after singular extension search)
ss->currentMove = move;
ss->continuationHistory = &thisThread->continuationHistory[inCheck]
[captureOrPromotion]
[movedPiece]
[to_sq(move)];
// Step 15. Make the move
pos.do_move(move, st, givesCheck);
// Step 16. Reduced depth search (LMR). If the move fails high it will be
// re-searched at full 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
if ( depth >= 3
&& moveCount > 1 + 2 * rootNode
&& (!rootNode || thisThread->best_move_count(move) == 0)
&& ( !captureOrPromotion
|| moveCountPruning
|| ss->staticEval + PieceValue[EG][pos.captured_piece()] <= alpha
|| cutNode
|| thisThread->ttHitAverage < 384 * ttHitAverageResolution * ttHitAverageWindow / 1024))
{
Depth r = reduction(improving, depth, moveCount);
Use exploration rate for reductions This patch measures how frequently search is exploring new configurations. This is done be computing a running average of ttHit. The ttHitAverage rate is somewhat low (e.g. 30% for startpos) in the normal case, while it can be very high if no progress is made (e.g. 90% for the fortress I used for testing). This information can be used to influence search. In this patch, by adjusting reductions if the rate > 50%. A first version (using a low ttHitAverageResolution and this 50% threshold) passed testing: STC LLR: 2.96 (-2.94,2.94) [-1.50,4.50] Total: 26425 W: 5837 L: 5650 D: 14938 http://tests.stockfishchess.org/tests/view/5dcede8b0ebc5902563258fa LTC LLR: 2.96 (-2.94,2.94) [0.00,3.50] Total: 32313 W: 5392 L: 5128 D: 21793 http://tests.stockfishchess.org/tests/view/5dcefb1f0ebc590256325c0e However, as discussed in pull request 2414, using a larger ttHitAverageResolution gives a better approximation of the underlying distributions. This needs a slight adjustment for the threshold as the new distributions are shifted a bit compared to the older ones, and this threshold seemingly is sensitive (we used 0.53125 here). https://github.com/official-stockfish/Stockfish/pull/2414 This final version also passed testing, and is used for the patch: STC LLR: 2.95 (-2.94,2.94) [-1.50,4.50] Total: 16025 W: 3555 L: 3399 D: 9071 http://tests.stockfishchess.org/tests/view/5dd070b90ebc5902579e20c2 LTC LLR: 2.96 (-2.94,2.94) [0.00,3.50] Total: 37576 W: 6277 L: 5998 D: 25301 http://tests.stockfishchess.org/tests/view/5dd0f58e6f544e798086f224 Closes https://github.com/official-stockfish/Stockfish/pull/2414 Bench: 4989584
2019-11-15 10:16:27 -07:00
// Decrease reduction if the ttHit running average is large
if (thisThread->ttHitAverage > 544 * ttHitAverageResolution * ttHitAverageWindow / 1024)
r--;
Introduce coordination between searching threads (#2204) this patch improves threading performance by introducing some coordination between threads. The observation is that threading is an area where a lot of Elo can potentially be gained: https://github.com/glinscott/fishtest/wiki/UsefulData#elo-from-threading At STC, 8 threads gain roughly 320 Elo, vs sequential at the same time, however, loses 66 Elo against a single thread with 8x more time. This 66 Elo should be partially recoverable with improved threading. To improve threading, this patch introduces some LMR at nodes that are already being searched by other threads. This requires some coordination between threads, avoiding however synchronisation. To do so, threads leave a trail of breadcrumbs to mark the nodes they are searching. These breadcrumbs are stored in a small hash table, which is only probed at low plies (currently ply < 8). A couple of variants of this patch passed both STC and LTC threaded tests. I picked the simpler, more robust version. I expect that further tests can find further improvements. STC (5+0.05 @ 8 threads): LLR: 2.95 (-2.94,2.94) [0.50,4.50] Total: 26209 W: 5359 L: 5079 D: 15771 http://tests.stockfishchess.org/tests/view/5d0a9b030ebc5925cf0a8e6f LTC (20+0.2 @ 8 threads): LLR: 2.96 (-2.94,2.94) [0.00,3.50] Total: 34832 W: 5650 L: 5382 D: 23800 http://tests.stockfishchess.org/tests/view/5d0c67a20ebc5925cf0aafa7 other passed/tested variants: http://tests.stockfishchess.org/tests/view/5d0a9b030ebc5925cf0a8e6f http://tests.stockfishchess.org/tests/view/5d0c67ca0ebc5925cf0aafa9 http://tests.stockfishchess.org/tests/view/5d0c67810ebc5925cf0aafa3 http://tests.stockfishchess.org/tests/view/5d0958ca0ebc5925cf0a74c6 For the sequential code there is no change in bench, and an earlier version of this patch passed a non-regression test. STC (10+0.1 @ 1 thread) LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 10471 W: 2364 L: 2220 D: 5887 http://tests.stockfishchess.org/tests/view/5d087ee20ebc5925cf0a6381 passed the additional non-regression tests at 2 and 4 threads 20+0.2 TC. The code was rebased on master prior to testing. 2 threads: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 218863 W: 40927 L: 41153 D: 136783 http://tests.stockfishchess.org/tests/view/5d18c6c30ebc5925cf0b9566 4threads: LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 16839 W: 3017 L: 2889 D: 10933 http://tests.stockfishchess.org/tests/view/5d18c6ea0ebc5925cf0b9568 No functional change.
2019-07-01 06:07:23 -06:00
// Reduction if other threads are searching this position.
if (th.marked())
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++;
Introduce coordination between searching threads (#2204) this patch improves threading performance by introducing some coordination between threads. The observation is that threading is an area where a lot of Elo can potentially be gained: https://github.com/glinscott/fishtest/wiki/UsefulData#elo-from-threading At STC, 8 threads gain roughly 320 Elo, vs sequential at the same time, however, loses 66 Elo against a single thread with 8x more time. This 66 Elo should be partially recoverable with improved threading. To improve threading, this patch introduces some LMR at nodes that are already being searched by other threads. This requires some coordination between threads, avoiding however synchronisation. To do so, threads leave a trail of breadcrumbs to mark the nodes they are searching. These breadcrumbs are stored in a small hash table, which is only probed at low plies (currently ply < 8). A couple of variants of this patch passed both STC and LTC threaded tests. I picked the simpler, more robust version. I expect that further tests can find further improvements. STC (5+0.05 @ 8 threads): LLR: 2.95 (-2.94,2.94) [0.50,4.50] Total: 26209 W: 5359 L: 5079 D: 15771 http://tests.stockfishchess.org/tests/view/5d0a9b030ebc5925cf0a8e6f LTC (20+0.2 @ 8 threads): LLR: 2.96 (-2.94,2.94) [0.00,3.50] Total: 34832 W: 5650 L: 5382 D: 23800 http://tests.stockfishchess.org/tests/view/5d0c67a20ebc5925cf0aafa7 other passed/tested variants: http://tests.stockfishchess.org/tests/view/5d0a9b030ebc5925cf0a8e6f http://tests.stockfishchess.org/tests/view/5d0c67ca0ebc5925cf0aafa9 http://tests.stockfishchess.org/tests/view/5d0c67810ebc5925cf0aafa3 http://tests.stockfishchess.org/tests/view/5d0958ca0ebc5925cf0a74c6 For the sequential code there is no change in bench, and an earlier version of this patch passed a non-regression test. STC (10+0.1 @ 1 thread) LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 10471 W: 2364 L: 2220 D: 5887 http://tests.stockfishchess.org/tests/view/5d087ee20ebc5925cf0a6381 passed the additional non-regression tests at 2 and 4 threads 20+0.2 TC. The code was rebased on master prior to testing. 2 threads: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 218863 W: 40927 L: 41153 D: 136783 http://tests.stockfishchess.org/tests/view/5d18c6c30ebc5925cf0b9566 4threads: LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 16839 W: 3017 L: 2889 D: 10933 http://tests.stockfishchess.org/tests/view/5d18c6ea0ebc5925cf0b9568 No functional change.
2019-07-01 06:07:23 -06:00
// Decrease reduction if position is or has been on the PV
if (ttPv)
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;
// Decrease reduction if opponent's move count is high (~10 Elo)
if ((ss-1)->moveCount > 15)
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
if (singularLMR)
r -= 2;
if (!captureOrPromotion)
{
// Increase reduction if ttMove is a capture (~0 Elo)
if (ttCapture)
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++;
// Increase reduction for cut nodes (~5 Elo)
if (cutNode)
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;
// Decrease reduction for moves that escape a capture. Filter out
// castling moves, because they are coded as "king captures rook" and
// hence break make_move(). (~5 Elo)
else if ( type_of(move) == NORMAL
&& !pos.see_ge(reverse_move(move)))
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;
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)]
- 4729;
// Reset statScore to zero if negative and most stats shows >= 0
if ( ss->statScore < 0
&& (*contHist[0])[movedPiece][to_sq(move)] >= 0
&& (*contHist[1])[movedPiece][to_sq(move)] >= 0
&& thisThread->mainHistory[us][from_to(move)] >= 0)
ss->statScore = 0;
// Decrease/increase reduction by comparing opponent's stat score (~10 Elo)
if (ss->statScore >= -99 && (ss-1)->statScore < -116)
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--;
else if ((ss-1)->statScore >= -117 && ss->statScore < -144)
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/increase reduction for moves with a good/bad history (~30 Elo)
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 -= ss->statScore / 16384;
}
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 = clamp(newDepth - r, 1, newDepth);
value = -search<NonPV>(pos, ss+1, -(alpha+1), -alpha, d, true);
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 (didLMR && !captureOrPromotion)
{
int bonus = value > alpha ? stat_bonus(newDepth)
: -stat_bonus(newDepth);
if (move == ss->killers[0])
bonus += bonus / 4;
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, 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: When
// the best move changes frequently, we allocate some more time.
if (moveCount > 1)
++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;
else
{
assert(value >= beta); // Fail high
ss->statScore = 0;
break;
}
}
}
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 || !inCheck || excludedMove || !MoveList<LEGAL>(pos).size());
if (!moveCount)
bestValue = excludedMove ? alpha
A better contempt implementation for Stockfish (#1325) * A better contempt implementation for Stockfish The round 2 of TCEC season 10 demonstrated the benefit of having a nice contempt implementation: it gives the strongest programs in the tournament the ability to slow down the game when they feel the position is slightly worse, prefering to stay in a complicated (even if slightly risky) middle game rather than simplifying by force into a drawn endgame. The current contempt implementation of Stockfish is inadequate, and this patch is an attempt to provide a better one. Passed STC non-regression test against master: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 83360 W: 15089 L: 15075 D: 53196 http://tests.stockfishchess.org/tests/view/5a1bf2de0ebc590ccbb8b370 This contempt implementation is showing promising results in certains situations. For instance, it obtained a nice +30 Elo gain when playing with contempt=40 against Stockfish 7, compared to current master: • master against SF 7 (20000 games at LTC): +121.2 Elo • this patch with contempt=40 (20000 games at LTC): +154.11 Elo This was the result of real cooperative work from the Stockfish team, with key ideas coming from Stefan Geschwentner (locutus2) and Chris Cain (ceebo) while most of the community helped with feedback and computer time. In this commit the bench is unchanged by default, but you can test at home with the new contempt in the UCI options. The style of play will change a lot when using contempt different of zero (I repeat: not done in this version by default, however)! The Stockfish team is still deliberating over the best default contempt value in self-play and the best contempt modeling strategy, to help users choosing a contempt value when playing against much weaker programs. These informations will be given in future commits when available :-) Bench: 5051254 * Remove the prefetch No functional change.
2017-12-04 23:25:42 -07:00
: inCheck ? mated_in(ss->ply) : VALUE_DRAW;
else if (bestMove)
update_all_stats(pos, ss, bestMove, bestValue, beta, prevSq,
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));
if (PvNode)
bestValue = std::min(bestValue, maxValue);
if (!excludedMove)
tte->save(posKey, value_to_tt(bestValue, ss->ply), 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 NT>
Value qsearch(Position& pos, Stack* ss, Value alpha, Value beta, Depth depth) {
2008-08-31 23:59:13 -06:00
constexpr bool PvNode = NT == 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;
TTEntry* tte;
Key posKey;
Move ttMove, move, bestMove;
Depth ttDepth;
Value bestValue, value, ttValue, futilityValue, futilityBase, oldAlpha;
bool ttHit, pvHit, inCheck, givesCheck, captureOrPromotion, evasionPrunable;
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();
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
(ss+1)->ply = ss->ply + 1;
bestMove = MOVE_NONE;
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 && !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 = inCheck || depth >= DEPTH_QS_CHECKS ? DEPTH_QS_CHECKS
: DEPTH_QS_NO_CHECKS;
// Transposition table lookup
posKey = pos.key();
tte = TT.probe(posKey, ttHit);
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
ttValue = ttHit ? value_from_tt(tte->value(), ss->ply, pos.rule50_count()) : VALUE_NONE;
More robust interaction of singular search and iid When iid (Internal iterative deepening) is invoked, the prior value of ttValue is not guaranteed to be VALUE_NONE. As such, it is currently possible to enter a state in which ttValue has a specific value which is inconsistent with tte->bound() and tte->depth(). Currently, ttValue is only used within the search in a context that prevents this situation from making a difference (and so this change is non-functional, but this is not guaranteed to remain the case in the future. For instance, just changing the tt depth condition in singular extension node to be tte->depth() >= depth - 4 * ONE_PLY instead of tte->depth() >= depth - 3 * ONE_PLY interacts badly with the absence of ttMove in iid. For the ttMove to become a singular extension candidate, singularExtensionNode needs to be true. With the current master, this requires that tte->depth() >= depth - 3 * ONE_PLY. This is not currently possible if tte comes from IID, since the depth 'd' used for the IID search is always less than depth - 4 * ONE_PLY for depth >= 8 * ONE_PLY (below depth 8 singularExtensionNode can never be true anyway). However, with DU-jdto/Stockfish@251281a , this condition can be met, and it is possible for singularExtensionNode to become true after IID. There are then two mechanisms by which this patch can affect the search: • If ttValue was VALUE_NONE prior to IID, the fact that this patch sets ttValue allows the 'ttValue != VALUE_NONE' condition of singularExtensionNode to be met. • If ttValue wasn't VALUE_NONE prior to IID, the fact that this patch modifies ttValue's value causes a different 'rBeta' to be calculated if the singular extension search is performed. Tested at STC for non-regression: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 76981 W: 17060 L: 17048 D: 42873 http://tests.stockfishchess.org/tests/view/5a7738b70ebc5902971a9868 No functional change
2018-02-24 17:14:29 -07:00
ttMove = ttHit ? tte->move() : MOVE_NONE;
pvHit = ttHit && tte->is_pv();
if ( !PvNode
&& 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 (inCheck)
{
ss->staticEval = VALUE_NONE;
bestValue = futilityBase = -VALUE_INFINITE;
}
else
{
if (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
ss->staticEval = bestValue =
(ss-1)->currentMove != MOVE_NULL ? evaluate(pos)
: -(ss-1)->staticEval + 2 * Eval::Tempo;
// Stand pat. Return immediately if static value is at least beta
if (bestValue >= beta)
{
if (!ttHit)
tte->save(posKey, value_to_tt(bestValue, ss->ply), pvHit, BOUND_LOWER,
DEPTH_NONE, MOVE_NONE, ss->staticEval);
return bestValue;
}
if (PvNode && bestValue > alpha)
alpha = bestValue;
futilityBase = bestValue + 153;
}
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 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));
givesCheck = pos.gives_check(move);
captureOrPromotion = pos.capture_or_promotion(move);
moveCount++;
2008-08-31 23:59:13 -06:00
// Futility pruning
if ( !inCheck
&& !givesCheck
&& futilityBase > -VALUE_KNOWN_WIN
&& !pos.advanced_pawn_push(move))
{
assert(type_of(move) != ENPASSANT); // Due to !pos.advanced_pawn_push
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
}
// Detect non-capture evasions that are candidates to be pruned
evasionPrunable = inCheck
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 != 0 || moveCount > 2)
&& bestValue > VALUE_MATED_IN_MAX_PLY
&& !pos.capture(move);
// Don't search moves with negative SEE values
if ( (!inCheck || evasionPrunable)
&& !(givesCheck && pos.is_discovery_check_on_king(~pos.side_to_move(), move))
&& !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)));
// Check for legality just before making the move
if (!pos.legal(move))
{
moveCount--;
continue;
}
ss->currentMove = move;
ss->continuationHistory = &thisThread->continuationHistory[inCheck]
[captureOrPromotion]
[pos.moved_piece(move)]
[to_sq(move)];
// Make and search the move
pos.do_move(move, st, givesCheck);
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<NT>(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 (inCheck && bestValue == -VALUE_INFINITE)
return mated_in(ss->ply); // Plies to mate from the root
2008-08-31 23:59:13 -06:00
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;
}
// value_to_tt() adjusts a mate score from "plies to mate from the root" to
// "plies to mate from the current position". Non-mate 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);
return v >= VALUE_MATE_IN_MAX_PLY ? v + ply
: v <= VALUE_MATED_IN_MAX_PLY ? v - ply : v;
}
// value_from_tt() is the inverse of value_to_tt(): It adjusts a mate score
// from the transposition table (which refers to the plies to mate/be mated
// from current position) to "plies to mate/be mated from the root".
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) {
return v == VALUE_NONE ? VALUE_NONE
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
: v >= VALUE_MATE_IN_MAX_PLY ? VALUE_MATE - v > 99 - r50c ? VALUE_MATE_IN_MAX_PLY : v - ply
: v <= VALUE_MATED_IN_MAX_PLY ? VALUE_MATE + v > 99 - r50c ? VALUE_MATED_IN_MAX_PLY : v + ply : 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,
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))
{
update_quiet_stats(pos, ss, bestMove, bonus2);
// Decrease all the 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
captureHistory[moved_piece][to_sq(bestMove)][captured] << bonus1;
// Extra penalty for a quiet TT or main killer move in previous ply when it gets refuted
if ( ((ss-1)->moveCount == 1 || ((ss-1)->currentMove == (ss-1)->killers[0]))
&& !pos.captured_piece())
update_continuation_histories(ss-1, pos.piece_on(prevSq), prevSq, -bonus1);
// Decrease all the 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, and -4 with current move.
void update_continuation_histories(Stack* ss, Piece pc, Square to, int bonus) {
for (int i : {1, 2, 4, 6})
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) {
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);
if (type_of(pos.moved_piece(move)) != PAWN)
thisThread->mainHistory[us][from_to(reverse_move(move))] << -bonus;
if (is_ok((ss-1)->currentMove))
{
Square prevSq = to_sq((ss-1)->currentMove);
thisThread->counterMoves[pos.piece_on(prevSq)][prevSq] = move;
}
}
// 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 weakness = 120 - 2 * level;
int maxScore = -VALUE_INFINITE;
// 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 = ( weakness * int(topScore - rootMoves[i].score)
+ delta * (rng.rand<unsigned>() % 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 = (i <= pvIdx && rootMoves[i].score != -VALUE_INFINITE);
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 == 1 && !updated)
continue;
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 = updated ? depth : depth - 1;
Value v = updated ? rootMoves[i].score : rootMoves[i].previousScore;
2015-01-18 00:05:05 -07:00
bool tb = TB::RootInTB && abs(v) < VALUE_MATE - 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 (!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;
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::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;
}
}