-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Switch time management to 64 bits (2) #1510
Conversation
Just a small suggestion:
|
Done, thanks |
I'm OK with this, too. But you should also change the cast in - limits.time[us] = (int)availableNodes;
+ limits.time[us] = TimePoint(availableNodes); |
Corrected, thanks |
@snicolet assigning an integer to a float variable is perfectly fine, as is using integer operands in a float expression. |
@mcostalba I know, but it makes the code more readable in my opinion because it makes the typing intuitive from the form of the expression. In particular we don't have to wonder for half a second if the division will be floating point division or integer division (euclidian quotient).
|
int t = 99;
double y = t / 100;
cout << y << endl;
double z = t / 100.0;
cout << z << endl; Result:
|
@snicolet I understand. Thanks. |
This is a patch to fix issue #1498, switching the time management variables to 64 bits to avoid overflow of time variables after 25 days. There was a bug in Stockfish 9 causing the output to be wrong after 2^31 milliseconds search. Here is a long run from the starting position: info depth 64 seldepth 87 multipv 1 score cp 23 nodes 13928920239402 nps 0 tbhits 0 time -504995523 pv g1f3 d7d5 d2d4 g8f6 c2c4 d5c4 e2e3 e7e6 f1c4 c7c5 e1g1 b8c6 d4c5 d8d1 f1d1 f8c5 c4e2 e8g8 a2a3 c5e7 b2b4 f8d8 b1d2 b7b6 c1b2 c8b7 a1c1 a8c8 c1c2 c6e5 d1c1 c8c2 c1c2 e5f3 d2f3 a7a5 b4b5 e7c5 f3d4 d8c8 d4b3 c5d6 c2c8 b7c8 b3d2 c8b7 d2c4 d6c5 e2f3 b7d5 f3d5 e6d5 c4e5 a5a4 e5d3 f6e4 d3c5 e4c5 b2d4 c5e4 d4b6 e4d6 g2g4 d6b5 b6c5 b5c7 g1g2 c7e6 c5d6 g7g6 We check at compile time that the TimePoint type is exactly 64 bits long for the compiler (TimePoint is our alias in Stockfish for std::chrono::milliseconds -- it is a signed integer type of at least 45 bits according to the C++ standard, but will most probably be implemented as a 64 bits signed integer on modern compilers), and we use this TimePoint type consistently across the code. Bug report by user "fischerandom" on the TCEC chat (thanks), and the patch includes code and suggestions by user "WOnder93" and Ronald de Man. Fixes issue: #1498 Closes pull request: #1510 No functional change.
Closed via a03e98d |
This is a patch to fix issue #1498, switching the time management variables to 64 bits to avoid overflow of time variables after 25 days. There was a bug in Stockfish 9 causing the output to be wrong after 2^31 milliseconds search. Here is a long run from the starting position: info depth 64 seldepth 87 multipv 1 score cp 23 nodes 13928920239402 nps 0 tbhits 0 time -504995523 pv g1f3 d7d5 d2d4 g8f6 c2c4 d5c4 e2e3 e7e6 f1c4 c7c5 e1g1 b8c6 d4c5 d8d1 f1d1 f8c5 c4e2 e8g8 a2a3 c5e7 b2b4 f8d8 b1d2 b7b6 c1b2 c8b7 a1c1 a8c8 c1c2 c6e5 d1c1 c8c2 c1c2 e5f3 d2f3 a7a5 b4b5 e7c5 f3d4 d8c8 d4b3 c5d6 c2c8 b7c8 b3d2 c8b7 d2c4 d6c5 e2f3 b7d5 f3d5 e6d5 c4e5 a5a4 e5d3 f6e4 d3c5 e4c5 b2d4 c5e4 d4b6 e4d6 g2g4 d6b5 b6c5 b5c7 g1g2 c7e6 c5d6 g7g6 We check at compile time that the TimePoint type is exactly 64 bits long for the compiler (TimePoint is our alias in Stockfish for std::chrono::milliseconds -- it is a signed integer type of at least 45 bits according to the C++ standard, but will most probably be implemented as a 64 bits signed integer on modern compilers), and we use this TimePoint type consistently across the code. Bug report by user "fischerandom" on the TCEC chat (thanks), and the patch includes code and suggestions by user "WOnder93" and Ronald de Man. Fixes issue: official-stockfish/Stockfish#1498 Closes pull request: official-stockfish/Stockfish#1510 No functional change.
This is a patch to fix issue official-stockfish#1498, switching the time management variables to 64 bits to avoid overflow of time variables after 25 days. There was a bug in Stockfish 9 causing the output to be wrong after 2^31 milliseconds search. Here is a long run from the starting position: info depth 64 seldepth 87 multipv 1 score cp 23 nodes 13928920239402 nps 0 tbhits 0 time -504995523 pv g1f3 d7d5 d2d4 g8f6 c2c4 d5c4 e2e3 e7e6 f1c4 c7c5 e1g1 b8c6 d4c5 d8d1 f1d1 f8c5 c4e2 e8g8 a2a3 c5e7 b2b4 f8d8 b1d2 b7b6 c1b2 c8b7 a1c1 a8c8 c1c2 c6e5 d1c1 c8c2 c1c2 e5f3 d2f3 a7a5 b4b5 e7c5 f3d4 d8c8 d4b3 c5d6 c2c8 b7c8 b3d2 c8b7 d2c4 d6c5 e2f3 b7d5 f3d5 e6d5 c4e5 a5a4 e5d3 f6e4 d3c5 e4c5 b2d4 c5e4 d4b6 e4d6 g2g4 d6b5 b6c5 b5c7 g1g2 c7e6 c5d6 g7g6 We check at compile time that the TimePoint type is exactly 64 bits long for the compiler (TimePoint is our alias in Stockfish for std::chrono::milliseconds -- it is a signed integer type of at least 45 bits according to the C++ standard, but will most probably be implemented as a 64 bits signed integer on modern compilers), and we use this TimePoint type consistently across the code. Bug report by user "fischerandom" on the TCEC chat (thanks), and the patch includes code and suggestions by user "WOnder93" and Ronald de Man. Fixes issue: official-stockfish#1498 Closes pull request: official-stockfish#1510 No functional change.
This is another tentative to fix issue #1498, about switching the time management variables to 64 bits to avoid overflow of time variables after 25 days.
There was a bug in Stockfish 9 causing the output to be wrong after 2^31 milliseconds search.
Here is a long run from the starting position:
We check at compile time that the TimePoint type is exactly 64 bits long for the compiler (TimePoint is our alias in Stockfish for std::chrono::milliseconds -- it is a signed integer type of at least 45 bits according to the C++ standard, but will most probably be implemented as a 64 bits signed integer on modern compilers), and we use this TimePoint type consistently across the code.
Includes code and suggestions by user "WOnder93" and Ronald de Man.
No functional change.