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.
Read the FAQ or leave a comment.

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: Wed May 30 13:38:11 2018 +0200
Timestamp: 1527680291

Simplify depth reduction in IID.

Use a constant reduction instead of a depth dependent reduction.

passed STC:
http://tests.stockfishchess.org/tests/view/5b06eb600ebc5914abc12ba8
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 58086 W: 11710 L: 11657 D: 34719 Elo +0.32

passed LTC:
http://tests.stockfishchess.org/tests/view/5b07b25e0ebc5914abc12c6d
LLR: 3.09 (-2.94,2.94) [-3.00,1.00]
Total: 110414 W: 16217 L: 16219 D: 77978 Elo -0.01

Bench: 4521056
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: Rodrigo Exterckötter Tjäder
Date: Wed May 30 13:07:18 2018 +0200
Timestamp: 1527678438

Use threads to clear the TT faster.

Stockfish currently takes a while to clear the TT when using larger hash sizes.

On one machine with 128 GB hash it takes about 50 seconds with a single thread,
allowing it to use all allocated cores brought that time down to 4 seconds on
some Linux systems. The patch was further tested on Windows and refined with
NUMA binding of the hash initializing threads (we refer to pull request #1601
for the complete discussion and the speed measurements).

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

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: VoyagerOne
Date: Thu May 24 19:06:24 2018 +0200
Timestamp: 1527181584

LMR Capture Tweak

Increase capture reduction by comparing opponent's stat score

STC: (Yellow)
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 92291 W: 18647 L: 18350 D: 55294 Elo +1.12
http://tests.stockfishchess.org/tests/view/5b04225e0ebc5914abc1291b

LTC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 20176 W: 3061 L: 2868 D: 14247 Elo +3.32
http://tests.stockfishchess.org/tests/view/5b04bb3f0ebc5914abc129a3

How to continue?
• we could try a different value for the capture history threeshold

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

Bench: 5167159
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 May 24 18:46:55 2018 +0200
Timestamp: 1527180415

Simplify BlockedByPawn to one dimension

I was able to get this to pass which reduces BlockedByPawn to one dimension
with NO distance from edge offset.

GOOD) It's more simple and may provide additional clarity for further
simplifications. Facilitates migrating unblocked to one dimension as well.

BAD) If there is indeed a distance component to BlockedStorm (may or may
not be the case), this obfuscates this component into ShelterStrength and
UnblockedStorm. This may be more convoluted. Also, it may be more convenient
to have each of the three arrays (ShelterStrength, BlockedStorm, and UnBlocked)
be the same size.

STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 96173 W: 19326 L: 19343 D: 57504 Elo -0.06
http://tests.stockfishchess.org/tests/view/5b04544d0ebc5914abc12965

LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 49818 W: 7441 L: 7363 D: 35014 Elo +0.54
http://tests.stockfishchess.org/tests/view/5b0487d50ebc5914abc12990

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

Bench: 5133208
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 May 24 18:26:34 2018 +0200
Timestamp: 1527179194

Correctly prevent recursive verification in nmp.

As discussed with @pb00068, the condition to prevent recursive verification
was not completely correct. This patch corrects that condition, and adds an
assert. In the current implementation, recursive verification needs to be
avoided in order not to break the verification of the move closer to the
root (i.e. to not set thisThread->nmp_min_ply to zero prematurely).

This patch is tested as a bug fix, based on and tested against PR #1609 .

passed STC:
http://tests.stockfishchess.org/tests/view/5b050f170ebc5914abc129c5
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 7875 W: 1669 L: 1523 D: 4683 Elo +6.44

passed LTC:
http://tests.stockfishchess.org/tests/view/5b0513970ebc5914abc129cd
LLR: 3.00 (-2.94,2.94) [-3.00,1.00]
Total: 24048 W: 3525 L: 3407 D: 17116 Elo +1.70

Bench changes at high depth.

