Fabian Fichter [Fri, 2 Nov 2018 14:24:14 +0000 (15:24 +0100)]
Simplify mobility danger
Check sign only after adding mobility danger term.
STC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 9090 W: 2001 L: 1856 D: 5233
http://tests.stockfishchess.org/tests/view/
5bdc5ee10ebc595e0ae27bc2
LTC
LLR: 2.94 (-2.94,2.94) [-3.00,1.00]
Total: 123466 W: 19766 L: 19805 D: 83895
http://tests.stockfishchess.org/tests/view/
5bdc678e0ebc595e0ae27cf3
bench:
3630207
Stéphane Nicolet [Fri, 2 Nov 2018 21:04:43 +0000 (22:04 +0100)]
Rook tweaks in evaluation
Some small changes in evaluation to try to convince Stockfish to centralize
her rooks more in middle game and avoid trapping them in the corners. Joint
work by SFisGOD and snicolet.
STC:
LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 99826 W: 21895 L: 21341 D: 56590
http://tests.stockfishchess.org/tests/view/
5bdc3e280ebc595e0ae277df
LTC:
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 21467 W: 3541 L: 3322 D: 14604
http://tests.stockfishchess.org/tests/view/
5bdc9ff30ebc595e0ae28119
Bench:
3631608
Joost VandeVondele [Sun, 28 Oct 2018 14:25:15 +0000 (15:25 +0100)]
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
SFisGOD [Wed, 31 Oct 2018 16:48:16 +0000 (00:48 +0800)]
Combo
Combo of two parameter tweaks and tuned values for Queen and ThreatByKing.
STC
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 20180 W: 4439 L: 4198 D: 11543
http://tests.stockfishchess.org/tests/view/
5bd7b8250ebc595e0ae22e97
LTC
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 86312 W: 14106 L: 13685 D: 58521
http://tests.stockfishchess.org/tests/view/
5bd803560ebc595e0ae23213
This combo consists of the following:
Queen Value (tuned values)
Iter: 72056, A: 5000, alpha 0.602000, gamma 0.101000, clipping old, rounding deterministic
param: QueenValueMg, best: 2528.91, start: 2528.00
param: QueenValueEg, best: 2687.12, start: 2698.00
ThreatByKing (tuned values)
Green STC (50.8k games)
http://tests.stockfishchess.org/tests/view/
5bd1d5a00ebc595e0ae1cbec
LTC (I stopped this test at 71.2k games. It's likely yellow.)
http://tests.stockfishchess.org/tests/view/
5bd263e70ebc595e0ae1d77e
WeakUnopposedPawn (tweak) by xoto (https://github.com/xoto10)
Green STC (102.8k games)
http://tests.stockfishchess.org/tests/view/
5bd306bb0ebc595e0ae1e146
Yellow LTC (90.8k games)
http://tests.stockfishchess.org/tests/view/
5bd3ea660ebc595e0ae1f16b
aspiTune1 (tweak) by vondele (https://github.com/vondele)
Green STC (125.9k games)
http://tests.stockfishchess.org/tests/view/
5bd2ae100ebc595e0ae1dab0
Yellow LTC (107.9k games)
http://tests.stockfishchess.org/tests/view/
5bd3eb700ebc595e0ae1f16f
Thank you @31m059 (Mark Tenzer) for helping me! Also, thank you very much
for recognizing my efforts. I genuinely appreciate it.
Bench:
3556672
Vizvezdenec [Fri, 26 Oct 2018 12:17:42 +0000 (15:17 +0300)]
Tweak of knight PSQT and mobility bonuses
STC
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 16906 W: 3745 L: 3516 D: 9645
http://tests.stockfishchess.org/tests/view/
5bd306a40ebc595e0ae1e144
LTC
LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 62779 W: 10249 L: 9901 D: 42629
http://tests.stockfishchess.org/tests/view/
5bd3188f0ebc595e0ae1e296
Bench
3166402
Guenther Demetz [Fri, 19 Oct 2018 08:33:01 +0000 (10:33 +0200)]
On main thread: reduce depth after fail high
This helps resolving consecutive FH's during aspiration more efficiently
STC:
http://tests.stockfishchess.org/tests/view/
5bc857920ebc592439f85765
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 4992 W: 1134 L: 980 D: 2878 Elo +10.72
LTC:
http://tests.stockfishchess.org/tests/view/
5bc868050ebc592439f857ef
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 8123 W: 1363 L: 1210 D: 5550 Elo +6.54
No-Regression test with 8 threads, tc=15+0.15:
http://tests.stockfishchess.org/tests/view/
5bc874ca0ebc592439f85938
LLR: 2.94 (-2.94,2.94) [-3.00,1.00]
Total: 24740 W: 3977 L: 3863 D: 16900 Elo +1.60
This was a cooperation between me and Michael Stembera:
-me recognizing SF having problems with resolving FH's efficiently at
high depths, thus starting some tests based on consecutive FH's.
-mstembera picking up the idea with first success at STC & LTC (so full
credits to him!)
-me suggesting how to resolve the issues pinpointed by S.G on PR #1768
and finally restricting the logic to the main thread so that it don't
regresses at multi-thread.
bench:
3314347
Peter Zsifkovits [Tue, 4 Sep 2018 11:36:42 +0000 (13:36 +0200)]
NUMA for 9 threads or more
Enable numa machinery only for STRICTLY MORE than 8 threads. Reason for this
change is that nowadays SMP tests are always done with 8 threads. That is a
problem for multi-socket Windows machines running on fishtest.
No functional change
Günther Demetz [Tue, 23 Oct 2018 16:04:30 +0000 (18:04 +0200)]
Revert Pull Request #1771, see issue #1785 (#1786)
no functional change
bench:
4274207
mstembera [Sun, 14 Oct 2018 19:50:31 +0000 (12:50 -0700)]
Small simplification in castling rights
There is no need for a special struct with a static member
to generate castling rights.
No functional change.
ElbertoOne [Tue, 2 Oct 2018 07:07:29 +0000 (09:07 +0200)]
Simplify check extensions
Remove the !moveCountPruning condition for check extensions, which seems not necessary.
STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 22238 W: 4835 L: 4715 D: 12688
http://tests.stockfishchess.org/tests/view/
5bb3241a0ebc592439f6d2ac
LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 36593 W: 5898 L: 5802 D: 24893
http://tests.stockfishchess.org/tests/view/
5bb34c220ebc592439f6d5dc
Bench:
4274207
Joost VandeVondele [Sun, 14 Oct 2018 18:33:24 +0000 (20:33 +0200)]
Randomize draw eval
The patch adds a small random component (+-1) to VALUE_DRAW for the evaluation
of draw positions (mostly 3folds). This random component is not static, but
potentially different for each visit of the node (hence derived from the node
counter). The effect is that in positions with many 3fold draw lines, different
lines are followed at each iteration. This keeps the search much more dynamic,
as opposed to being locked to one particular 3fold.
An example of a position where master suffers from 3fold-blindness and this patch
solves quickly is the famous TCEC game 53:
FEN: 3r2k1/pr6/1p3q1p/5R2/3P3p/8/5RP1/3Q2K1 b - - 0 51
master doesn't see that this is a lost position (draw eval up to depth 50) as
Qf6-e6 d4-d5 (found by patch at depth 23) leads to a loss.
The 3fold-blindness is more important at longer TC, the patch was yellow STC and
LTC, but passed VLTC:
STC
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 46328 W: 10048 L: 9953 D: 26327
http://tests.stockfishchess.org/tests/view/
5b9c0ca20ebc592cf275f7c7
LTC
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 54663 W: 8938 L: 8846 D: 36879
http://tests.stockfishchess.org/tests/view/
5b9ca1610ebc592cf27601d3
VLTC
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 31789 W: 4512 L: 4284 D: 22993
http://tests.stockfishchess.org/tests/view/
5b9d1a670ebc592cf276076d
Credit to @crossbr for pointing to this problem repeatedly, and giving the hint
that many draw lines are typical in those situations.
Bench:
4756639
Guenther Demetz [Mon, 17 Sep 2018 06:42:58 +0000 (08:42 +0200)]
Correctly track down pv even in fail-high case
Currently we update (track up) the pv even in the fail high case.
However most times in such cases the pv in the ply below remains unset
because there we have value == alpha and so finally we see truncated
pv's (=just one move) in fail high cases.
Of course tracking down these pv's (+sending them to the gui) comes at a
certian cost, but no-regression tests passed:
STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 16300 W: 3556 L: 3424 D: 9320
http://tests.stockfishchess.org/tests/view/
5b9b73500ebc592cf275ea92
LTC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 202411 W: 32734 L: 32897 D: 136780
http://tests.stockfishchess.org/tests/view/
5b9baed10ebc592cf275ef6d
N.B.: Digging also into qsearch was tried in another version but seemed
not to pass the tests. This means that we don't always will get a pv
until the very tips.
No functional change
Miguel Lahoz [Thu, 20 Sep 2018 07:12:12 +0000 (15:12 +0800)]
Simplify evaluation of blockers_for_king
Currently, we have two evaluation terms which account for pinned pieces.
One is for all pinned pieces in kingDanger computation and another for
just pinned pawns in ThreatByRank. We can increase the relevant bonus
for kingDanger calculation and do away with the ThreatByRank, which
seems to just add more complexity.
STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 113353 W: 24299 L: 24356 D: 64698
http://tests.stockfishchess.org/tests/view/
5ba348c20ebc592cf2766e61
LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 96458 W: 15514 L: 15511 D: 65433
http://tests.stockfishchess.org/tests/view/
5ba398830ebc592cf2767563
At 100k games, I thought it struggles a bit, but some related [0,4]
tests attempting individual tweaks seem to fail:
I tried directly tweaking ThreatByRank:
http://tests.stockfishchess.org/tests/view/
5ba3c6300ebc592cf276791c
http://tests.stockfishchess.org/tests/view/
5ba3c6190ebc592cf2767917
@Vizveznedec was also recently trying to tweak the same coeffecients
for kingDanger calculation:
http://tests.stockfishchess.org/tests/view/
5ba2c7320ebc592cf27664b2
http://tests.stockfishchess.org/tests/view/
5ba2c8220ebc592cf27664b8
http://tests.stockfishchess.org/tests/view/
5ba2c7880ebc592cf27664b4
http://tests.stockfishchess.org/tests/view/
5ba2c7ce0ebc592cf27664b6
Bench:
4648095
Joost VandeVondele [Tue, 2 Oct 2018 14:34:40 +0000 (16:34 +0200)]
small ttCapture simplification.
ttCapture can be assigned to only once outside of the main loop. The patch seems
functional at higher depths (seems possible in the case of non-legal TTmoves that
are captures).
passed STC
LLR: 2.94 (-2.94,2.94) [-3.00,1.00]
Total: 23189 W: 5098 L: 4980 D: 13111
http://tests.stockfishchess.org/tests/view/
5bb3822c0ebc592439f6d966
passed LTC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 10336 W: 1665 L: 1529 D: 7142
http://tests.stockfishchess.org/tests/view/
5bb39a190ebc592439f6db8a
unchanged bench:
4312846
31m059 [Mon, 8 Oct 2018 18:43:45 +0000 (14:43 -0400)]
Combo
This PR is a combination of two unrelated [0, 4] patches that appeared promising
but not quite strong enough to pass on their own. The combination initially failed
STC with a positive score after a long run, and the subsequent speculative LTC test
passed.
* tweak_threatOnQueen4 :
Increase the middlegame components of ThreatByMinor[QUEEN]
and ThreatByRook[QUEEN] by 15 each. Bryan's (@crossbr) analysis of CCC Bonus Game 10
inspired several tests on penalizing a queen with limited safe mobility. While
attempting to implement this idea, I noticed that when I did not include the queen's
current square in the calculations, the Elo gains seemed to vanish--and only then did
I have the idea to revisit ThreatByMinor[QUEEN] and ThreatByRook[QUEEN], adding a
corresponding value to each. Without Bryan's work, this test would never have been
submitted. I would also like to recognize the efforts and contributions of @SFisGOD,
who also vigorously worked on this idea.
* Use pure static eval for null move pruning :
This idea was directly re-purposed from a promising test by Jerry Donald Watson
(@jerrydonaldwatson) in August. It was also independently developed and tested by
Stefan Geschwentner (@locutus2) previously.
Thank you all!
STC (failed yellow):
LLR: -2.96 (-2.94,2.94) [0.00,4.00]
Total: 83913 W: 17986 L: 17825 D: 48102
http://tests.stockfishchess.org/tests/view/
5bbc59300ebc592439f76aa5
LTC:
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 137198 W: 22351 L: 21772 D: 93075
http://tests.stockfishchess.org/tests/view/
5bbce35f0ebc592439f77639
Bench:
4312846
Eduardo Caceres [Fri, 21 Sep 2018 21:18:46 +0000 (23:18 +0200)]
Fix two typos in comments
Note by snicolet: I use this non-functional change patch
as a pretext to correct the wrong bench number I introduced
in the message of the previous commit.
Bench:
4059356
Joost VandeVondele [Thu, 20 Sep 2018 12:50:39 +0000 (14:50 +0200)]
Remove essentially unused code
this was added recently as part of a larger commit, but only changes eval of positions at MAX_PLY depth a little. Can be safely removed:
passed STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 7424 W: 1640 L: 1492 D: 4292
http://tests.stockfishchess.org/html/live_elo.html?
5ba3bcbe0ebc592cf27677ff
passed LTC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 73554 W: 12028 L: 11990 D: 49536
http://tests.stockfishchess.org/html/live_elo.html?
5ba397ee0ebc592cf2767556
unchanged Bench:
4248710
protonspring [Fri, 14 Sep 2018 15:04:11 +0000 (09:04 -0600)]
Two simplifications in passed pawns evaluation
These two simplifications appear to be affecting and/or offsetting each other.
Neither can be removed independently, but in combination they pass -3,1.
STC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 36391 W: 7888 L: 7795 D: 20708
http://tests.stockfishchess.org/tests/view/
5b9bce410ebc592cf275f1b2
LTC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 19513 W: 3237 L: 3114 D: 13162
http://tests.stockfishchess.org/tests/view/
5b9c0edf0ebc592cf275f80e
Closes https://github.com/official-stockfish/Stockfish/pull/1769
bench
4059356
Rocky640 [Sun, 23 Sep 2018 20:57:57 +0000 (16:57 -0400)]
Pawn PSQT Tuned
Tested against master "Tweak opposite color bishops endgame scaling"
using values from a 100K SPSA with ck=10
Passed STC
http://tests.stockfishchess.org/tests/view/
5ba7fe7a0ebc592cf276b971
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 27717 W: 6052 L: 5782 D: 15883
Passed LTC
http://tests.stockfishchess.org/tests/view/
5ba815790ebc592cf276bb6b
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 17486 W: 2919 L: 2712 D: 11855
bench:
4441247
Joost VandeVondele [Sun, 24 Jun 2018 16:14:48 +0000 (18:14 +0200)]
Remove unneeded branch
Storing unconditionally the current generation and bound is equivalent to master.
Part of the condition was added as a speed optimization in #429.
Here the branch is fully eliminated.
passed STC single-threaded:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 73515 W: 16378 L: 16359 D: 40778
http://tests.stockfishchess.org/tests/view/
5b2fc38c0ebc5902b2e57fd5
passed STC multi-threaded:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 63725 W: 12916 L: 12874 D: 37935
http://tests.stockfishchess.org/tests/view/
5b307b8f0ebc5902b2e5895f
The multithreaded test was run after a plausible suggestion by @mstembera that the effect of this could be larger with many cores. The result seems to indicate this doesn't really matter on the 8core architecture abundantly available on fishtest.
No functional change
Vizvezdenec [Mon, 10 Sep 2018 10:02:43 +0000 (12:02 +0200)]
Tweak opposite colord bishops endgame scaling.
Make scale factor dependant on asymmetry of pawn structure.
STC http://tests.stockfishchess.org/tests/view/
5b92a2a80ebc592cf2753dd4
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 31490 W: 6870 L: 6587 D: 18033
LTC http://tests.stockfishchess.org/tests/view/
5b92f8170ebc592cf2754438
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 54928 W: 8988 L: 8653 D: 37287
This patch shows that SF can use some more complicated endgame heuristics to evaluate endgames better from the distance.
Closes https://github.com/official-stockfish/Stockfish/pull/1767
Bench:
4248710
ElbertoOne [Mon, 3 Sep 2018 10:15:31 +0000 (12:15 +0200)]
Parameter tweaks in PSQT and NMP
This patch is a combinaison of two parameters tweaks patches which
have failed as strong yellows at LTC recently, by Alain Savard (Rocky640)
and Fabian Fichter (ianfab):
http://tests.stockfishchess.org/tests/view/
5b8a71e60ebc592cf2749b1d
http://tests.stockfishchess.org/tests/view/
5b81ce3b0ebc5902bdbb6585
Passed STC:
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 57200 W: 12392 L: 12008 D: 32800
http://tests.stockfishchess.org/tests/view/
5b8d0a5a0ebc592cf274c48f
And LTC:
LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 37215 W: 6233 L: 5962 D: 25020
http://tests.stockfishchess.org/tests/view/
5b8d56090ebc592cf274cb53
Closes https://github.com/official-stockfish/Stockfish/pull/1764
Bench:
4136116
---------------
How to continue from there?
The null move reduction formula in line 769 of search.cpp is quite convoluted
and full of mysterious magic constants at the moment, it would certainly be
nice to simplify it and/or gain more Elo from it:
```
Depth R = ( (823 + 67 * depth / ONE_PLY) / 256
+ std::min(int(eval - beta) / 200, 3)) * ONE_PLY;
```
Stéphane Nicolet [Mon, 3 Sep 2018 10:46:05 +0000 (12:46 +0200)]
Update list of authors
And also fix some spaces and formatting oddities in the code.
No functional change
Stéphane Nicolet [Sat, 1 Sep 2018 08:39:29 +0000 (10:39 +0200)]
Re-introduce "keep pawns on both flanks"
Re-introduce the "keep pawns on both flanks" idea.
STC yellow:
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 93279 W: 20175 L: 19853 D: 53251
http://tests.stockfishchess.org/tests/view/
5b8a00370ebc592cf274916a
LTC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 11440 W: 1960 L: 1792 D: 7688
http://tests.stockfishchess.org/tests/view/
5b8a329f0ebc592cf2749615
Closes https://github.com/official-stockfish/Stockfish/pull/1761
Bench:
4609645
Rocky640 [Fri, 31 Aug 2018 13:30:16 +0000 (09:30 -0400)]
Long Diagonal Tweaks
a) Reduce PSQT values along the long diagonals on non-central squares
and increase the LongDiagonal bonus accordingly. The effect is to penalise
bishops on the long diagonal which can not "see" the 2 central squares.
The "good" bishops still have more or less the same bonus as current master.
b) For a bishop on a central square, because of the "| s" term in the code,
the LongDiagonalBonus was always given. So while being there, remove the "| s"
and compensate the central Bishop PSQT accordingly.
Passed STC
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 44498 W: 9658 L: 9323 D: 25517
http://tests.stockfishchess.org/tests/view/
5b8992770ebc592cf2748942
Passed LTC
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 63092 W: 10324 L: 9975 D: 42793
http://tests.stockfishchess.org/tests/view/
5b89a17a0ebc592cf2748b59
Closes https://github.com/official-stockfish/Stockfish/pull/1760
bench:
4693901
protonspring [Wed, 29 Aug 2018 00:48:45 +0000 (02:48 +0200)]
Remove PawnsOnBothFlanks
It looks like PawnsOnBothFlanks can be removed from initiative().
A barrage of tests seem to confirm that the adjustment to -110
does not gain elo to offset any potential loss by removing
PawnsOnBothFlanks.
STC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 22014 W: 4760 L: 4639 D: 12615
http://tests.stockfishchess.org/tests/view/
5b7f50cc0ebc5902bdbb3a3e
LTC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 40561 W: 6667 L: 6577 D: 27317
http://tests.stockfishchess.org/tests/view/
5b801f9f0ebc5902bdbb4467
The barrage of 0,4 tests on the -136 value are in my ps_tunetests branch.
http://tests.stockfishchess.org/tests/user/protonspring
Closes https://github.com/official-stockfish/Stockfish/pull/1751
Bench:
4413173
-------------
How to continue from there?
The fact that endgames with all the pawns on only one flank are
drawish is a well-known chess idea, so it seems quite strange that
this can be removed so easily without losing Elo.
In the past there had been attempts to improve on PawnsOnBothFlanks
with similar concepts (for instance using the pawn span value), but
the tests were at best neutral. Maybe Stockfish is now mature enough
that these refined ideas would work to replace PawnsOnBothFlanks?
MJZ1977 [Wed, 29 Aug 2018 00:27:47 +0000 (02:27 +0200)]
Fix bug with "excludedMove" for probcut
Bugfix: "excludedMove" has to be skipped in the probcut loop too.
If it is not skipped, the probcut can exit quickly with a wrong return
value corresponding to the excluded move. See the following forum
thread for a discussion:
https://groups.google.com/forum/?fromgroups=#!topic/fishcooking/GGithf_VwSU
STC :
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 17130 W: 3747 L: 3617 D: 9766
http://tests.stockfishchess.org/tests/view/
5b8460c40ebc5902bdbb999a
LTC :
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 12387 W: 2064 L: 1930 D: 8393
http://tests.stockfishchess.org/tests/view/
5b8466f90ebc5902bdbb9a21
To go further : it can be perhaps useful to tune the singular extension
search parameters.
Closes https://github.com/official-stockfish/Stockfish/pull/1754
Bench:
4308541
Steinar H. Gunderson [Wed, 29 Aug 2018 00:00:14 +0000 (02:00 +0200)]
Shrink the hash table of tablebases back to 4096 entries
There is no need to make this as large as 65536 just for the sake of the
single 7-man tablebase that happens to have the key 0xf9247fff. Idea for the
fix by Ronald de Man, who suggested simply to allow more buckets past the end.
We also implement Robin Hood hashing for the hash table, which takes the worst
-case search for full 7-man tablebases down from 68 to 11 probes (Also takes
the average probe length from 2.06 to 2.05). For a table with 8K entries, the
corresponding numbers would be worst-case from 9 to 4, with average from 1.30
to 1.29.
https://github.com/official-stockfish/Stockfish/pull/1747
No functional change
Ondrej Mosnacek [Tue, 28 Aug 2018 23:22:22 +0000 (01:22 +0200)]
Refactor pure static eval code
This commit tries to make the new pure static eval code more readable by
splitting up the nested assignments into separate lines and making a few
more cosmetic tweaks.
No functional change.
protonspring [Mon, 20 Aug 2018 16:29:46 +0000 (10:29 -0600)]
make DistanceRing more consistent
This is a non-functional change. By pre-incrementing minKingPawnDistance
instead of post-incrementing, we can remove this -1.
This also makes DistanceRing more consistent with the rest of stockfish
since it now holds an actual "distance" instead of a less natural distance-1.
In current master, PseudoAttacks[KING][ksq] == DistanceRingBB[ksq][0]
With this patch, it will be PseudoAttacks[KING][ksq] == DistanceRingBB[ksq][1]
ie squares at distance 1 from the king. This is more natural use of distance.
The current array size DistanceRingBB[SQUARE_NB][8] is still OK with the new
definition, because maximum distance between two squares on a chess board is
seven (for example Kh1 and a8).
No functional change.
Vizvezdenec [Tue, 28 Aug 2018 22:50:55 +0000 (00:50 +0200)]
Tweak stat bonus formula
Tweak stat bonus formula on top of latest elo gain by @snicolet
STC
http://tests.stockfishchess.org/tests/view/
5b830a810ebc5902bdbb7e9c
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 27797 W: 6113 L: 5842 D: 15842
LTC
http://tests.stockfishchess.org/tests/view/
5b831f2c0ebc5902bdbb8038
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 13655 W: 2294 L: 2099 D: 9262
I think that more elo can be found in tweaks of this parameters so I plan
to further try some "hand-tuning", including increasing/decreasing ratio of
two constants and making bonus assimetric to 0. Thx to @AndyGrant for helping
with github and @jerrydonaldwatson for original idea.
Closes https://github.com/official-stockfish/Stockfish/pull/1748
Bench:
4172767
VoyagerOne [Wed, 22 Aug 2018 19:51:20 +0000 (15:51 -0400)]
Don't modify Eval with search stats at ttHits
STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 28344 W: 6148 L: 6040 D: 16156
http://tests.stockfishchess.org/tests/view/
5b7d6b4e0ebc5902bdbb1914
LTC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 41084 W: 6769 L: 6680 D: 27635
http://tests.stockfishchess.org/tests/view/
5b7d7f5b0ebc5902bdbb1b85
Bench:
4457440
Stefan Geschwentner [Mon, 20 Aug 2018 10:06:52 +0000 (12:06 +0200)]
Store only unchanged static evaluations in TT
A recent commit introduced a decrease of the static evaluation of
an inner node dependent on the previous stat score, which finally
was also stored in the transposition table. Now only the unchanged
static evaluation are stored there.
Remark:
For the case that a static evaluation can be retrieved from the
transposition table the value is now used unchanged. Another test
which also applies the modification in this case failed:
http://tests.stockfishchess.org/tests/view/
5b7af6df0ebc5902bdbae2f6
STC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 6707 W: 1547 L: 1383 D: 3777
http://tests.stockfishchess.org/tests/view/
5b7a92df0ebc5902bdbadcf3
LTC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 36203 W: 6046 L: 5781 D: 24376
http://tests.stockfishchess.org/tests/view/
5b7abaa10ebc5902bdbadfa9
Closes https://github.com/official-stockfish/Stockfish/pull/1742
Bench:
4457440
Stéphane Nicolet [Fri, 17 Aug 2018 23:23:36 +0000 (01:23 +0200)]
Use an affine formula to mix stats and eval
Follow-up for the previous patch: we use an affine formula to mix stats
and evaluation in search. The idea is to give a bonus if the previous
move of the opponent was historically bad, and a malus if the previous
move of the opponent was historically good.
More precisely, if x is the stat score of the previous move by the opponent,
we implement the following formulas to tweak the evaluation at an internal
node of the tree for our pruning decisions at this node:
if x = 0, use v' = eval(P)
if x > 0, use v' = eval(P) - 5 - x/1024
if x < 0, use v' = eval(P) + 5 - x/1024
For reference, the previous master had this simpler rule:
if x > 0, use v' = eval(P) - 10
if x <= 0, use v' = eval(P)
STC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 29322 W: 6359 L: 6088 D: 16875
http://tests.stockfishchess.org/tests/view/
5b76a5980ebc5902bdba957f
LTC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 30893 W: 5154 L: 4910 D: 20829
http://tests.stockfishchess.org/tests/view/
5b76ca6d0ebc5902bdba9914
Closes https://github.com/official-stockfish/Stockfish/pull/1740
Bench:
4592766
VoyagerOne [Thu, 16 Aug 2018 21:58:48 +0000 (23:58 +0200)]
Mix search stats with evaluation
Mix search stats with evaluation: if the opponent's move has a good historyStat,
then decrease the evaluation of the internal node a bit for the pruning decisions
during search.
STC;
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 72083 W: 15683 L: 15203 D: 41197
http://tests.stockfishchess.org/tests/view/
5b74c3ea0ebc5902bdba7d41
LTC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 29104 W: 4867 L: 4630 D: 19607
http://tests.stockfishchess.org/tests/view/
5b7565000ebc5902bdba851b
Closes https://github.com/official-stockfish/Stockfish/pull/1738
Bench:
4514101
-----------
How to continue from there?
• the use of the previous stat score can probably be simplified in lines 587 and 716
• we could try to use a continuous bonus based on the previous stat score, instead
of just a fixed offset of -10 when the opponent previous move was good.
----------
Comments by Stefan Geschwentner:
Interesting idea. Because only the eval in search is tweak this should only
influence the eval and static eval used at inner nodes, and not on the return
search value (which comes in the end from quiescence search), except through
saving in TT followed by a TT cutoff.
So essentialy this effects diverse pruning/reduction parts -- eval and static
eval are lowered for good opponent moves:
• tt cutoff (ttValue)
• improving (static eval)
• more razoring (eval)
• less futility pruning (eval)
• less null move pruning (eval + static eval) (but with little more depth)
• more probcut (static eval)
• more move futility pruning (static eval)
protonspring [Fri, 17 Aug 2018 08:19:32 +0000 (10:19 +0200)]
Simplify king file dependancy in evaluate_shelter()
Remove the special value we used for the file of the king in the
evaluate_shelter() function, and compensate by tweaking some of
the ShelterStrength[] array values.
STC
LLR: 2.94 (-2.94,2.94) [-3.00,1.00]
Total: 17069 W: 3782 L: 3652 D: 9635
http://tests.stockfishchess.org/tests/view/
5b75eb0d0ebc5902bdba8f3d
LTC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 42639 W: 6973 L: 6887 D: 28779
http://tests.stockfishchess.org/tests/view/
5b75fd7f0ebc5902bdba906b
Closes https://github.com/official-stockfish/Stockfish/pull/1739
Bench:
4639508
Stéphane Nicolet [Tue, 14 Aug 2018 07:24:26 +0000 (09:24 +0200)]
Double weight of capture history
We double in this patch the weight of the capture history table in the
local scoring of captures for move ordering.
The capture history table is indexed by the triplet (capturing piece,
capture square, captured piece) and gets information like "it seems to
have been historically good in that part of the search tree to capture
a pawn with a rook on g3, even if it seems to lose material", and affect
the normaly pure « Most Valuable Victim » ordering of captures.
Finished yellow at STC after 228842 games (posting a +1.36 Elo gain):
LLR: -2.95 (-2.94,2.94) [0.00,4.00]
Total: 228842 W: 50894 L: 50152 D: 127796
http://tests.stockfishchess.org/tests/view/
5b714bb00ebc5902bdba332d
Passed LTC:
LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 43251 W: 7425 L: 7131 D: 28695
http://tests.stockfishchess.org/tests/view/
5b71c7d40ebc5902bdba3e51
Thanks to user Vizvezdenec for running the LTC test.
Closes https://github.com/official-stockfish/Stockfish/pull/1736
Bench:
4272361
Alain SAVARD [Tue, 14 Aug 2018 06:31:56 +0000 (08:31 +0200)]
Remove pawncount array in imbalance
This is a natural follow up to last commit where values on the
QuadraticOurs diagonal and some piece value deltas were changed.
@Stefano80 tried to simplify the newly introduced pawncount array
using QuadraticOurs[1][1] =52 and a -30 adjustment on pawn values
His STC [-3,1] was green
http://tests.stockfishchess.org/tests/view/
5b707f5b0ebc5902bdba2745
but not his LTC[-3,1]
http://tests.stockfishchess.org/tests/view/
5b7095700ebc5902bdba2a49
So I started a 80000 30+0.3 SPSA on the QuadraticOurs diagonal and
on the piece values using @Stefano80 start values.
SPSA gave the new values QuadraticOurs[1][1] =38 and a -33 on pawn
values (the other changes on QuadraticOurs were kept, but were not
ignificant according to this test
http://tests.stockfishchess.org/tests/view/
5b710ccb0ebc5902bdba2f27)
STC
http://tests.stockfishchess.org/tests/view/
5b710b220ebc5902bdba2f19
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 50902 W: 11214 L: 11150 D: 28538
LTC
http://tests.stockfishchess.org/tests/view/
5b7124ef0ebc5902bdba3106
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 34271 W: 5852 L: 5753 D: 22666
Closes https://github.com/official-stockfish/Stockfish/pull/1735
bench:
4738555
GuardianRM [Sun, 12 Aug 2018 16:40:03 +0000 (18:40 +0200)]
Non-linear bonus for pawn count
This patch introduces a non-linear bonus for pawns, along with some
(linear) corrections for the other pieces types.
The original values were obtained by a massive non-linear tuning of both
pawns and other pieces by GuardianRM, while Alain Savard and Chris Cain
later simplified the patch by observing that, apart from the pawn case, the
tuned corrections were in fact almost affine and could be incorporated in
our current code base via the piece values in types.h (offset) and the diagonal
of the quadratic matrix (slope). See discussion in PR#1725 :
https://github.com/official-stockfish/Stockfish/pull/1725
STC:
LLR: 2.97 (-2.94,2.94) [0.00,5.00]
Total: 42948 W: 9662 L: 9317 D: 23969
http://tests.stockfishchess.org/tests/view/
5b6ff6e60ebc5902bdba1d87
LTC:
LLR: 2.97 (-2.94,2.94) [0.00,5.00]
Total: 19683 W: 3409 L: 3206 D: 13068
http://tests.stockfishchess.org/tests/view/
5b702dbd0ebc5902bdba216b
How to continue from there?
- Maybe the non-linearity for the pawn value could be somewhat tempered
again and a simpler linear correction for pawns would work?
Closes https://github.com/official-stockfish/Stockfish/pull/1734
Bench:
4681496
Stefano Cardanobile [Sun, 12 Aug 2018 08:02:51 +0000 (10:02 +0200)]
Combo of several promising parameter tweaks
Combo of several tuning patches which finished yellow at LTC.
[STC](http://tests.stockfishchess.org/tests/view/
5b6ead340ebc5902bdba14ce)
LR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 10668 W: 2445 L: 2239 D: 5984
Elo: 6.25 [1.76,10.69] (95%)
[LTC](http://tests.stockfishchess.org/tests/view/
5b6eb50e0ebc5902bdba151f)
LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 23761 W: 4155 L: 3923 D: 15683
Elo: 3.02 [0.29,5.67] (95%)
Original patches:
- [Piece values](http://tests.stockfishchess.org/tests/view/
5b6d2cc00ebc5902bdba02d5) by Stefano Cardanobile
- [Stat bonus](http://tests.stockfishchess.org/tests/view/
5b6adbc90ebc5902bdb9da73) by Stefan Geschwentner
- [Rook on pawn](http://tests.stockfishchess.org/tests/view/
5b62a95b0ebc5902bdb961c0) by Mark Tenzer
- [Hanging bonus](http://tests.stockfishchess.org/tests/view/
5b5d2fa00ebc5902bdb90855) by Ivan Ilvec
- [ss tweak](http://tests.stockfishchess.org/tests/view/
5b58b7240ebc5902bdb89025) by miguel-l
Bench:
4694813
Jerry Donald Watson [Sun, 12 Aug 2018 07:47:30 +0000 (09:47 +0200)]
Simple razoring: depth 1 only, no distinction between PV / NonPV
We simplify the razoring logic by applying it to all nodes at depth 1 only.
An added advantage is that only one razor margin is needed now, and we treat
PV and Non-PV nodes in the same manner.
How to continue?
- There may be some conditions in which depth 2 razoring is beneficial.
- We can see whether the razor margin can be tuned, perhaps even with a
different value for PV nodes.
- Perhaps we can unify the treatment of PV and Non-PV nodes in other parts
of the search as well.
STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 5474 W: 1281 L: 1127 D: 3066
http://tests.stockfishchess.org/tests/view/
5b6de3b20ebc5902bdba0d1e
LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 62670 W: 10749 L: 10697 D: 41224
http://tests.stockfishchess.org/tests/view/
5b6dee340ebc5902bdba0eb0
In addition, we ran a fixed LTC test against a similar patch which also
passed SPRT [-3, 1]:
ELO: 0.23 +-2.1 (95%) LOS: 58.6%
Total: 36412 W: 6168 L: 6144 D: 24100
http://tests.stockfishchess.org/tests/view/
5b6e83940ebc5902bdba1485
We are opting for this patch as the more logical and simple of the two,
and it appears to be no less strong. Thanks in particular to @DU-jdto
for input into this patch.
Bench:
4476945
Miguel Lahoz [Thu, 9 Aug 2018 14:04:36 +0000 (22:04 +0800)]
Remove Condition For Passed Pawns
Currently, we do not consider pawns passed if there is another pawn of
the same color in front of them. It appears that this condition is not
necessary. The idea is that the doubled pawns are likely to be weak and
one of them will be likely captured anyway. On the other hand, if we do
somehow manage to promote a pawn, then the pawn behind it becomes passed
as well. In any case, the end result is we end up with an extra
potentially passed pawn. The current evaluation for passed pawns already
handles this case by also scaling down this effect.
STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 28291 W: 6287 L: 6178 D: 15826
http://tests.stockfishchess.org/tests/view/
5b6c4b960ebc5902bdb9f256
LTC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 30717 W: 5256 L: 5151 D: 20310
http://tests.stockfishchess.org/tests/view/
5b6c82980ebc5902bdb9f863
Bench:
4938285
Stefan Geschwentner [Wed, 8 Aug 2018 07:45:58 +0000 (09:45 +0200)]
LMR simplification
Unify the "quiet" and "non-quiet" reduction rules for use at any kind of moves.
The idea behind it was that both rules reduce at similiar cases in master:
one directly for late previous moves and the other indirectly by using a
bad stat score which is used for most move sorting and so approximates the
late move condition.
For captures/promotions the old rule was triggered in 25% but the new
rule only for 3% of all cases (so now more reductions are done, whereas
for quiet moves reductions keep the same level).
STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 162327 W: 35976 L: 36134 D: 90217
http://tests.stockfishchess.org/tests/view/
5b6a9a430ebc5902bdb9d5c1
LTC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 29570 W: 5083 L: 4976 D: 19511
http://tests.stockfishchess.org/tests/view/
5b6bc5d00ebc5902bdb9e9d6
Bench:
4526980
Stefano Cardanobile [Wed, 8 Aug 2018 12:27:28 +0000 (14:27 +0200)]
First check threshold in space evaluation
Currently, we first calculate some bitboards at the top of Evaluation::space()
and then check whether we actually need them. Invert the ordering. Of course this
does not make a difference in current master because the constexpr bitboard
calculations are in fact done at compile time by any decent compiler, but I find
my version a bit healthier since it will always meet or exceed current implementation
even if we eventually change the spaceMask to something not contsexpr.
No functional change.
FauziAkram [Wed, 8 Aug 2018 15:48:06 +0000 (17:48 +0200)]
King Psqt Tuning
After a session of tuning for King Psqt I got some new values, which was later
tweaked manually by me Fauzi, to result in an Elo-gain patch which seems to scale
pretty well:
STC: LLR: -2.96 (-2.94,2.94) [0.00,4.00]
Total: 100653 W: 22550 L: 22314 D: 55789 [Yellow patch]
LTC: LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 147079 W: 25584 L: 24947 D: 96548 [Green Patch]
Bench:
4669050
Stefano Cardanobile [Wed, 4 Jul 2018 19:54:38 +0000 (21:54 +0200)]
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)
Marco Costalba [Sat, 28 Jul 2018 13:33:39 +0000 (15:33 +0200)]
Improve Stats definition
Use operator const T&() instead of operator T() to avoid possible
costly hidden copies of non-scalar nested types.
Currently StatsEntry has a single member T, so assuming
sizeof(StatsEntry) == sizeof(T) it happens to work, but it's
better to use the size of the proper entry type in std::fill.
Note that current code works because std::array items are ensured
to be allocated in contiguous memory and there is no padding among
nested arrays. The latter condition does not seem to be strictly
enforced by the standard, so be careful here.
Finally use address-of operator instead of get() to fully hide the
wrapper class StatsEntry at calling sites. For completness add
the arrow operator too and simplify the C++ code a bit more.
Same binary code as previous master under the Clang compiler.
No functional change.
Marco Costalba [Sat, 28 Jul 2018 08:38:36 +0000 (10:38 +0200)]
Small tweaks to recent code changes
As a note, current 2 LMR conditions on stat score
could be simplified in a single line:
r -= ((ss->statScore >= 0) - ((ss-1)->statScore >= 0)) * ONE_PLY;
We keep them splitted in 2 "if" statements because are easier
to (immediately) read.
No functional change.
noobpwnftw [Thu, 26 Jul 2018 19:18:04 +0000 (03:18 +0800)]
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
```
Stéphane Nicolet [Sun, 29 Jul 2018 23:41:04 +0000 (01:41 +0200)]
Introduce tropism measure in king danger
This patch adds the tropism measure as a new term in the king danger variable.
Since we then trasform this variable as a Score via a quadratic formula, the
main effect of the patch is the positive correlation of the tropism measure
with some checks and pins information already present in the king danger code.
STC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 6805 W: 1597 L: 1431 D: 3777
http://tests.stockfishchess.org/tests/view/
5b5df8d10ebc5902bdb91699
LTC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 32872 W: 5782 L: 5523 D: 21567
http://tests.stockfishchess.org/tests/view/
5b5e08d80ebc5902bdb917ee
How to continue from there?
• it may be possible to use CloseEnemies=S(7,0)
• we may want to try incorporating other strategic features in the quadratic
king danger.
Closes https://github.com/official-stockfish/Stockfish/pull/1717
Bench:
5591925
Miguel Lahoz [Fri, 27 Jul 2018 16:23:53 +0000 (00:23 +0800)]
Increase the mg->eg gradient for the PawnlessFlank malus
Just a change of value to S(19, 84). Also somewhat of a follow up
to the recent tweak in definition of KingFlank.
I tried a lot of other values before this, increasing and decreasing
but with little success, and before giving up I wanted to try tweaking
the middlegame and endgame values in the opposite directions. I guess
this is somewhat lucky.
STC:
LLR: 2.94 (-2.94,2.94) [0.00,4.00]
Total: 67685 W: 15399 L: 14963 D: 37323
http://tests.stockfishchess.org/tests/view/
5b5b5ae80ebc5902bdb8e4f8
LTC: (Also thanks to Stephane Nicolet)
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 54635 W: 9505 L: 9172 D: 35958
http://tests.stockfishchess.org/tests/view/
5b5b78f20ebc5902bdb8ece5
Closes https://github.com/official-stockfish/Stockfish/pull/1714
Bench:
4883742
VoyagerOne [Fri, 27 Jul 2018 14:23:05 +0000 (16:23 +0200)]
Simplify cmh pruning
Simplify cmh pruning by removing PvNode exception
STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 9935 W: 2330 L: 2184 D: 5421
http://tests.stockfishchess.org/tests/view/
5b587dc00ebc5902bdb88424
LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 20635 W: 3585 L: 3464 D: 13586
http://tests.stockfishchess.org/tests/view/
5b58910a0ebc5902bdb885b9
Closes https://github.com/official-stockfish/Stockfish/pull/1711
Bench:
4905530
Stéphane Nicolet [Fri, 27 Jul 2018 13:46:13 +0000 (15:46 +0200)]
Fix a compilation error for MSVC
The previous commit wouldn't compile on the Microsoft Virtual Studio C++ compiler. So use a more compatible style for the same idea (which we already use in numerous places of evaluate.cpp, for instance in line 563).
Under the Clang compiler, both versions generate exactly the same machine code (same md5 signatures for the two binaries).
No functional change.
Stéphane Nicolet [Fri, 27 Jul 2018 07:39:06 +0000 (09:39 +0200)]
Remove a popcount for HinderPassedPawn
Remove a popcount for HinderPassedPawn, and compensate by doubling
the bonus from S(4,0) to to S(8,0).
Maybe it was pure luck, but we got the idea of this Elo gaining patch by
seing the simplification attempt by Mike Whiteley in pull request #1703.
This suggests that whenever we have a passed evaluation simplification,
we should consider the possibility that the master bonus has become
slightly out of tune with time, and we should try a few Elo gaining [0..4]
tests by hand-tuning the master bonus.
STC:
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 19136 W: 4388 L: 4147 D: 10601
http://tests.stockfishchess.org/tests/view/
5b59be6f0ebc5902bdb8ac06
LTC:
LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 99382 W: 17324 L: 16843 D: 65215
http://tests.stockfishchess.org/tests/view/
5b59d2410ebc5902bdb8afa8
Closes https://github.com/official-stockfish/Stockfish/pull/1710
Bench:
4688817
Miguel Lahoz [Wed, 25 Jul 2018 16:11:51 +0000 (00:11 +0800)]
Tweak KingFlank when king is on edge files
This tweak excludes files D and E from the KingFlank bitboard when our
king is on the A or H files respectively. As far as I can tell, this
affects two things: the calculation for CloseEnemies and PawnlessFlank.
Aside from filtering out slightly less relevant attacks in the flank,
I suspect this helps with king prophylaxis, avoiding attacks and moving
towards the center when the pawns start to come off.
STC
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 56755 W: 12881 L: 12489 D: 31385
http://tests.stockfishchess.org/tests/view/
5b58a94c0ebc5902bdb88c72
LTC
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 130205 W: 22536 L: 21957 D: 85712
http://tests.stockfishchess.org/tests/view/
5b58b7580ebc5902bdb89029
How to continue: Tweaking the two bonuses mentioned might give some
gain, although as far as I can tell, CloseEnemies is very sensitive to
even small changes.
Closes https://github.com/official-stockfish/Stockfish/pull/1705
Bench:
5026009
Jekaa [Fri, 27 Jul 2018 08:24:49 +0000 (10:24 +0200)]
Small reformat in evaluate threats (non functional)
When evaluating threat by safe pawn and pawn push the same expression is used.
STC
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 19444 W: 4540 L: 4309 D: 10595
http://tests.stockfishchess.org/tests/view/
5b5a6e150ebc5902bdb8c5c0
Closes https://github.com/official-stockfish/Stockfish/pull/1709
No functional change.
--------------------
Comments by Stéphane Nicolet:
I don't measure any speed-up on my system, with two parallel benches at depth 22:
Total time (ms) : 74989
Nodes searched :
144830258
Nodes/second :
1931353
master
Total time (ms) : 75341
Nodes searched :
144830258
Nodes/second :
1922329
testedpatch
And anyway, like Stefan Geschwentner, I don't think that a 0.3% speed-up would
be enough to pass a [0..5] LTC test -- as a first approximation, we have this
rule of thumb that 1% speed-up gives about 1 Elo point.
However, considering the facts that the reformatting by itself is interesting,
that this is your first green test and that you played by the rules by running
the SPRT[0..5] test before opening the pull request, I will commit the change.
I will only take the liberty to change the occurrences of safe in lines 590 and
591 to b, to make the code more similar to lines 584 and 585.
So approved, and congrats :-)
ianfab [Wed, 25 Jul 2018 19:02:28 +0000 (21:02 +0200)]
Fix condition for error message of signature script
Use obtained bench instead of reference bench when checking for crash.
No functional change.
protonspring [Thu, 26 Jul 2018 07:34:14 +0000 (09:34 +0200)]
Remove condition for pawn threats
It appears as though removing squares that are already attacked
by our pawns can be removed.
STC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 51242 W: 11503 L: 11440 D: 28299
http://tests.stockfishchess.org/tests/view/
5b58b5a40ebc5902bdb88f52
LTC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 35246 W: 6063 L: 5966 D: 23217
http://tests.stockfishchess.org/tests/view/
5b58f8e20ebc5902bdb8959b
How to continue after this patch: there is now a slight semantic
overlap between the ThreatByPawnPush and the ThreatBySafePawn bonuses,
so hand-tuning either of these, or both at the same time, is natural.
Closes https://github.com/official-stockfish/Stockfish/pull/1702
Bench
4734881
Stefan Geschwentner [Wed, 25 Jul 2018 23:28:37 +0000 (01:28 +0200)]
Rank threats on pinned pawns
Add for pinned pawns half of the standard rank based threat bonus.
STC:
LLR: 2.97 (-2.94,2.94) [0.00,5.00]
Total: 44010 W: 9987 L: 9635 D: 24388
http://tests.stockfishchess.org/tests/view/
5b58aa780ebc5902bdb88c7a
LTC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 29475 W: 5089 L: 4847 D: 19539
http://tests.stockfishchess.org/tests/view/
5b58b56c0ebc5902bdb88f37
Closes https://github.com/official-stockfish/Stockfish/pull/1701
Bench:
4503866
Stéphane Nicolet [Wed, 25 Jul 2018 16:31:02 +0000 (18:31 +0200)]
Code clean-up
This patch implements some idea by Alain Savard and Mike Whiteley taken from the perpertual renaming/reformatting thread.
This is a pure code cleaning patch (so no change in functionality), but I use it as a pretext to correct the bogus bench number that I introduced in the previous commit.
Bench:
4413383
Stefan Geschwentner [Wed, 25 Jul 2018 16:01:47 +0000 (18:01 +0200)]
Tweak stat bonus
Increase stat bonus by 1/32 and adjust the divisor of main and capture
history tables to 10692.
STC:
LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 28437 W: 6444 L: 6166 D: 15827
http://tests.stockfishchess.org/tests/view/
5b579b4d0ebc5902bdb87139
LTC:
LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 111204 W: 19160 L: 18644 D: 73400
http://tests.stockfishchess.org/tests/view/
5b57a7c60ebc5902bdb872d3
Closes https://github.com/official-stockfish/Stockfish/pull/1698
Bench:
4778882
VoyagerOne [Wed, 25 Jul 2018 11:49:35 +0000 (07:49 -0400)]
CounterMove History Pruning Tweak
STC: (Yellow)
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 40124 W: 8817 L: 8751 D: 22556
http://tests.stockfishchess.org/tests/view/
5b5690180ebc5902bdb85c8a
LTC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 21599 W: 3811 L: 3599 D: 14189
http://tests.stockfishchess.org/tests/view/
5b5757010ebc5902bdb86b1f
Closes https://github.com/official-stockfish/Stockfish/pull/1697
Bench:
4794161
Stefan Geschwentner [Tue, 24 Jul 2018 10:16:49 +0000 (12:16 +0200)]
Revert "Tweak reductions formula: 0.88 * depth + 0.12"
This patch reverts the recent commit called "Tweak reductions formula, etc."
The decisions for the revert decision were as follows:
1) The original commit called "Tweak reductions formula: 0.88 * depth + 0.12"
showed bad scaling at in a Very Long Time Control (VLTC) test:
VLTC (180+1.8):
LLR: -1.59 (-2.94,2.94) [0.00,5.00]
Total: 14968 W: 2247 L: 2257 D: 10464
http://tests.stockfishchess.org/tests/view/
5b559ffa0ebc5902bdb84f36
2) So there was a suspicion that the original fast passing LTC test which lead
us to accept the patch may have been a statistical accident, so we organized
a match against the previous master at LTC to get an Elo estimate for the
patch:
LTC match:
ELO: -1.83 +-2.1 (95%) LOS: 4.3%
Total: 36018 W: 6018 L: 6208 D: 23792
http://tests.stockfishchess.org/tests/view/
5b55f8110ebc5902bdb8526f
3) Based on these results, we ran a simplification test with [-3..1] bounds
for the revert at LTC:
LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 41501 W: 7107 L: 7020 D: 27374
http://tests.stockfishchess.org/tests/view/
5b5738670ebc5902bdb86932
4) So we revert.
Bench:
4491691
double-beep [Mon, 23 Jul 2018 20:06:24 +0000 (22:06 +0200)]
Slight decrease of overload value
Set overload value to S(13,6)
STC:
LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 27606 W: 6371 L: 6094 D: 15141
http://tests.stockfishchess.org/tests/view/
5b5455840ebc5902bdb82425
LTC:
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 112435 W: 19442 L: 18921 D: 74072
http://tests.stockfishchess.org/tests/view/
5b546d4a0ebc5902bdb82741
Closes https://github.com/official-stockfish/Stockfish/pull/1694
Bench:
4937000
Stefan Geschwentner [Mon, 23 Jul 2018 07:16:14 +0000 (09:16 +0200)]
Tweak reductions formula: 0.88 * depth + 0.12
Replace the depth part in the reduction formula for higher depths
with a slower growing linear function. So for depth > 3 less reductions
are used.
What we can try next:
- move the break point to even higher depths
- tweak the slope for lower and higher depth
- even possibly use a further higher depth threshold for a another
slower growing function
STC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 25317 W: 5763 L: 5505 D: 14049
http://tests.stockfishchess.org/tests/view/
5b54f9f70ebc5902bdb840ed
LTC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 7451 W: 1320 L: 1167 D: 4964
http://tests.stockfishchess.org/tests/view/
5b54feeb0ebc5902bdb84244
Closes https://github.com/official-stockfish/Stockfish/pull/1692
Bench:
4617359
Goodkov Vasiliy Aleksandrovich [Sun, 22 Jul 2018 22:02:37 +0000 (00:02 +0200)]
Simplify condition for ThreatByRook
Remove stronglyProtected Queen for ThreatByRook. Idea is that in the
current master the SliderOnQueen bonus and the see_ge() function do
something similar as ThreatByRook for Queen, so this patch removes
some redundancy, in that sense.
STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 21878 W: 4939 L: 4818 D: 12121
http://tests.stockfishchess.org/tests/view/
5b53a83b0ebc5902bdb815d1
LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 35307 W: 5979 L: 5882 D: 23446
http://tests.stockfishchess.org/tests/view/
5b53b60b0ebc5902bdb8174c
Close https://github.com/official-stockfish/Stockfish/pull/1690
Bench:
4834554
protonspring [Sat, 21 Jul 2018 06:17:27 +0000 (00:17 -0600)]
simplified forward ranks.
This is a non-functional simplification. We change replaces an 'OR'
and a lookup (rank_bb(ksq)) with a bitwise ~. This is fewer operations
and is probably faster.
STC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 25441 W: 5689 L: 5575 D: 14177
http://tests.stockfishchess.org/tests/view/
5b52d05a0ebc5902bdb8010e
LTC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 26904 W: 4664 L: 4553 D: 17687
http://tests.stockfishchess.org/tests/view/
5b543df70ebc5902bdb8212d
No functional change.
Marco Costalba [Sat, 21 Jul 2018 08:30:22 +0000 (10:30 +0200)]
Slight tidy up in endgame machinery
No functional change.
Stefan Geschwentner [Sat, 21 Jul 2018 02:21:54 +0000 (04:21 +0200)]
Non functional LMR rewrite.
Alain SAVARD [Fri, 20 Jul 2018 23:57:45 +0000 (19:57 -0400)]
Simplify the "overload" condition
This is a follow-up of the previous pull request (#1686) by Miguel.
We simplify the "Overload" bonus condition by re-using the "weak"
variable, which captures well the essence of the overload condition.
This may also be a small speed optimization because the weak variable
is in a register at this point of the code.
http://tests.stockfishchess.org/tests/view/
5b527b440ebc5902bdb7f7db
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 10925 W: 2517 L: 2374 D: 6034
http://tests.stockfishchess.org/tests/view/
5b527f930ebc5902bdb7f883
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 15569 W: 2697 L: 2568 D: 10304
Closes https://github.com/official-stockfish/Stockfish/pull/1687
Bench:
5010472
Miguel Lahoz [Thu, 19 Jul 2018 11:18:30 +0000 (19:18 +0800)]
Remove connectivity.
There seems to be some strange interaction between Overload and Connectivity.
Overload encourages us to not have too many defended and attacked pieces,
as this may expose us to various tactics. This feels somewhat like it is in
conflict with Connectivity, where pieces are defended preemptively.
Here I take the "pick one or the other" approach and just remove connectivity,
while strengthening the effect of Overload to compensate. The reasoning is that
if we defend our pieces preemptively, then it does get attacked, we want to do
something about it so we don't get penalized by Overload. On the other
hand, if it doesn't get attacked, then there's no need to defend it.
STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 27734 W: 6174 L: 6064 D: 15496
http://tests.stockfishchess.org/tests/view/
5b5073bd0ebc5902bdb7ba5c
LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 51606 W: 8897 L: 8827 D: 33882
http://tests.stockfishchess.org/tests/view/
5b50aa900ebc5902bdb7bf29
Bench:
4658006
Stefan Geschwentner [Thu, 19 Jul 2018 16:26:05 +0000 (18:26 +0200)]
Better check evasion move sorting
Use in addition the counter move history table for sorting quiet
check evasion moves in main and quiecence search. Also rename
"contHistory" to "continuationHistory" while there.
STC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 73284 W: 16433 L: 15938 D: 40913
http://tests.stockfishchess.org/tests/view/
5b4f526e0ebc5902bdb7a401
LTC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 12135 W: 2171 L: 1997 D: 7967
http://tests.stockfishchess.org/tests/view/
5b4fc0ef0ebc5902bdb7ae0e
Closes https://github.com/official-stockfish/Stockfish/pull/1685
Bench
4817583
Miguel Lahoz [Mon, 16 Jul 2018 16:51:43 +0000 (00:51 +0800)]
Use single value for KingProtector.
After some recent big tuning session, the values for King Protector were
simplified to only be used on minor pieces. This patch tries to further
simplify by just using a single value, since current S(6,5) and S(5,6)
are close to each other. The value S(6,6) ended up passing, although
S(5,5) was also tried and failed STC.
STC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 14261 W: 3288 L: 3151 D: 7822
http://tests.stockfishchess.org/tests/view/
5b4ccdf50ebc5902bdb77f65
LTC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 19606 W: 3396 L: 3273 D: 12937
http://tests.stockfishchess.org/tests/view/
5b4ce4280ebc5902bdb7803b
Bench:
5448998
ElbertoOne [Wed, 18 Jul 2018 06:36:23 +0000 (08:36 +0200)]
Simplify Overload condition
Extend the bonus for Overload to cases where our side
has more than one attacker to a non pawn piece.
Based on an idea by Bryan in the forum. For instance,
now black gets the overload bonus in this position:
8/5R1k/6pb/p6p/P1N4P/1Pp5/2K3P1/2N4r b - - 6 46
because two black pieces are attacking the knight on c1
that is defended only by the king.
STC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 57446 W: 12762 L: 12711 D: 31973
http://tests.stockfishchess.org/tests/view/
5b4ca9970ebc5902bdb77a88
LTC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 42113 W: 7295 L: 7209 D: 27609
http://tests.stockfishchess.org/tests/view/
5b4ccea00ebc5902bdb77f69
Bench:
4667263
DU-jdto [Mon, 16 Jul 2018 20:53:50 +0000 (06:53 +1000)]
Minor code style tweaks
No functional change.
ianfab [Sun, 15 Jul 2018 12:30:59 +0000 (14:30 +0200)]
Minor whitespace formatting changes
No functional change.
Gian-Carlo Pascutto [Tue, 17 Jul 2018 21:13:12 +0000 (23:13 +0200)]
Allow Position::init() to be called multiple times.
For the rationale to allow this, see commit
a66c73deef420104e74b6645ee60e20b37fd8549
This was broken when cuckoo hashing was added, and
subtly broke (for example) lichess' Android application,
thus illustrating the original judgement was sound.
No functional change.
protonspring [Sat, 14 Jul 2018 06:26:57 +0000 (08:26 +0200)]
Remove rank limitation for MinorBehindPawn
This is a functional simplification. It seems like the rank restriction
for MinorBehindPawn can be removed.
STC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 61195 W: 13404 L: 13360 D: 34431
http://tests.stockfishchess.org/tests/view/
5b47e6f00ebc5978f4be3fc0
LTC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 31701 W: 5367 L: 5264 D: 21070
http://tests.stockfishchess.org/tests/view/
5b48a2cb0ebc5978f4be4769
Bench:
4938702
candirufish [Sat, 14 Jul 2018 06:08:32 +0000 (08:08 +0200)]
Tuned Values after 2 million spsa games
Various king and pawn eval values tuned after 2 million games. Rounding
slightly adjusted.
LTC: http://tests.stockfishchess.org/tests/view/
5b477a260ebc5978f4be3ed4
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 32783 W: 5852 L: 5588 D: 21343
STC: http://tests.stockfishchess.org/tests/view/
5b472d420ebc5978f4be3e4d
LLR: 3.23 (-2.94,2.94) [0.00,4.00]
Total: 44380 W: 10201 L: 9841 D: 24338
I think I reached the limit of the fishtest framework. It frequently
crashed at 2 million games already. The small values also moved a lot
throughout the entire tuning session though with smaller margin. The
passed danger and close enemies values seems the most sensitive (changing
close enemies alone to 6 failed before but now it passes), whether or not
they are close to optimal I don't know, but it seems some parameters are
also correlated to others.
Closes https://github.com/official-stockfish/Stockfish/pull/1670
bench:
5103722
Joost VandeVondele [Thu, 5 Jul 2018 16:33:18 +0000 (18:33 +0200)]
Remove offset in thread redistribution scheme.
doesn't have a benefit.
passed STC (8 threads):
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 19574 W: 4028 L: 3904 D: 11642
http://tests.stockfishchess.org/tests/view/
5b3e48950ebc5902b9fff080
passed LTC (8 threads):
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 21293 W: 3626 L: 3506 D: 14161
http://tests.stockfishchess.org/tests/view/
5b3eefd60ebc5902b9fffa81
Closes https://github.com/official-stockfish/Stockfish/pull/1667
No functional change single threaded.
31m059 [Thu, 5 Jul 2018 02:18:52 +0000 (22:18 -0400)]
Simplify ThreatByKing to be a single Score.
In the current master, ThreatByKing is an array of two Scores, one for
when we have a single attack and one for when we have many. The latter
case is very rarely called during bench and was recently given a strange
negative value during a tuning run, as pointed out by @candirufish on
commit
efd4ca2. Here, we simplify away this second case entirely, and
increase the remaining ThreatByKing to compensate.
Although I derived the parameter tweak independently, with the goal of
preserving the same average bonus, I later noticed that a very similar
Score had already been derived by an ongoing SPSA tuning session.
I therefore recognize @candirufish for first discovering these values.
I would also like to thank @Rocky640 for valuable feedback that pointed
me in the direction of ThreatByKing.
STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 7677 W: 1772 L: 1623 D: 4282
http://tests.stockfishchess.org/tests/view/
5b3db0320ebc5902b9ffe97a
LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 108031 W: 18329 L: 18350 D: 71352
http://tests.stockfishchess.org/tests/view/
5b3dbf4b0ebc5902b9ffe9db
Closes https://github.com/official-stockfish/Stockfish/pull/1666
Bench:
4678861
VoyagerOne [Tue, 3 Jul 2018 23:11:54 +0000 (01:11 +0200)]
Capture Stat Tweak
Penalize capture moves that fail to create a cutoff even at quiet move cutoff.
STC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 19004 W: 4284 L: 4059 D: 10661
http://tests.stockfishchess.org/tests/view/
5b3a7d4d0ebc5902b9ffb6ea
LTC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 23100 W: 3981 L: 3765 D: 15354
http://tests.stockfishchess.org/tests/view/
5b3aa4550ebc5902b9ffb8cf
Closes https://github.com/official-stockfish/Stockfish/pull/1664
Bench:
5232010
Joost VandeVondele [Tue, 3 Jul 2018 22:58:16 +0000 (00:58 +0200)]
Simplify saving a TT entry.
Avoid passing TT.generation() to TTEntry::save() at every call,
moving the implementation of TTEntry::save from tt.h to tt.cpp.
tested for no regression:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 53787 W: 11948 L: 11890 D: 29949
http://tests.stockfishchess.org/tests/view/
5b2ff37f0ebc5902b2e582fe
Closes https://github.com/official-stockfish/Stockfish/pull/1662
No functional change.
Joost VandeVondele [Tue, 3 Jul 2018 22:48:20 +0000 (00:48 +0200)]
Reduce scope of variables
Small cleanup TranspositionTable:clear().
Closes https://github.com/official-stockfish/Stockfish/pull/1659
No functional change.
Ondrej Mosnáček [Sat, 9 Jun 2018 11:45:49 +0000 (13:45 +0200)]
Move PSQ score to Position
This patch simplifies Position::do_move() by moving the PSQ score from
StateInfo to Position and updating it inside the put/remove/move_piece
functions.
The downside is that there is now slightly more computation done in
Position::undo_move(), but the fishtest results are Elo neutral.
Passed STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 78820 W: 15775 L: 15760 D: 47285
http://tests.stockfishchess.org/tests/view/
5b1cd1d00ebc5902ab9c64ab
Passed LTC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 32966 W: 5716 L: 5615 D: 21635
http://tests.stockfishchess.org/tests/view/
5b31e1230ebc5902b2e5a833
Closes https://github.com/official-stockfish/Stockfish/pull/1647
No functional change.
protonspring [Sun, 17 Jun 2018 02:26:25 +0000 (20:26 -0600)]
Remove make_bitboard()
In current master, the function make_bitboard() does nothing apart from
helping initialize the SquareBB[] array. This seems like an unnecessary
abstraction layer.
The advantage of make_bitboard() is we can define a bitboard, in a simple
and general way, not only from a single square but also from a list of
squares. It is more elegant, faster and readable than combining multiple
SquareBB explicitly, but the last complex use case in evaluation was
simplified away a few months ago.
If make_bitboard() becomes useful again to define complicated bitboards,
it will be easy enough to reintroduce it using this pull request as
an implementation reference.
No functional change.
joergoster [Sun, 24 Jun 2018 15:07:38 +0000 (17:07 +0200)]
Simplify KingProtector penalty.
Recent tuning results implied this penalty is more important for knights
and bishops, and almost negligible for rooks and queen.
Passed as simplification both
STC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 20873 W: 4592 L: 4469 D: 11812
http://tests.stockfishchess.org/tests/view/
5b2fb4d00ebc5902b2e57e84
and LTC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 46069 W: 7949 L: 7870 D: 30250
http://tests.stockfishchess.org/tests/view/
5b2fcc4b0ebc5902b2e580c5
Closes https://github.com/official-stockfish/Stockfish/pull/1660
Bench:
5487679
Alain SAVARD [Sun, 24 Jun 2018 22:06:13 +0000 (18:06 -0400)]
Simplify HinderPassedPawn bonus
Make sure each piece is not scored more than once as a passed pawn "hinderer",
by scoring only the blockers along the passed pawn path. Inspired by TCEC Game 29.
Passed STC as a simplification
http://tests.stockfishchess.org/tests/view/
5b3016d00ebc5902b2e58552
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 75388 W: 16656 L: 16641 D: 42091
Passed LTC as a simplification
http://tests.stockfishchess.org/tests/view/
5b302ed90ebc5902b2e587fc
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 49157 W: 8460 L: 8386 D: 32311
Current master was also counting the number of attacks along a passed pawn path,
which might be misleading:
a) a defender might be counted many times for the same pawn path. For example a
White rook on a1 attacking a black pawn on a7 would score the bonus * 6 but
would be probably better placed on a8
b) a defender might be counted on different pawn paths and might be overloaded. For
example a Ke4 or Qe4 against pawns on d6 and f6 would score the bonus * 6.
Counting each blocker or attacker only once is more complicated, and does not help
either: http://tests.stockfishchess.org/tests/view/
5b2ff1cb0ebc5902b2e582b2
After this small simplification, there might be ways to increase the HinderPassedPawn
penalty.
Closes https://github.com/official-stockfish/Stockfish/pull/1661
Bench:
4520519
candirufish [Sat, 23 Jun 2018 06:57:05 +0000 (08:57 +0200)]
Another set of tuned values after one million games
Another set of tuned values, obtained by a long session of one million games.
STC:
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 15810 W: 3687 L: 3458 D: 8665
http://tests.stockfishchess.org/tests/view/
5b2d32f60ebc5902b2e55d9e
LTC:
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 102118 W: 18146 L: 17651 D: 66321
http://tests.stockfishchess.org/tests/view/
5b2d372c0ebc5902b2e55e0a
Closes https://github.com/official-stockfish/Stockfish/pull/1658
Bench:
4557946
Stéphane Nicolet [Thu, 21 Jun 2018 23:28:02 +0000 (01:28 +0200)]
Increase outflanking weight to 12
Give more incentive to king activity in the endgame by increasing the weight
of the "outflanking" variable from 8 to 12 in the function evaluate_initiative().
Finished yellow after 133102 games at STC:
LLR: -3.07 (-2.94,2.94) [0.00,4.00]
Total: 133102 W: 29535 L: 29179 D: 74388
http://tests.stockfishchess.org/tests/view/
5b2b63fe0ebc5902b2e54475
Passed LTC:
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 28027 W: 4918 L: 4672 D: 18437
http://tests.stockfishchess.org/tests/view/
5b2ba39e0ebc5902b2e54a64
Closes https://github.com/official-stockfish/Stockfish/pull/1657
Bench:
4721753
candirufish [Thu, 21 Jun 2018 08:20:31 +0000 (10:20 +0200)]
Tuned values after 505k games
Various king and pawn tuned eval values after 505k 60 sec 600 nodes time
SPSA games. Adjusted passed rank and file values to be symmetrical.
Passed LTC (after passed rank/file adjustment):
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 37906 W: 6953 L: 6668 D: 24285
http://tests.stockfishchess.org/tests/view/
5b2790960ebc5902b8d17ba1
A previous, very similar version with raw tuned values passed STC and LTC:
STC:
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 39515 W: 9227 L: 8900 D: 21388
http://tests.stockfishchess.org/tests/view/
5b277e3e0ebc5902b8d17ac9
LTC:
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 14618 W: 2743 L: 2537 D: 9338
http://tests.stockfishchess.org/tests/view/
5b2785020ebc5902b8d17b98
Closes https://github.com/official-stockfish/Stockfish/pull/1654
bench:
4777396
Michael An [Thu, 21 Jun 2018 01:05:27 +0000 (21:05 -0400)]
Fix GCC 8 cast warnings
Silences the following warnings when compiling with GCC 8.
The fix is to use an intermediate pointer to anonymous function:
```
misc.cpp: In function 'int WinProcGroup::get_group(size_t)':
misc.cpp:241:77: warning: cast between incompatible function types from 'FARPROC' {aka 'long long int (*)()'} to 'fun1_t' {aka 'bool (*)(_LOGICAL_PROCESSOR_RELATIONSHIP, _SYSTEM_LOGICAL_PROCESSOR_INFORMATION_EX*, long unsigned int*)'} [-Wcast-function-type]
auto fun1 = (fun1_t)GetProcAddress(k32, "GetLogicalProcessorInformationEx");
^
misc.cpp: In function 'void WinProcGroup::bindThisThread(size_t)':
misc.cpp:309:71: warning: cast between incompatible function types from 'FARPROC' {aka 'long long int (*)()'} to 'fun2_t' {aka 'bool (*)(short unsigned int, _GROUP_AFFINITY*)'} [-Wcast-function-type]
auto fun2 = (fun2_t)GetProcAddress(k32, "GetNumaNodeProcessorMaskEx");
^
misc.cpp:310:67: warning: cast between incompatible function types from 'FARPROC' {aka 'long long int (*)()'} to 'fun3_t' {aka 'bool (*)(void*, const _GROUP_AFFINITY*, _GROUP_AFFINITY*)'} [-Wcast-function-type]
auto fun3 = (fun3_t)GetProcAddress(k32, "SetThreadGroupAffinity");
^
```
No functional change.
mstembera [Tue, 12 Jun 2018 22:20:38 +0000 (15:20 -0700)]
Fix MSVC error
Compiling the current master with MSVC gives the following error:
```
search.cpp(956): error C2660: 'operator *': function does not take 1 arguments
types.h(303): note: see declaration of 'operator *'
```
This was introduced in commit:
https://github.com/official-stockfish/Stockfish/commit/
88de112b84a5285c2afb3e075a05c2ab8ad3fd33
We use a suggestion by @vondele to fix the error, thanks!
No functional change.
Stefano80 [Wed, 20 Jun 2018 03:24:24 +0000 (05:24 +0200)]
Slight simplification in scale factor computation
[STC](http://tests.stockfishchess.org/tests/view/
5b2614000ebc5902b8d17193)
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 17733 W: 3996 L: 3866 D: 9871
[LTC](http://tests.stockfishchess.org/tests/view/
5b264d0f0ebc5902b8d17206)
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 55524 W: 9535 L: 9471 D: 36518
Use pawn count scaling also for opposite bishops endings with additional material, with a slope of 2 instead of 7. This simplifies slightly the code.
This PR is a functionally equivalent refactoring of the version which was submitted.
Four versions tried, 2 passed both STC and LTC. I picked the one which seemed more promising at LTC.
Slope 4 passed STC (-0.54 Elo), LTC not attempted
Slope 3 passed STC (+2.51 Elo), LTC (-0.44 Elo)
Slope 2 passed STC (+2.09 Elo), LTC (+0.04 Elo)
Slope 1 passed STC (+0.90 Elo), failed LTC (-3.40 Elo)
Bench:
4761613
DU-jdto [Wed, 13 Jun 2018 05:22:52 +0000 (15:22 +1000)]
Remove lmrDepth restriction on quiet see pruning
And tweak the threshold value. With this threshold and the current piece
values, this permits see pruning on quiets to be done up to an lmrDepth
of 9 (beyond that the threshold is below -QueenValueMg and see_ge will
pass unconditionally).
STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 110316 W: 24612 L: 24667 D: 61037
http://tests.stockfishchess.org/tests/view/
5b20aa760ebc5902ab9c9c1d
LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 17352 W: 2968 L: 2842 D: 11542
http://tests.stockfishchess.org/tests/view/
5b20cf1e0ebc5902ab9c9fb6
Closes https://github.com/official-stockfish/Stockfish/pull/1651
Bench:
5069074
Joost VandeVondele [Tue, 12 Jun 2018 05:32:21 +0000 (07:32 +0200)]
Remove depth condition for pruning captures.
The SEE condition alone is sufficient.
passed STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 109863 W: 24339 L: 24392 D: 61132
http://tests.stockfishchess.org/tests/view/
5b1f5b000ebc5902ab9c8668
passed LTC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 23390 W: 4020 L: 3903 D: 15467
http://tests.stockfishchess.org/tests/view/
5b1f94b40ebc5902ab9c8b5e
Closes https://github.com/official-stockfish/Stockfish/pull/1648
Bench:
4834747
protonspring [Mon, 11 Jun 2018 08:17:03 +0000 (10:17 +0200)]
Optimize an expression in endgame.cpp
I believe using foward_file_bb() here is fewer instructions.
a) Fewer instructions and probably more clear (debatable).
b) Possible that a lookup is slower than a few local operations, but the
forward_file_bb table is probably used often enough that it is always
cached.
Passed
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 21004 W: 4263 L: 4141 D: 12600
http://tests.stockfishchess.org/tests/view/
5b1cad830ebc5902ab9c6239
Closes https://github.com/official-stockfish/Stockfish/pull/1644
No functional change.
candirufish [Sun, 10 Jun 2018 08:53:05 +0000 (01:53 -0700)]
Simplify capture pruning margin formula
Using just `PawnValueEg * depth` as Capture Prune Margin. There was a bunch
of patches that passed recently regarding captures, maybe this part of the
master code redundant? The patch was tested as a simplification:
STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 20833 W: 4218 L: 4096 D: 12519
http://tests.stockfishchess.org/tests/view/
5b1cf2100ebc5902ab9c6651
LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 27050 W: 3975 L: 3864 D: 19211
http://tests.stockfishchess.org/tests/view/
5b1cfdc80ebc5902ab9c6776
Closes https://github.com/official-stockfish/Stockfish/pull/1643
Bench:
4980482
Stefan Geschwentner [Mon, 11 Jun 2018 06:39:55 +0000 (08:39 +0200)]
Optimize contempt value (21)
After several tests it seems best to increase contempt from 12 to 21. This does
not regress against contempt=0 and gives a gain of around 7-8 elo against SF 7
in comparison to current default contempt.
STC: Test for non-regression contempt=21 against contempt=0
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 71250 W: 13956 L: 13926 D: 43368
http://tests.stockfishchess.org/tests/view/
5b19a58d0ebc5902ab9c3bfa
STC: Test contempt 21 against SF 7
ELO: 190.06 +-2.8 (95%) LOS: 100.0%
Total: 40000 W: 22608 L: 2676 D: 14716
http://tests.stockfishchess.org/tests/view/
5b19a6520ebc5902ab9c3c0e
STC: Test master against SF 7 for comparison
ELO: 182.95 +-2.7 (95%) LOS: 100.0%
Total: 40000 W: 21905 L: 2595 D: 15500
http://tests.stockfishchess.org/tests/view/
5b16f5bc0ebc59214346d5ca
LTC: Test for non-regression contempt=21 against contempt=0
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 47666 W: 6914 L: 6832 D: 33920
http://tests.stockfishchess.org/tests/view/
5b1a170b0ebc5902ab9c3fde
LTC: Test contempt 21 against SF 7
ELO: 203.92 +-2.6 (95%) LOS: 100.0%
Total: 40000 W: 22447 L: 1340 D: 16213
http://tests.stockfishchess.org/tests/view/
5b1a174b0ebc5902ab9c3fe1
LTC: Test master against SF 7 for comparison
ELO: 196.08 +-2.6 (95%) LOS: 100.0%
Total: 40000 W: 21639 L: 1191 D: 17170
http://tests.stockfishchess.org/tests/view/
5b1a17e40ebc5902ab9c3fe4
Closes https://github.com/official-stockfish/Stockfish/pull/1646
Bench:
4786912
Joost VandeVondele [Mon, 11 Jun 2018 07:46:05 +0000 (09:46 +0200)]
Remove failedLow from the mainThread struct
failedLow is in fact a local variable in Thread::search().
Also clean some spaces and tabs in code.
No functional change.