1
0
Fork 0
stockfish/src/ucioption.cpp

193 lines
6.3 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
Add NNUE evaluation This patch ports the efficiently updatable neural network (NNUE) evaluation to Stockfish. Both the NNUE and the classical evaluations are available, and can be used to assign a value to a position that is later used in alpha-beta (PVS) search to find the best move. The classical evaluation computes this value as a function of various chess concepts, handcrafted by experts, tested and tuned using fishtest. The NNUE evaluation computes this value with a neural network based on basic inputs. The network is optimized and trained on the evalutions of millions of positions at moderate search depth. The NNUE evaluation was first introduced in shogi, and ported to Stockfish afterward. It can be evaluated efficiently on CPUs, and exploits the fact that only parts of the neural network need to be updated after a typical chess move. [The nodchip repository](https://github.com/nodchip/Stockfish) provides additional tools to train and develop the NNUE networks. This patch is the result of contributions of various authors, from various communities, including: nodchip, ynasu87, yaneurao (initial port and NNUE authors), domschl, FireFather, rqs, xXH4CKST3RXx, tttak, zz4032, joergoster, mstembera, nguyenpham, erbsenzaehler, dorzechowski, and vondele. This new evaluation needed various changes to fishtest and the corresponding infrastructure, for which tomtor, ppigazzini, noobpwnftw, daylen, and vondele are gratefully acknowledged. The first networks have been provided by gekkehenker and sergiovieri, with the latter net (nn-97f742aaefcd.nnue) being the current default. The evaluation function can be selected at run time with the `Use NNUE` (true/false) UCI option, provided the `EvalFile` option points the the network file (depending on the GUI, with full path). The performance of the NNUE evaluation relative to the classical evaluation depends somewhat on the hardware, and is expected to improve quickly, but is currently on > 80 Elo on fishtest: 60000 @ 10+0.1 th 1 https://tests.stockfishchess.org/tests/view/5f28fe6ea5abc164f05e4c4c ELO: 92.77 +-2.1 (95%) LOS: 100.0% Total: 60000 W: 24193 L: 8543 D: 27264 Ptnml(0-2): 609, 3850, 9708, 10948, 4885 40000 @ 20+0.2 th 8 https://tests.stockfishchess.org/tests/view/5f290229a5abc164f05e4c58 ELO: 89.47 +-2.0 (95%) LOS: 100.0% Total: 40000 W: 12756 L: 2677 D: 24567 Ptnml(0-2): 74, 1583, 8550, 7776, 2017 At the same time, the impact on the classical evaluation remains minimal, causing no significant regression: sprt @ 10+0.1 th 1 https://tests.stockfishchess.org/tests/view/5f2906a2a5abc164f05e4c5b LLR: 2.94 (-2.94,2.94) {-6.00,-4.00} Total: 34936 W: 6502 L: 6825 D: 21609 Ptnml(0-2): 571, 4082, 8434, 3861, 520 sprt @ 60+0.6 th 1 https://tests.stockfishchess.org/tests/view/5f2906cfa5abc164f05e4c5d LLR: 2.93 (-2.94,2.94) {-6.00,-4.00} Total: 10088 W: 1232 L: 1265 D: 7591 Ptnml(0-2): 49, 914, 3170, 843, 68 The needed networks can be found at https://tests.stockfishchess.org/nns It is recommended to use the default one as indicated by the `EvalFile` UCI option. Guidelines for testing new nets can be found at https://github.com/glinscott/fishtest/wiki/Creating-my-first-test#nnue-net-tests Integration has been discussed in various issues: https://github.com/official-stockfish/Stockfish/issues/2823 https://github.com/official-stockfish/Stockfish/issues/2728 The integration branch will be closed after the merge: https://github.com/official-stockfish/Stockfish/pull/2825 https://github.com/official-stockfish/Stockfish/tree/nnue-player-wip closes https://github.com/official-stockfish/Stockfish/pull/2912 This will be an exciting time for computer chess, looking forward to seeing the evolution of this approach. Bench: 4746616
2020-08-05 09:11:15 -06:00
Copyright (C) 2004-2020 The Stockfish developers (see AUTHORS file)
2008-08-31 23:59:13 -06:00
Stockfish is free software: you can redistribute it and/or modify
2008-08-31 23:59:13 -06:00
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
Stockfish is distributed in the hope that it will be useful,
2008-08-31 23:59:13 -06:00
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
2008-08-31 23:59:13 -06:00
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
#include <algorithm>
#include <cassert>
#include <ostream>
#include <sstream>
2008-08-31 23:59:13 -06:00
#include "evaluate.h"
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(size_t(o)); }
void on_logger(const Option& o) { start_logger(o); }
void on_threads(const Option& o) { Threads.set(size_t(o)); }
2015-01-18 00:05:05 -07:00
void on_tb_path(const Option& o) { Tablebases::init(o); }
Add NNUE evaluation This patch ports the efficiently updatable neural network (NNUE) evaluation to Stockfish. Both the NNUE and the classical evaluations are available, and can be used to assign a value to a position that is later used in alpha-beta (PVS) search to find the best move. The classical evaluation computes this value as a function of various chess concepts, handcrafted by experts, tested and tuned using fishtest. The NNUE evaluation computes this value with a neural network based on basic inputs. The network is optimized and trained on the evalutions of millions of positions at moderate search depth. The NNUE evaluation was first introduced in shogi, and ported to Stockfish afterward. It can be evaluated efficiently on CPUs, and exploits the fact that only parts of the neural network need to be updated after a typical chess move. [The nodchip repository](https://github.com/nodchip/Stockfish) provides additional tools to train and develop the NNUE networks. This patch is the result of contributions of various authors, from various communities, including: nodchip, ynasu87, yaneurao (initial port and NNUE authors), domschl, FireFather, rqs, xXH4CKST3RXx, tttak, zz4032, joergoster, mstembera, nguyenpham, erbsenzaehler, dorzechowski, and vondele. This new evaluation needed various changes to fishtest and the corresponding infrastructure, for which tomtor, ppigazzini, noobpwnftw, daylen, and vondele are gratefully acknowledged. The first networks have been provided by gekkehenker and sergiovieri, with the latter net (nn-97f742aaefcd.nnue) being the current default. The evaluation function can be selected at run time with the `Use NNUE` (true/false) UCI option, provided the `EvalFile` option points the the network file (depending on the GUI, with full path). The performance of the NNUE evaluation relative to the classical evaluation depends somewhat on the hardware, and is expected to improve quickly, but is currently on > 80 Elo on fishtest: 60000 @ 10+0.1 th 1 https://tests.stockfishchess.org/tests/view/5f28fe6ea5abc164f05e4c4c ELO: 92.77 +-2.1 (95%) LOS: 100.0% Total: 60000 W: 24193 L: 8543 D: 27264 Ptnml(0-2): 609, 3850, 9708, 10948, 4885 40000 @ 20+0.2 th 8 https://tests.stockfishchess.org/tests/view/5f290229a5abc164f05e4c58 ELO: 89.47 +-2.0 (95%) LOS: 100.0% Total: 40000 W: 12756 L: 2677 D: 24567 Ptnml(0-2): 74, 1583, 8550, 7776, 2017 At the same time, the impact on the classical evaluation remains minimal, causing no significant regression: sprt @ 10+0.1 th 1 https://tests.stockfishchess.org/tests/view/5f2906a2a5abc164f05e4c5b LLR: 2.94 (-2.94,2.94) {-6.00,-4.00} Total: 34936 W: 6502 L: 6825 D: 21609 Ptnml(0-2): 571, 4082, 8434, 3861, 520 sprt @ 60+0.6 th 1 https://tests.stockfishchess.org/tests/view/5f2906cfa5abc164f05e4c5d LLR: 2.93 (-2.94,2.94) {-6.00,-4.00} Total: 10088 W: 1232 L: 1265 D: 7591 Ptnml(0-2): 49, 914, 3170, 843, 68 The needed networks can be found at https://tests.stockfishchess.org/nns It is recommended to use the default one as indicated by the `EvalFile` UCI option. Guidelines for testing new nets can be found at https://github.com/glinscott/fishtest/wiki/Creating-my-first-test#nnue-net-tests Integration has been discussed in various issues: https://github.com/official-stockfish/Stockfish/issues/2823 https://github.com/official-stockfish/Stockfish/issues/2728 The integration branch will be closed after the merge: https://github.com/official-stockfish/Stockfish/pull/2825 https://github.com/official-stockfish/Stockfish/tree/nnue-player-wip closes https://github.com/official-stockfish/Stockfish/pull/2912 This will be an exciting time for computer chess, looking forward to seeing the evolution of this approach. Bench: 4746616
2020-08-05 09:11:15 -06:00
void on_use_NNUE(const Option& ) { Eval::init_NNUE(); }
void on_eval_file(const Option& ) { Eval::init_NNUE(); }
/// 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); });
}
/// UCI::init() initializes the UCI options to their hard-coded default values
2008-08-31 23:59:13 -06:00
void init(OptionsMap& o) {
constexpr int MaxHashMB = Is64Bit ? 33554432 : 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(10, 0, 5000);
Simplify Time Management This is a functional simplification of the time management system. With this patch, there is a simple equation for each of two distinct time controls: basetime + increment, and x moves in y seconds (+increment). These equations are easy to plot and understand making future modifications or adding additional time controls much easier. SlowMover is reset to 100 so that is has no effect unless a user changes it. There are two scaling variables: * Opt_scale is a scale factor (or percentage) of time to use for this current move. * Max_scale is a scale factor to apply to the resulting optimumTime. There seems to be some elo gain in most scenarios. Better performance is attributable to one of two things: * minThinkingTime was not allowing reasonable time calculations for very short games like 10+0 or 10+0.01. This is because adding almost no increment and substracting move overhead for 50 moves quickly results in almost 0 time very early in the game. Master depended on minThinkingTime to handle these short games instead of good time management. This patch addresses this issue by lowering minThinkingTime to 0 and adjusting moverOverhead if there are very low increments. * Notice that the time distribution curves tail downward for the first 10 moves or so. This causes less time to attribute for very early moves leaving more time available for middle moves where more important decisions happen. Here is a summary of tests for this version at different time controls: SMP 5+0.05 LLR: 2.97 (-2.94,2.94) {-1.50,0.50} Total: 46544 W: 7175 L: 7089 D: 32280 Ptnml(0-2): 508, 4826, 12517, 4914, 507 https://tests.stockfishchess.org/tests/user/protonspring STC LLR: 2.94 (-2.94,2.94) {-1.50,0.50} Total: 20480 W: 3872 L: 3718 D: 12890 Ptnml(0-2): 295, 2364, 4824, 2406, 351 https://tests.stockfishchess.org/tests/view/5ebc343e7dd5693aad4e6873 STC, sudden death LLR: 2.93 (-2.94,2.94) {-1.50,0.50} Total: 7024 W: 1706 L: 1489 D: 3829 Ptnml(0-2): 149, 813, 1417, 938, 195 https://tests.stockfishchess.org/tests/view/5ebc346f7dd5693aad4e6875 STC, TCEC style LLR: 2.95 (-2.94,2.94) {-1.50,0.50} Total: 4192 W: 1014 L: 811 D: 2367 Ptnml(0-2): 66, 446, 912, 563, 109 https://tests.stockfishchess.org/tests/view/5ebc34857dd5693aad4e6877 40/10 LLR: 2.93 (-2.94,2.94) {-1.50,0.50} Total: 54032 W: 10592 L: 10480 D: 32960 Ptnml(0-2): 967, 6148, 12677, 6254, 970 https://tests.stockfishchess.org/tests/view/5ebc50597dd5693aad4e688d LTC, sudden death LLR: 2.95 (-2.94,2.94) {-1.50,0.50} Total: 9152 W: 1391 L: 1263 D: 6498 Ptnml(0-2): 75, 888, 2526, 1008, 79 https://tests.stockfishchess.org/tests/view/5ebc6f5c7dd5693aad4e689b LTC LLR: 2.98 (-2.94,2.94) {-1.50,0.50} Total: 12344 W: 1563 L: 1459 D: 9322 Ptnml(0-2): 70, 1103, 3740, 1171, 88 https://tests.stockfishchess.org/tests/view/5ebc6f4c7dd5693aad4e6899 closes https://github.com/official-stockfish/Stockfish/pull/2678 Bench: 4395562
2020-05-13 11:52:41 -06:00
o["Slow Mover"] << Option(100, 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);
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
o["UCI_LimitStrength"] << Option(false);
o["UCI_Elo"] << Option(1350, 1350, 2850);
o["UCI_ShowWDL"] << 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);
o["Use NNUE"] << Option(true, on_use_NNUE);
o["EvalFile"] << Option(EvalFileDefaultName, on_eval_file);
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