Closes https://github.com/official-stockfish/Stockfish/pull/1610
and https://github.com/official-stockfish/Stockfish/pull/1609

Bench: 4484288
Windows x64 for Haswell CPUs
Windows x64 for modern computers
Windows x64
Windows 32
Linux x64 for Haswell CPUs
Linux x64 for modern computers
Linux x64
Author: Joost VandeVondele
Date: Tue May 22 22:43:17 2018 +0200
Timestamp: 1527021797

Simplify color usage in search.

define Color us and use this instead of pos.side_to_move() and nmp_odd. The latter allows to clarify the nmp verification criterion.

Tested for no regression:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 76713 W: 15303 L: 15284 D: 46126 Elo +0.09
http://tests.stockfishchess.org/tests/view/5b046a0d0ebc5914abc12971

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: VoyagerOne
Date: Tue May 22 07:23:04 2018 +0200
Timestamp: 1526966584

Simply reset StatScore to zero at beta cutoff

STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 43154 W: 8706 L: 8625 D: 25823 Elo +0.65
http://tests.stockfishchess.org/tests/view/5b01a7660ebc5914abc1271d

LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 48155 W: 7036 L: 6955 D: 34164 Elo +0.58
http://tests.stockfishchess.org/tests/view/5b01b2e50ebc5914abc1272c

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

Bench: 4484288
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: Mon May 21 09:51:05 2018 +0200
Timestamp: 1526889065

Simplify shelter: always do strength and danger

This check of pawns before subtracting danger can be removed.

STC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 21174 W: 4361 L: 4239 D: 12574 Elo +2.00
http://tests.stockfishchess.org/tests/view/5b00b9f90ebc5914abc12680

LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 56980 W: 8377 L: 8309 D: 40294 Elo +0.41
http://tests.stockfishchess.org/tests/view/5b00ca750ebc5914abc12683

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

Bench: 4746692
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 May 21 09:37:44 2018 +0200
Timestamp: 1526888264

Simplifying away the progressKey

Simplifying away all the progressKey stuff gives exactly the same bench,
without any speed impact. Tested for speed against master with two benches
at depth 22 ran in parallel:

**testedpatch**
Total time (ms) : 92350
Nodes searched : 178962949
Nodes/second : 1937877

**master**
Total time (ms) : 92358
Nodes searched : 178962949
Nodes/second : 1937709

We also tested the patch at STC for no-regression with [-3, 1] bounds:

LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 57299 W: 11529 L: 11474 D: 34296 Elo +0.33
http://tests.stockfishchess.org/tests/view/5b015a1c0ebc5914abc126e5

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

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: mstembera
Date: Wed May 16 23:40:23 2018 +0200
Timestamp: 1526506823

Fix MSVC errors in tbprobe.cpp

Default template parameters values and recursive functions do not play well
together. Fix for below errors that showed up after updating to latest MSVC.

````
tbprobe.cpp(1156): error C2672:
'search': no matching overloaded function found

tbprobe.cpp(1198): error C2783:
'Tablebases::WDLScore `anonymous-namespace'::search(Position &,Tablebases::ProbeState *)':
could not deduce template argument for 'CheckZeroingMoves'

````

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

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: Tom Truscott
Date: Wed May 16 22:51:43 2018 +0200
Timestamp: 1526503903

Use cycle detection to bound search value

A position which has a move which draws by repetition, or which could have
been reached from an earlier position in the game tree, is considered to be
at least a draw for the side to move.

Cycle detection algorithm by Marcel van Kervink:

https://marcelk.net/2013-04-06/paper/upcoming-rep-v2.pdf

----------------------------

How does the algorithm work in practice? The algorithm is an efficient
method to detect if the side to move has a drawing move, without doing any
move generation, thus possibly giving a cheap cutoffThe most interesting
conditions are both on line 1195:

```
if ( originalKey == (progressKey ^ stp->key)
|| progressKey == Zobrist::side)
```

