1
0
Fork 0
stockfish/src/ucioption.cpp

189 lines
6.0 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 <cassert>
#include <ostream>
#include <sstream>
2008-08-31 23:59:13 -06:00
#include "misc.h"
#include "search.h"
2008-08-31 23:59:13 -06:00
#include "thread.h"
#include "tt.h"
#include "uci.h"
2015-01-18 00:05:05 -07:00
#include "syzygy/tbprobe.h"
using std::string;
2008-08-31 23:59:13 -06:00
UCI::OptionsMap Options; // Global object
namespace UCI {
/// 'On change' actions, triggered by an option's value change
void on_clear_hash(const Option&) { Search::clear(); }
void on_hash_size(const Option& o) { TT.resize(o); }
void on_logger(const Option& o) { start_logger(o); }
void on_threads(const Option& o) { Threads.set(o); }
2015-01-18 00:05:05 -07:00
void on_tb_path(const Option& o) { Tablebases::init(o); }
/// Our case insensitive less() function as required by UCI protocol
bool CaseInsensitiveLess::operator() (const string& s1, const string& s2) const {
return std::lexicographical_compare(s1.begin(), s1.end(), s2.begin(), s2.end(),
[](char c1, char c2) { return tolower(c1) < tolower(c2); });
}
/// init() initializes the UCI options to their hard-coded default values
2008-08-31 23:59:13 -06:00
void init(OptionsMap& o) {
Allow for general transposition table sizes. (#1341) For efficiency reasons current master only allows for transposition table sizes that are N = 2^k in size, the index computation can be done efficiently as (hash % N) can be written instead as (hash & 2^k - 1). On a typical computer (with 4, 8... etc Gb of RAM), this implies roughly half the RAM is left unused in analysis. This issue was mentioned on fishcooking by Mindbreaker: http://tests.stockfishchess.org/tests/view/5a3587de0ebc590ccbb8be04 Recently a neat trick was proposed to map a hash into the range [0,N[ more efficiently than (hash % N) for general N, nearly as efficiently as (hash % 2^k): https://lemire.me/blog/2016/06/27/a-fast-alternative-to-the-modulo-reduction/ namely computing (hash * N / 2^32) for 32 bit hashes. This patch implements this trick and now allows for general hash sizes. Note that for N = 2^k this just amounts to using a different subset of bits from the hash. Master will use the lower k bits, this trick will use the upper k bits (of the 32 bit hash). There is no slowdown as measured with [-3, 1] test: http://tests.stockfishchess.org/tests/view/5a3587de0ebc590ccbb8be04 LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 128498 W: 23332 L: 23395 D: 81771 There are two (smaller) caveats: 1) the patch is implemented for a 32 bit hash (so that a 64 bit multiply can be used), this effectively limits the number of clusters that can be used to 2^32 or to 128Gb of transpostion table. That's a change in the maximum allowed TT size, which could bother those using 256Gb or more regularly. 2) Already in master, an excluded move is hashed into the position key in rather simple way, essentially only affecting the lower 16 bits of the key. This is OK in master, since bits 0-15 end up in the index, but not in the new scheme, which picks the higher bits. This is 'fixed' by shifting the excluded move a few bits up. Eventually a better hashing scheme seems wise. Despite these two caveats, I think this is a nice improvement in usability. Bench: 5346341
2017-12-18 08:32:21 -07:00
// at most 2^32 clusters.
constexpr int MaxHashMB = Is64Bit ? 131072 : 2048;
o["Debug Log File"] << Option("", on_logger);
o["Contempt"] << Option(24, -100, 100);
o["Analysis Contempt"] << Option("Both var Off var White var Black var Both", "Both");
o["Threads"] << Option(1, 1, 512, on_threads);
o["Hash"] << Option(16, 1, MaxHashMB, on_hash_size);
o["Clear Hash"] << Option(on_clear_hash);
o["Ponder"] << Option(false);
o["MultiPV"] << Option(1, 1, 500);
o["Skill Level"] << Option(20, 0, 20);
o["Move Overhead"] << Option(30, 0, 5000);
o["Minimum Thinking Time"] << Option(20, 0, 5000);
Tweak time management Using a SPSA tuning session to optimize the time management parameters. With SPSA tuning it is not always possible to say where improvements came from. Maybe some variables changed randomly or because result was not sensitive enough to them. So my explanation of changes will not be necessarily correct, but here it is. • When decrease of thinking time was added by Joost a few months ago if best move has not changed for several plies, one more competing indicator was introduced for the same purpose along with increase in score and absence of fail low at root. It seems that tuning put relatively more importance on that new indicator what allowed to save time. • Some of this saved time is distributed proportionally between all moves and some more time were given to moves when score dropped a lot or best move changed. • It looks also that SPSA redistributed more time from the beginning to later stages of game via other changes in variables - maybe because contempt made game to last longer or for whatever reason. All of this is just small tweaks here and there (a few percentages changes). STC (10+0.1): LLR: 2.96 (-2.94,2.94) [0.00,4.00] Total: 18970 W: 4268 L: 4029 D: 10673 http://tests.stockfishchess.org/tests/view/5a9291a40ebc590297cc8881 LTC (60+0.6): LLR: 2.95 (-2.94,2.94) [0.00,4.00] Total: 72027 W: 12263 L: 11878 D: 47886 http://tests.stockfishchess.org/tests/view/5a92d7510ebc590297cc88ef Additional non-regression tests at other time controls Sudden death 60s: LLR: 2.95 (-2.94,2.94) [-4.00,0.00] Total: 14444 W: 2715 L: 2608 D: 9121 http://tests.stockfishchess.org/tests/view/5a9445850ebc590297cc8a65 40 moves repeating at LTC: LLR: 2.95 (-2.94,2.94) [-4.00,0.00] Total: 10309 W: 1880 L: 1759 D: 6670 http://tests.stockfishchess.org/tests/view/5a9566ec0ebc590297cc8be1 This is a functional patch only for time management, but the bench does not reflect this because it uses fixed depth search, so the number of nodes does not change during bench. No functional change.
2018-02-28 04:36:36 -07:00
o["Slow Mover"] << Option(84, 10, 1000);
Add support for playing in 'nodes as time' mode When running more games in parallel, or simply when running a game with a background process, due to how OS scheduling works, there is no guarantee that the CPU resources allocated evenly between the two players. This introduces noise in the result that leads to unreliable result and in the worst cases can even invalidate the result. For instance in SF test framework we avoid running from clouds virtual machines because are a known source of very unstable CPU speed. To overcome this issue, without requiring changes to the GUI, the idea is to use searched nodes instead of time, and to convert time to available nodes upfront, at the beginning of the game. When nodestime UCI option is set at a given nodes per milliseconds (npmsec), at the beginning of the game (and only once), the engine reads the available time to think, sent by the GUI with 'go wtime x' UCI command. Then it translates time in available nodes (nodes = npmsec * x), then feeds available nodes instead of time to the time management logic and starts the search. During the search the engine checks the searched nodes against the available ones in such a way that all the time management logic still fully applies, and the game mimics a real one played on real time. When the search finishes, before returning best move, the total available nodes are updated, subtracting the real searched nodes. After the first move, the time information sent by the GUI is ignored, and the engine fully relies on the updated total available nodes to feed time management. To avoid time losses, the speed of the engine (npms) must be set to a value lower than real speed so that if the real TC is for instance 30 secs, and npms is half of the real speed, the game will last on average 15 secs, so much less than the TC limit, providing for a safety 'time buffer'. There are 2 main limitations with this mode. 1. Engine speed should be the same for both players, and this limits the approach to mainly parameter tuning patches. 2. Because npms is fixed while, in real engines, the speed increases toward endgame, this introduces an artifact that is equivalent to an altered time management. Namely it is like the time management gives less available time than what should be in standard case. May be the second limitation could be mitigated in a future with a smarter 'dynamic npms' approach. Tests shows that the standard deviation of the results with 'nodestime' is lower than in standard TC, as is expected because now all the introduced noise due the random speed variability of the engines during the game is fully removed. Original NIT idea by Michael Hoffman that shows how to play in NIT mode without requiring changes to the GUI. This implementation goes a bit further, the key difference is that we read TC from GUI only once upfront instead of re-reading after every move as in Michael's implementation. No functional change.
2015-03-22 14:15:44 -06:00
o["nodestime"] << Option(0, 0, 10000);
o["UCI_Chess960"] << Option(false);
o["UCI_AnalyseMode"] << Option(false);
2015-01-18 00:05:05 -07:00
o["SyzygyPath"] << Option("<empty>", on_tb_path);
o["SyzygyProbeDepth"] << Option(1, 1, 100);
o["Syzygy50MoveRule"] << Option(true);
7-pieces Syzygy tablebase support This is the first patch teaching Stockfish how to use the 7-pieces Syzygy tablebase currently calculated by Bujun Guo (@noobpwnftw) and Ronald de Man (@syzygy1). The 7-pieces database are so big that they required a change in the internal format of the files (technically, some DTZ values are 16 bits long, so this had to be stored as wide integers in the Huffman tree). Here are the estimated file size for the 7-pieces Syzygy files, compared to the 151G of the 6-pieces Syzygy: ``` 7.1T ./7men_testing/4v3_pawnful (ongoing, 120 of 325 sets remaining) 2.4T ./7men_testing/4v3_pawnless 2.3T ./7men_testing/5v2_pawnful 660G ./7men_testing/5v2_pawnless 117G ./7men_testing/6v1_pawnful 87G ./7men_testing/6v1_pawnless ``` Some pointers to download or recalculate the tables: Location of original files, by Bujun Guo: ftp://ftp.chessdb.cn/pub/syzygy/ Mirrors: http://tablebase.sesse.net/ (partial) http://tablebase.lichess.ovh/tables/standard/7/ Generator code: https://github.com/syzygy1/tb/ Closes https://github.com/official-stockfish/Stockfish/pull/1707 Bench: 5591925 (No functional change if SyzygyTB is not used) ---------------------- Comment by Leonardo Ljubičić (@DragonMist) This is an amazing achievement, generating and being able to use 7 men syzygy on the fly. Thank you for your efforts @noobpwnftw !! Looking forward how this will work in real life, and expecting some trade off between gaining perfect play and slow disc Access, but once the disc speed and space is not a problem, I expect 7 men to yield something like 30 elo at least. ----------------------- Comment by Michael Byrne (@MichaelB7) This definitely has a bright future. I turned off the 50 move rule (ala ICCF new rules) for the following position: `[d]8/8/1b6/8/4N2r/1k6/7B/R1K5 w - - 0 1` This position is a 451 ply win for white (sans the 50 move rule, this position was identified by the generator as the longest cursed win for white in KRBN v KRB). Now Stockfish finds it instantly (as it should), nice work 👊👍 . ``` dep score nodes time 7 +132.79 4339 0:00.00 Rb1+ Kc4 Nd6+ Kc5 Bg1+ Kxd6 Rxb6+ Kc7 Be3 Rh2 Bd4 6 +132.79 1652 0:00.00 Rb1+ Kc4 Nd2+ Kd5 Rxb6 Rxh2 Nf3 Rf2 5 +132.79 589 0:00.00 Rb1+ Kc4 Rxb6 Rxh2 Nf6 Rh1+ Kb2 4 +132.79 308 0:00.00 Rb1+ Kc4 Nd6+ Kc3 Rxb6 Rxh2 3 +132.79 88 0:00.00 Rb1+ Ka4 Nc3+ Ka5 Ra1+ Kb4 Ra4+ Kxc3 Rxh4 2 +132.79 54 0:00.00 Rb1+ Ka4 Nc3+ Ka5 Ra1+ Kb4 1 +132.7 ```
2018-07-26 13:18:04 -06:00
o["SyzygyProbeLimit"] << Option(7, 0, 7);
2008-08-31 23:59:13 -06:00
}
/// operator<<() is used to print all the options default values in chronological
/// insertion order (the idx field) and in the format defined by the UCI protocol.
std::ostream& operator<<(std::ostream& os, const OptionsMap& om) {
for (size_t idx = 0; idx < om.size(); ++idx)
for (const auto& it : om)
if (it.second.idx == idx)
{
const Option& o = it.second;
os << "\noption name " << it.first << " type " << o.type;
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
if (o.type == "string" || o.type == "check" || o.type == "combo")
os << " default " << o.defaultValue;
if (o.type == "spin")
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
os << " default " << int(stof(o.defaultValue))
<< " min " << o.min
<< " max " << o.max;
break;
}
return os;
2008-08-31 23:59:13 -06:00
}
/// Option class constructors and conversion operators
2008-08-31 23:59:13 -06:00
Option::Option(const char* v, OnChange f) : type("string"), min(0), max(0), on_change(f)
{ defaultValue = currentValue = v; }
2008-08-31 23:59:13 -06:00
Option::Option(bool v, OnChange f) : type("check"), min(0), max(0), on_change(f)
{ defaultValue = currentValue = (v ? "true" : "false"); }
2008-08-31 23:59:13 -06:00
Option::Option(OnChange f) : type("button"), min(0), max(0), on_change(f)
{}
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
Option::Option(double v, int minv, int maxv, OnChange f) : type("spin"), min(minv), max(maxv), on_change(f)
{ defaultValue = currentValue = std::to_string(v); }
2008-08-31 23:59:13 -06:00
Option::Option(const char* v, const char* cur, OnChange f) : type("combo"), min(0), max(0), on_change(f)
{ defaultValue = v; currentValue = cur; }
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
Option::operator double() const {
assert(type == "check" || type == "spin");
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
return (type == "spin" ? stof(currentValue) : currentValue == "true");
}
Option::operator std::string() const {
assert(type == "string");
return currentValue;
}
bool Option::operator==(const char* s) const {
assert(type == "combo");
return !CaseInsensitiveLess()(currentValue, s)
&& !CaseInsensitiveLess()(s, currentValue);
}
/// operator<<() inits options and assigns idx in the correct printing order
void Option::operator<<(const Option& o) {
static size_t insert_order = 0;
*this = o;
idx = insert_order++;
}
/// operator=() updates currentValue and triggers on_change() action. It's up to
/// the GUI to check for option's limits, but we could receive the new value
/// from the user by console window, so let's check the bounds anyway.
2008-08-31 23:59:13 -06:00
Option& Option::operator=(const string& v) {
2008-08-31 23:59:13 -06:00
assert(!type.empty());
if ( (type != "button" && v.empty())
|| (type == "check" && v != "true" && v != "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
|| (type == "spin" && (stof(v) < min || stof(v) > max)))
return *this;
if (type == "combo")
{
OptionsMap comboMap; // To have case insensitive compare
string token;
std::istringstream ss(defaultValue);
while (ss >> token)
comboMap[token] << Option();
if (!comboMap.count(v) || v == "var")
return *this;
}
if (type != "button")
currentValue = v;
if (on_change)
on_change(*this);
return *this;
2008-08-31 23:59:13 -06:00
}
} // namespace UCI