"B"
Admin
 Posts : 1201
Reputation : 4018
Join date : 2010-01-17
Location : undetermined
 |  Subject: Latest abrok Development Version November 12th (SF The gift that keeps on giving ) Tue Nov 12, 2019 2:31 pm | |
| nt. !! latest version !!
Windows x64 for Haswell CPUs
Windows x64 for modern computers
Windows x64
Windows 32
Linux x64 for Haswell CPUs
Linux x64 for modern computers
Linux x64 | Author: Miguel Lahoz
Date: Tue Nov 12 01:36:06 2019 +0100
Timestamp: 1573518966
Shallow depth pruning on NonPV advanced pawn push
Usually advanced pawn pushes are not considered in shallow depth pruning
because it is risky to do so with possible promotions near the horizon.
However, this heuristic is not also beneficial on NonPV nodes since we
can afford to take slightly more risk on less important nodes.
STC:
LLR: 2.95 (-2.94,2.94) [-1.50,4.50]
Total: 54530 W: 11955 L: 11686 D: 30889 Elo +1.71
http://tests.stockfishchess.org/tests/view/5dc7dda30ebc5902ea57efd0
LTC:
LLR: 2.95 (-2.94,2.94) [0.00,3.50]
Total: 77336 W: 12786 L: 12399 D: 52151 Elo +1.74
http://tests.stockfishchess.org/tests/view/5dc8050d0ebc5902ea57f491
Closes https://github.com/official-stockfish/Stockfish/pull/2408
Bench: 4422068 | Windows x64 for Haswell CPUs
Windows x64 for modern computers
Windows x64
Windows 32
Linux x64 for Haswell CPUs
Linux x64 for modern computers
Linux x64 | Author: Joost VandeVondele
Date: Tue Nov 12 01:27:06 2019 +0100
Timestamp: 1573518426
Remove explicit moveCount pruning
The removed lines approximately duplicate equivalent logic in the movePicker.
Adjust the futility_move_count to componsate for some difference
(the movePicker prunes one iteration of the move loop later).
Passed STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 8114 W: 1810 L: 1663 D: 4641 Elo +6.30
http://tests.stockfishchess.org/tests/view/5dc6afe60ebc5902562bd318
Passed LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 89956 W: 14473 L: 14460 D: 61023 Elo +0.05
http://tests.stockfishchess.org/tests/view/5dc6bdcf0ebc5902562bd3c0
Closes https://github.com/official-stockfish/Stockfish/pull/2407
Bench: 4256440
---------------------
How to continue from there?
It would be interesting to see if we can extract some Elo gain
from the new futility_move_count formula, for instance by somehow
incorporating the final -1 in the 5 constant, or adding a linear
term to the quadratics...
```
futility_move_count = (5 + depth * depth) * (1 + improving) / 2 - 1
``` | Windows x64 for Haswell CPUs
Windows x64 for modern computers
Windows x64
Windows 32
Linux x64 for Haswell CPUs
Linux x64 for modern computers
Linux x64 | Author: Alain SAVARD
Date: Tue Nov 12 01:18:54 2019 +0100
Timestamp: 1573517934
Sequencing tweak in tbprobe()
Followup of "issue" #2372, which was in fact a small speed-up
proposal by user @d3vv for the probing code of tablebases.
See comments on this issue where it was proven by Alin Savard that the
proposed change is more efficient on average than master on all type of
sequences it will usually be called.
Note that on gcc 4.3, this will produce a bogus warning which was solved
with ulterior gcc versions: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43949
Closes https://github.com/official-stockfish/Stockfish/issues/2372
Closes https://github.com/official-stockfish/Stockfish/pull/2379
Non functional change | Windows x64 for Haswell CPUs
Windows x64 for modern computers
Windows x64
Windows 32
Linux x64 for Haswell CPUs
Linux x64 for modern computers
Linux x64 | Author: Joost VandeVondele
Date: Tue Nov 12 01:09:57 2019 +0100
Timestamp: 1573517397
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 Elo +0.02
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 Elo +1.01
http://tests.stockfishchess.org/tests/view/5db4c8940ebc5902d6b146fc
closes https://github.com/official-stockfish/Stockfish/issues/2370
Bench: 4362323 |
_________________
looking for Bettina
| |
|