This uses the position keys as a sort-of Bloom filter, to avoid the expensive
checks which follow. For "upcoming repetition" consider the opening Nf3 Nf6 Ng1.
The XOR of this position's key with the starting position gives their difference,
which can be used to look up black's repeating move (Ng8). But that look-up is
expensive, so line 1195 checks that the white pieces are on their original squares.

This is the subtlest part of the algorithm, but the basic idea in the above game
is there are 4 positions (starting position and the one after each move). An XOR
of the first pair (startpos and after Nf3) gives a key matching Nf3. An XOR of
the second pair (after Nf6 and after Ng1) gives a key matching the move Ng1. But
since the difference in each pair is the location of the white knight those keys
are "identical" (not quite because while there are 4 keys the the side to move
changed 3 times, so the keys differ by Zobrist::side). The loop containing line
1195 does this pair-wise XOR-ing.

Continuing the example, after line 1195 determines that the white pieces are
back where they started we still need to make sure the changes in the black
pieces represents a legal move. This is done by looking up the "moveKey" to
see if it corresponds to possible move, and that there are no pieces blocking
its way. There is the additional complication that, to match the behavior of
is_draw(), if the repetition is not inside the search tree then there must be
an additional repetition in the game history. Since a position can have more
than one upcoming repetition a simple count does not suffice. So there is a
search loop ending on line 1215.

On the other hand, the "no-progress' is the same thing but offset by 1 ply.
I like the concept but think it currently has minimal or negative benefit,
and I'd be happy to remove it if that would get the patch accepted. This
will not, however, save many lines of code.

-----------------------------

STC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 36430 W: 7446 L: 7150 D: 21834 Elo +2.82
http://tests.stockfishchess.org/tests/view/5afc123f0ebc591fdf408dfc

LTC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 12998 W: 2045 L: 1876 D: 9077 Elo +4.52
http://tests.stockfishchess.org/tests/view/5afc2c630ebc591fdf408e0c

How could we continue after the patch:

• The code in search() that checks for cycles has numerous possible variants.
Perhaps the check need could be done in qsearch() too.

• The biggest improvement would be to get "no progress" to be of actual benefit,
and it would be helpful understand why it (probably) isn't. Perhaps there is an
interaction with the transposition table or the (fantastically complex) tree
search. Perhaps this would be hard to fix, but there may be a simple oversight.

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

Bench: 4550412
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: Mon May 14 06:52:48 2018 +0200
Timestamp: 1526273568

Update search.cpp

At PvNodes allow bonus for prior counter move that caused a fail low
for depth 1 and 2. Note : I did a speculative LTC on yellow STC patch
since history stats tend to be highly TC sensitive

STC (Yellow):
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 64295 W: 13042 L: 12873 D: 38380 Elo +0.91
http://tests.stockfishchess.org/tests/view/5af507c80ebc5968e6524153

LTC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 22407 W: 3413 L: 3211 D: 15783 Elo +3.13
http://tests.stockfishchess.org/tests/view/5af85dd40ebc591fdf408b87

Also use local variable excludedMove in NMP (marotear)

Bench: 5294316
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: Sun May 13 07:20:39 2018 +0200
Timestamp: 1526188839

Tweak kingAttackersCount and KingAttackWeights

Use the whole kingRing for pawn attackers instead of only the squares directly
around the king. This tends to give quite a lot more kingAttackersCount, so to
compensate and to avoid raising the king danger too fast we lower the values
in the KingAttackWeights array a little bit.

STC:
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 51892 W: 10723 L: 10369 D: 30800 Elo +2.37
http://tests.stockfishchess.org/tests/view/5af6d4dd0ebc5968e652428e

LTC:
LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 24536 W: 3737 L: 3515 D: 17284 Elo +3.14
http://tests.stockfishchess.org/tests/view/5af709890ebc5968e65242ac

