Stockfish Development Versions are build automatically if there are changes on the master branch in the git repository (https://github.com/official-stockfish/Stockfish). Use it at your own risk.
They are compiled with gcc/mingw 7.3 on Ubuntu 18.04.
2.Jan.2016: BMI build now slightly faster due to profiling.
Read the FAQ or leave a comment.

goto Gull
!! 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: mstembera
Date: Sun Oct 21 08:15:04 2018 +0200
Timestamp: 1540102504

Small simplification in castling rights

There is no need for a special struct with a static member
to generate castling rights.

No 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: ElbertoOne
Date: Sun Oct 14 20:40:57 2018 +0200
Timestamp: 1539542457

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 Elo +1.87
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 Elo +0.91
http://tests.stockfishchess.org/tests/view/5bb34c220ebc592439f6d5dc

Bench: 4274207
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: Sun Oct 14 20:33:52 2018 +0200
Timestamp: 1539542032

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 Elo +0.71
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 Elo +0.58
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 Elo +2.49
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
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: Guenther Demetz
Date: Sun Oct 14 20:19:46 2018 +0200
Timestamp: 1539541186

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 Elo +2.81
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 Elo -0.28
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
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: Sun Oct 14 20:15:16 2018 +0200
Timestamp: 1539540916

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 Elo -0.17
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 Elo +0.01
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
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: Sun Oct 14 20:10:47 2018 +0200
Timestamp: 1539540647

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 Elo +1.77
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 Elo +4.57
http://tests.stockfishchess.org/tests/view/5bb39a190ebc592439f6db8a

unchanged bench: 4312846
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: 31m059
Date: Sun Oct 14 20:02:31 2018 +0200
Timestamp: 1539540151

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 Elo +0.67
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 Elo +1.47
http://tests.stockfishchess.org/tests/view/5bbce35f0ebc592439f77639

Bench: 4312846
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: Eduardo Caceres
Date: Thu Sep 27 21:39:36 2018 +0200
Timestamp: 1538077176

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
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: Thu Sep 27 21:28:38 2018 +0200
Timestamp: 1538076518

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 Elo +6.93
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 Elo +0.18
http://tests.stockfishchess.org/html/live_elo.html?5ba397ee0ebc592cf2767556

unchanged Bench: 4248710
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: protonspring
Date: Thu Sep 27 21:18:18 2018 +0200
Timestamp: 1538075898

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 Elo +0.89
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 Elo +2.19
http://tests.stockfishchess.org/tests/view/5b9c0edf0ebc592cf275f80e

Closes https://github.com/official-stockfish/Stockfish/pull/1769

bench 4059356
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: Rocky640
Date: Thu Sep 27 20:58:40 2018 +0200
Timestamp: 1538074720

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 Elo +3.38

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 Elo +4.11

bench: 4441247
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: Thu Sep 27 20:48:11 2018 +0200
Timestamp: 1538074091

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 Elo +0.09
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 Elo +0.23
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
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: Vizvezdenec
Date: Mon Sep 10 12:22:44 2018 +0200
Timestamp: 1536574964

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 Elo +3.12

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 Elo +2.12

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
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: ElbertoOne
Date: Tue Sep 4 10:43:02 2018 +0200
Timestamp: 1536050582

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 Elo +2.33
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 Elo +2.53
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;
```
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: Stéphane Nicolet
Date: Mon Sep 3 22:11:30 2018 +0200
Timestamp: 1536005490

Update list of authors

And also fix some spaces and formatting oddities in the code.

No 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: Stéphane Nicolet
Date: Sat Sep 1 11:30:38 2018 +0200
Timestamp: 1535794238

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 Elo +1.20
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 Elo +5.10
http://tests.stockfishchess.org/tests/view/5b8a329f0ebc592cf2749615

Closes https://github.com/official-stockfish/Stockfish/pull/1761

Bench: 4609645
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: Rocky640
Date: Sat Sep 1 04:33:17 2018 +0200
Timestamp: 1535769197

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 Elo +2.62
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 Elo +1.92
http://tests.stockfishchess.org/tests/view/5b89a17a0ebc592cf2748b59

Closes https://github.com/official-stockfish/Stockfish/pull/1760

bench: 4693901
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: protonspring
Date: Wed Aug 29 02:49:10 2018 +0200
Timestamp: 1535503750

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 Elo +1.91
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 Elo +0.77
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?
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: MJZ1977
Date: Wed Aug 29 02:28:09 2018 +0200
Timestamp: 1535502489

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 Elo +2.64
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 Elo +3.76
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
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: Steinar H. Gunderson
Date: Wed Aug 29 02:00:20 2018 +0200
Timestamp: 1535500820

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
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: Ondrej Mosnacek
Date: Wed Aug 29 01:24:45 2018 +0200
Timestamp: 1535498685

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.
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: protonspring
Date: Wed Aug 29 01:07:38 2018 +0200
Timestamp: 1535497658

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.
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: Vizvezdenec
Date: Wed Aug 29 00:53:31 2018 +0200
Timestamp: 1535496811

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 Elo +3.39

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 Elo +4.96

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
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: VoyagerOne
Date: Wed Aug 29 00:41:53 2018 +0200
Timestamp: 1535496113

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 Elo +1.32
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 Elo +0.75
http://tests.stockfishchess.org/tests/view/5b7d7f5b0ebc5902bdbb1b85

Bench: 4457440
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: Stefan Geschwentner
Date: Mon Aug 20 21:52:29 2018 +0200
Timestamp: 1534794749

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 Elo +8.50
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 Elo +2.54
http://tests.stockfishchess.org/tests/view/5b7abaa10ebc5902bdbadfa9

Closes https://github.com/official-stockfish/Stockfish/pull/1742

Bench: 4457440

next page >