Credits to user @xoroshiro for the idea of using the kingRing for pawn attackers.

How to continue? It seems that the KingAttackWeights[] array stores values
which are quite Elo-sensitive, yet they have not been tuned with SPSA recently.
There might be easy Elo points to get there.

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

Bench: 5282815
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: Thu May 10 23:36:16 2018 +0200
Timestamp: 1525988176

Include all blockers in king danger

Simplification: in king danger, include all blockers and not only pinned
pieces, since blockers enemy pieces can result in discovered checks which
are also bad.

STC http://tests.stockfishchess.org/tests/view/5af35f9f0ebc5968e6523fe9
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 145781 W: 29368 L: 29478 D: 86935 Elo -0.26

LTC http://tests.stockfishchess.org/tests/view/5af3cb430ebc5968e652401f
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 76398 W: 11272 L: 11232 D: 53894 Elo +0.18

I also incorrectly scheduled STC with [0,5] which it failed.
http://tests.stockfishchess.org/tests/view/5af283c00ebc5968e6523f33
LLR: -2.94 (-2.94,2.94) [0.00,5.00]
Total: 12338 W: 2451 L: 2522 D: 7365 Elo -2.00

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

bench: 4698290

----------------------------------------

Thanks to @vondele and @Rocky640 for a cleaner version of the patch,
and the following comments!

> Most of the pinned, (or for this pull request, blocking) squares were
> already computed in the unsafeChecks, the only missing squares being:
>
> a) squares attacked by a Queen which are occupied by friendly piece
> or "unsafe". Note that adding such squares never passed SPRT[0,5].
>
> b) squares not in mobilityArea[Us].
>
> There is a strong relationship between the blockers and the unsafeChecks,
> but the bitboard unsafeChecks is still useful when the checker is not
> aligned with the king, and the checking square is occupied by friendly
> piece or is "unsafe". This is always the case for the Knight.
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 May 10 15:46:32 2018 +0200
Timestamp: 1525959992

Consolidate pawn storm types

Simplification: the Unopposed and Unblocked pawn storm types are mathematically
similar enough to combine with no Elo loss. This reduces the pawn storm types
to BlockedByPawn and UnBlocked.

STC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 116869 W: 23549 L: 23605 D: 69715 Elo -0.17
http://tests.stockfishchess.org/tests/view/5af2def90ebc5968e6523f82

LTC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 39912 W: 6090 L: 5998 D: 27824 Elo +0.80
http://tests.stockfishchess.org/tests/view/5af3b2e20ebc5968e6524013

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

Bench: 5244314
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: Thu May 10 12:28:18 2018 +0200
Timestamp: 1525948098

Tune null move pruning

Use a lower stat score threshold of 22500.

Failed yellow at STC after many games (~0.92 Elo):
LLR: -2.96 (-2.94,2.94) [0.00,4.00]
Total: 73978 W: 14947 L: 14834 D: 44197 Elo +0.53
http://tests.stockfishchess.org/tests/view/5af2deec0ebc5968e6523f80

But scales good and passed LTC:
LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 23147 W: 3453 L: 3237 D: 16457 Elo +3.24
http://tests.stockfishchess.org/tests/view/5af3cf820ebc5968e6524022

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

Bench: 4777674
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: candirufish
Date: Wed May 9 09:22:11 2018 +0200
Timestamp: 1525850531

Tuned some pawns and evaluation constants

Tuned values in pawns.cpp and evaluate.cpp after a SPSA session:
419k games 60sec 600nodetime. We have adjusted the PassedRank[]
output of the SPSA session to keep increasing values with rank,
and PassedFile[] output to keep the West <–> East symmetry of
the evaluation.

STC:
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 58948 W: 12431 L: 12046 D: 34471 Elo +2.27
http://tests.stockfishchess.org/tests/view/5af2302f0ebc5968e6523f0a

LTC:
LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 22211 W: 3468 L: 3251 D: 15492 Elo +3.39
http://tests.stockfishchess.org/tests/view/5af264c80ebc5968e6523f1a

See https://github.com/official-stockfish/Stockfish/pull/1587
and https://github.com/official-stockfish/Stockfish/pull/1590

bench: 4437531
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: Wed May 9 01:42:34 2018 +0200
Timestamp: 1525822954

Remove goto, limit skipping to NMP

This patch simplifies the control flow in search(), removing an if
and a goto. A side effect of the patch is that Stockfish is now a
little bit more selective at low depths, because we allow razoring,
futility pruning and probcut pruning after a null move.

passed STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 32035 W: 6523 L: 6422 D: 19090 Elo +1.10
http://tests.stockfishchess.org/tests/view/5af142ca0ebc597fb3d39bb6

passed LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 41431 W: 6187 L: 6097 D: 29147 Elo +0.75
http://tests.stockfishchess.org/tests/view/5af148770ebc597fb3d39bc1

Ideas for further work:

• Use the nodes credit opened by the patch (the increased selectivity)
to try somewhat higher razoring, futility or probcut margins at [0..4].

Bench: 4855031
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: Tue May 8 23:31:55 2018 +0200
Timestamp: 1525815115

Tweak null move pruning conditions

Allow null move pruning only if last stat score < 30000.

Passed STC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 12653 W: 2641 L: 2454 D: 7558 Elo +5.14
http://tests.stockfishchess.org/tests/view/5af1d8830ebc5968e6523edb

Passed LTC:
LLR: 2.97 (-2.94,2.94) [0.00,5.00]
Total: 19782 W: 3072 L: 2878 D: 13832 Elo +3.41
http://tests.stockfishchess.org/tests/view/5af1ee8c0ebc5968e6523ee4

Ideas for further work:

• Tune the stat score threshold.
• Try depth based stat score threshold.
• Try stat score condition for other prunings.

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

Bench: 5088156
Windows x64 for Haswell CPUs
Windows x64 for modern computers
Windows x64
Windows 32
Linux x64 for Haswell CPUs
Linux x64 for modern computers
Linux x64
Author: Alain SAVARD
Date: Tue May 8 11:14:43 2018 +0200
Timestamp: 1525770883

Drop the lever condition for backwards

We can view the patch version as adding some "undermining bonus" for
level pawns, when the defending side can not easily avoid the exchange
by advancing her pawn.

• Case 1) White b2,c3, Black a3,b3:
Black is breaking through, b2 deserves a penalty

• Case 2) White b2,c3, Black a3,c4:
if b2xa3 then White ends up with a weak pawn on a3
and probably a weak pawn on c3 too.

In either case, White can still not safely play b2-b3 and make a
phalanx with c3, which is the essence of a backward pawn definition.

Passed STC in SPRT[0, 4]:
LLR: -2.96 (-2.94,2.94) [0.00,4.00]
Total: 131169 W: 26523 L: 26199 D: 78447 Elo +0.86
http://tests.stockfishchess.org/tests/view/5aefa4d50ebc5902a409a151
ELO 1.19 [-0.38,2.88] (95%)

Passed LTC in SPRT[-3, 1]:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 24824 W: 3732 L: 3617 D: 17475 Elo +1.61
http://tests.stockfishchess.org/tests/view/5af04d3f0ebc5902a88b2e55
ELO 1.27 [-1.21,3.70] (95%)

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

How to continue from there?

There were some promising tests a couple of months ago about adding
a lever condition for king danger in evaluate.cpp, maybe it would
be time to re-try this after all the recent changes in pawns.cpp

Bench: 4773882
Windows x64 for Haswell CPUs
Windows x64 for modern computers
Windows x64
Windows 32
Linux x64 for Haswell CPUs
Linux x64 for modern computers
Linux x64
Author: Joost VandeVondele
Date: Tue May 8 10:43:56 2018 +0200
Timestamp: 1525769036

Remove skipEarlyPruning argument to search()

Remove nine boolean arguments and the corresponding skipEarlyPruning variable.
Instead, skip early pruning only when there is an excluded move, and try null
move pruning only if the previous move was not itself a null move.

passed STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 33623 W: 6853 L: 6755 D: 20015 Elo +1.01
http://tests.stockfishchess.org/tests/view/5aef462a0ebc5902a409a10e

passed LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 39474 W: 5882 L: 5789 D: 27803 Elo +0.82
http://tests.stockfishchess.org/tests/view/5aefd4b80ebc5902a409a164

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

Bench: 4953556
Windows x64 for Haswell CPUs
Windows x64 for modern computers
Windows x64
Windows 32
Linux x64 for Haswell CPUs
Linux x64 for modern computers
Linux x64
Author: Joost VandeVondele
Date: Tue May 8 10:32:23 2018 +0200
Timestamp: 1525768343

Improve signature script

Catch case of missing bench, indicative of a crash or assert.

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: Sun May 6 09:44:14 2018 +0200
Timestamp: 1525592654

Simplify the backward pawns code

The two lines of code in the patch seem to be just as good as master.

1. We now only look at the current square to see if it is currently backward,
whereas master looks there AND further ahead in the current file (master would
declare a pawn "backward" even though it could still safely advance a little).
This simplification allows us to avoid the use of the difficult logic with
`backmost_sq(Us, neighbours | stoppers)`.

2. The condition `relative_rank(Us,s) < RANK_5` is simplified away.

Passed STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 68132 W: 14025 L: 13992 D: 40115 Elo +0.17
http://tests.stockfishchess.org/tests/view/5aedc97a0ebc5902a4099fd6

Passed LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 23789 W: 3643 L: 3527 D: 16619 Elo +1.69
http://tests.stockfishchess.org/tests/view/5aee4f970ebc5902a409a03a

Ideas for further work:

• The new code flags some pawns on the 5th rank as backward, which was not the
case in the old master. So maybe we should test a version with that included?

• Further tweaks of the backward condition with [0..5] bounds?

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

Bench: 5122789
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: Thu May 3 22:00:07 2018 +0200
Timestamp: 1525377607

Tweak the connected[] array value for pawns on rank 5

A recent tuning session by Jerry Donald Watson suggested that the
value for the pawns on the fifth rank in the connected[] array were
a little bit too high in master. We lower here this value from 75 to 65.

STC:
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 27399 W: 5646 L: 5384 D: 16369 Elo +3.32
http://tests.stockfishchess.org/tests/view/5aea17c50ebc5902a1bed396

LTC:
LLR: 3.66 (-2.94,2.94) [0.00,4.00]
Total: 95590 W: 14529 L: 14062 D: 66999 Elo +1.70
http://tests.stockfishchess.org/tests/view/5aea34a40ebc5902a104ebe5

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

Bench: 5186783
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: Wed May 2 13:38:00 2018 +0200
Timestamp: 1525261080

Correct a bug introduced by Stéphane in the previous patch.

When we are using the "Bitboard + Square" overloaded operators,
the compiler uses the interpediate SquareBB[s] to transform the
square into a Bitboard, and then calculate the result.

For instance, the following code:

```
b = pos.pieces(Us, PAWN) & s
```

generates in fact the code:

```
b = pos.pieces(Us, PAWN) & SquareBB[s]`
```

The bug introduced by Stéphane in the previous patch was the
use of `b = pos.pieces(Us, PAWN) & (s + Up)` which can result
in out-of-bounds errors for the SquareBB[] array if s in the
last rank of the board.

We coorect the bug, and also add some asserts in bitboard.h to
make the code more robust for this particular bug in the future.

Bug report by Joost VandeVondele. Thanks!

Bench: 5512000

< prev page next page >