3 years agoUse per-thread dynamic contempt
Ondrej Mosnáček [Fri, 30 Mar 2018 08:47:05 +0000 (10:47 +0200)]
Use per-thread dynamic contempt

We now use per-thread dynamic contempt. This patch has the following

 * for Threads=1: **non-functional**
 * for Threads>1:
   * with MultiPV=1: **no regression, little to no ELO gain**
   * with MultiPV>1: **clear improvement over master**

First, I tried testing at standard MultiPV=1 play with [0,5] bounds.
This yielded 2 yellow and 1 red test:

5+0.05, Threads=5:
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 82689 W: 16439 L: 16190 D: 50060

5+0.05, Threads=8:
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 27164 W: 4974 L: 4983 D: 17207

5+0.5, Threads=16:
LLR: -2.97 (-2.94,2.94) [0.00,5.00]
Total: 41396 W: 7127 L: 7082 D: 27187

Then, I tested with Skill Level=17 (implicitly MutliPV=4), showing
a clear improvement:

5+0.05, Threads=5:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 3498 W: 1316 L: 1135 D: 1047

Next, I tested the patch with MultiPV=1 again, this time checking for
non-regression ([-3, 1]):

5+0.5, Threads=5:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 65575 W: 12786 L: 12745 D: 40044

Finally, I ran some tests with fixed number of games, checking if
reverting dynamic contempt gains more elo with Skill Level=17 (i.e.
MultiPV) than applying the "prevScore" fix and this patch. These tests
showed, that this patch gains 15 ELO when playing with Skill Level=17:

5+0.05, Threads=3, "revert dynamic contempt" vs. "WITHOUT this patch":
ELO: -11.43 +-4.1 (95%) LOS: 0.0%
Total: 20000 W: 7085 L: 7743 D: 5172

5+0.05, Threads=3, "revert dynamic contempt" vs. "WITH this patch":
ELO: -26.42 +-4.1 (95%) LOS: 0.0%
Total: 20000 W: 6661 L: 8179 D: 5160


**Why should this be commited?**
I believe that the gain for multi-thread MultiPV search is a sufficient
justification for this otherwise neutral change. I also believe this
implementation of dynamic contempt is more logical, although this may
be just my opinion.

**Why is per-thread contempt better at MultiPV?**
A likely explanation for the gain in MultiPV mode is that during
search each thread independently switches between rootMoves and via
the shared contempt score skews each other's evaluation.

**Why were the tests done with Skill Level=17?**
This was originally suggested by @Hanamuke and the idea is that with
Skill Level Stockfish sometimes plays also moves it thinks are slightly
sub-optimal and thus the quality of all moves offered by the MultiPV
search is checked by the test.

**Why are the ELO differences so huge?**
This is most likely because of the nature of Skill Level mode --
since it slower and weaker than normal mode, bugs in evaluation have
much greater effect.



No functional change -- in single thread mode.

3 years agoIntegrate syzygy in automated testing (v2).
Joost VandeVondele [Fri, 30 Mar 2018 08:21:59 +0000 (10:21 +0200)]
Integrate syzygy in automated testing (v2).

Extends valgrind/sanitizer testing to cover syzygy code.

The script downloads 4 man syzygy as needed. The time needed for the
additional testing is small (in fact hard to see a difference compared
to the large fluctuations in testing time in travis).

Possible follow-ups:

 * include more TB sensitive positions in bench.
 * include the test script of recent commit "Refactor tbprobe.cpp".
 * verify unchanged bench with TB (with a long run).
 * make the TB part of the continuation integration tests optional.


No functional change.

3 years agoChange reduction/improving interaction
Jerry Donald Watson [Tue, 27 Mar 2018 22:31:31 +0000 (00:31 +0200)]
Change reduction/improving interaction

Adjust criterion for applying extra reduction if not improving.
We now add an extra ply of reduction if r > 1.0, instead of the
previous condition Reductions[NonPV][imp][d][mc] >= 2.

Why does this work? Previously, reductions when not improving had
a discontinuity as the depth and/or move count increases due to the
Reductions[NonPV][imp][d][mc] >= 2 condition. Hence, values of r
such that 0.5 < r < 1.5 would be mapped to a reduction of 1, while
1.5 < r < 2.5 would be mapped to a reduction of 3. This patch allows
values of r satisfying 1.0 < r < 1.5 to be mapped to a reduction of 2,
making the reduction formula more continuous.

LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 35908 W: 7382 L: 7087 D: 21439

LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 23087 W: 3584 L: 3378 D: 16125

Ideas for future work:
- We could look at retuning the LMR formula.
- We could look at adjusting the reductions in PV nodes if not improving.

Bench: 5326261

3 years agoTweak queen values for midgame and endgame
Stéphane Nicolet [Tue, 27 Mar 2018 15:51:11 +0000 (17:51 +0200)]
Tweak queen values for midgame and endgame

Queen midgame value: -1%
Queen endgame value: +1%

This patch failed STC, but was exceptionally tested at LTC,
where it passed two independant SPRT tests with bounds [0..4]:

LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 20651 W: 3191 L: 2980 D: 14480

LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 89111 W: 13647 L: 13233 D: 62231

for the discussion of this patch.

How to continue from there?
• there is probably some more Elo gains to get from the tuning
of the queen value.

Bench: 5460229

3 years agoSimplification: remove pawn shelter/storm masks
protonspring [Tue, 27 Mar 2018 15:29:56 +0000 (17:29 +0200)]
Simplification: remove pawn shelter/storm masks

Encode the pawn shelter/storm masks into the danger score

This highly specialized rule directly contradicts the VERY high
danger score for blocked pawns. Reducing the danger score for
blocked pawns and removing this rule is apparently an effective

LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 36597 W: 7522 L: 7429 D: 21646

LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 100690 W: 15373 L: 15372 D: 69945


Bench: 5980822

3 years agoFix dynamic contempt for MultiPV
Ondrej Mosnáček [Wed, 14 Mar 2018 15:47:45 +0000 (16:47 +0100)]
Fix dynamic contempt for MultiPV

Use rootMoves[PVIdx].previousScore instead of bestValue for
dynamic contempt. This is equivalent for MultiPV=1 (bench remained the
same, even for higher depths), but more correct for MultiPV.

STC (MultiPV=3):
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 2657 W: 1079 L: 898 D: 680

LTC (MultiPV=3):
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 2390 W: 874 L: 706 D: 810

VLTC 240+2.4 (MultiPV=3):
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 2399 W: 861 L: 694 D: 844

LTC (MultiPV=4, Skill Level=17):
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 747 W: 333 L: 175 D: 239

Note: although the ELO differences seem huge, they are inflated by the
nature of Skill Level / MultiPV search, so I don't think they can be
reasonably compared with classic ELO strength.

See for some
verifications searches with MultiPV = 10 at depths 12 and 24 from the
starting position and the position after 1.e4, comparing the outputs
of the full PV by the old master and by this patch.

No functional change for MultiPV=1

3 years agoRefactor tbprobe.cpp
Ondrej Mosnáček [Sat, 10 Mar 2018 13:37:42 +0000 (14:37 +0100)]
Refactor tbprobe.cpp

This involves:
 * replacing the union hacks with simply reusing the EntryPiece arrays
   for the no-pawns case
 * merging the PairsData structure with the EntryPiece/-Pawn structs
   (with credit to Marco: @mcostalba)
 * simplifying some HashTable functions
 * thanks to previous changes, removing the ugly memsets
 * simplifying the template logic for WDL/DTZ distinction
   (now we distinguish based on an enum type, not the entry classes)
 * removing the unneeded Atomic wrapper


For reference, here is a manual way to check that patches concerning
table bases code are non-functional changes:

0) Download the Syzygy table bases (up to 6 men).
1) Make sure you have branches master and the pull request pointing to
   the right commits.
2) Download the bench calculation scripts from the following URL:

   and copy into src inside your Stockfish repo.
3) Make the scripts executable (chmod +x *.sh).
4) Run the following command to use TBs located at <path>:

       export SYZYGY_PATH='<path>'

5) After that, run this (it will take a long time, this is a deep bench):

       BENCH_ARGS='128 1 22' ./ master tbprobe_cleanup 2>/dev/null`

==> You should see two equal numbers printed.
    (Of course, now we have to trust that the script itself is correct :)



No functional change.

3 years agoFix indentation in movepicker.cpp
Marco Costalba [Tue, 27 Mar 2018 14:44:47 +0000 (16:44 +0200)]
Fix indentation in movepicker.cpp

Fix indentation in movepicker.cpp and evaluate.cpp. Also move
the PickType enum out of global space.

No functional change

3 years agoSwitch time management to 64 bits
Stéphane Nicolet [Tue, 27 Mar 2018 14:22:53 +0000 (16:22 +0200)]
Switch time management to 64 bits

This is a patch to fix issue #1498, switching the time management variables
to 64 bits to avoid overflow of time variables after 25 days.

There was a bug in Stockfish 9 causing the output to be wrong after
2^31 milliseconds search. Here is a long run from the starting position:

info depth 64 seldepth 87 multipv 1 score cp 23 nodes 13928920239402
nps 0 tbhits 0 time -504995523 pv g1f3 d7d5 d2d4 g8f6 c2c4 d5c4 e2e3 e7e6 f1c4
c7c5 e1g1 b8c6 d4c5 d8d1 f1d1 f8c5 c4e2 e8g8 a2a3 c5e7 b2b4 f8d8 b1d2 b7b6 c1b2
c8b7 a1c1 a8c8 c1c2 c6e5 d1c1 c8c2 c1c2 e5f3 d2f3 a7a5 b4b5 e7c5 f3d4 d8c8 d4b3
c5d6 c2c8 b7c8 b3d2 c8b7 d2c4 d6c5 e2f3 b7d5 f3d5 e6d5 c4e5 a5a4 e5d3 f6e4 d3c5
e4c5 b2d4 c5e4 d4b6 e4d6 g2g4 d6b5 b6c5 b5c7 g1g2 c7e6 c5d6 g7g6

We check at compile time that the TimePoint type is exactly 64 bits long for
the compiler (TimePoint is our alias in Stockfish for std::chrono::milliseconds
-- it is a signed integer type of at least 45 bits according to the C++ standard,
but will most probably be implemented as a 64 bits signed integer on modern
compilers), and we use this TimePoint type consistently across the code.

Bug report by user "fischerandom" on the TCEC chat (thanks), and the
patch includes code and suggestions by user "WOnder93" and Ronald de Man.

Fixes issue:
Closes pull request:

No functional change.

3 years agoMake kingRing always 8 squares
Jerry Donald Watson [Mon, 26 Mar 2018 07:26:50 +0000 (09:26 +0200)]
Make kingRing always 8 squares

Make kingRing always eight squares, extending the bitboard to the
F file if the king is on the H file, and to the C file if the king
is on the A file. This may deal with cases where Stockfish (like
many other engines) would shift the king around on the back rank
like g1h1, not because there is some imminent threat, but because
it makes king safety look a little better just because the king ring
had a smaller area.

LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 34000 W: 7167 L: 6877 D: 19956

LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 22574 W: 3576 L: 3370 D: 15628

How to continue from there?

This patch probably makes it easier to tune the king safety evaluation,
because the new regularity of the king ring size will make the king
safety function more continuous.


Bench: 5934103

3 years agoIID margin reduced to 128
Chess13234 [Fri, 23 Mar 2018 18:39:07 +0000 (20:39 +0200)]
IID margin reduced to 128

Change the internal iterative deepening margin from +256 to +128.

Passed STC:
LLR: 3.26 (-2.94,2.94) [0.00,5.00]
Total: 22006 W: 4646 L: 4400 D: 12960

Passed LTC:
LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 46665 W: 7187 L: 6898 D: 32580

Possible work in this area after this change:

• Reduce even more the margin?
• Try to do IID for smaller depths too?

Bench: 5851102

3 years agoJoin refutation stages in the movepicker
Joost VandeVondele [Wed, 21 Mar 2018 00:48:31 +0000 (01:48 +0100)]
Join refutation stages in the movepicker

Unifies a bit further the three refuation stages in the MovePicker
class. Also treat the skipping of TT move now always via select_move(),
as discussed in pull request #1454.

Passed STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 16608 W: 3461 L: 3331 D: 9816


No functional change.

3 years agoFix a few minor code style inconsistencies
DU-jdto [Wed, 21 Mar 2018 00:26:12 +0000 (01:26 +0100)]
Fix a few minor code style inconsistencies

No functional change.

3 years agoJoin common code in the stages of next_move()
Joost VandeVondele [Sun, 18 Mar 2018 23:56:19 +0000 (00:56 +0100)]
Join common code in the stages of next_move()

Rewrite the MovePicker class using lambda expressions for move filtering.
Includes code style changes by @mcostalba.

Verified for speed, passed STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 43191 W: 9391 L: 9312 D: 24488

This rewrite of MovePicker.cpp seems to trigger less random crashes on Ryzen
machines than the version in previous master (reported by Bojun Guo).


No functional change.

3 years agoSimplify razoring logic
Joost VandeVondele [Sun, 18 Mar 2018 23:16:23 +0000 (00:16 +0100)]
Simplify razoring logic

passed STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 36574 W: 7523 L: 7430 D: 21621

No functional change.

3 years agoMark all compile-time constants as constexpr.
Ronald de Man [Sun, 18 Mar 2018 22:38:58 +0000 (23:38 +0100)]
Mark all compile-time constants as constexpr.

To more clearly distinguish them from "const" local variables, this patch
defines compile-time local constants as constexpr. This is consistent with
the definition of PvNode as constexpr in search() and qsearch(). It also
makes the code more robust, since the compiler will now check that those
constants are indeed compile-time constants.

We can go even one step further and define all the evaluation and search
compile-time constants as constexpr.

In generate_castling() I replaced "K" with "step", since K was incorrectly
capitalised (in the Chess960 case).

In timeman.cpp I had to make the non-local constants MaxRatio and StealRatio
constepxr, since otherwise gcc would complain when calculating TMaxRatio and
TStealRatio. (Strangely, I did not have to make Is64Bit constexpr even though
it is used in ucioption.cpp in the calculation of constexpr MaxHashMB.)

I have renamed PieceCount to pieceCount in material.h, since the values of
the array are not compile-time constants.

Some compile-time constants in tbprobe.cpp were overlooked. Sides and MaxFile
are not compile-time constants, so were renamed to sides and maxFile.

Non-functional change.

3 years agoFix an MSVC 2017 error and warnings.
mstembera [Fri, 16 Mar 2018 04:34:38 +0000 (21:34 -0700)]
Fix an MSVC 2017 error and warnings.

Improved version by @mcostalba.

No functional change.

3 years agoRenaming some variables in code
Stéphane Nicolet [Thu, 15 Mar 2018 09:44:26 +0000 (10:44 +0100)]
Renaming some variables in code

Implements renaming suggestions by Marco Costalba, Günther Demetz,
Gontran Lemaire, Ronald de Man, Stéphane Nicolet, Alain Savard,
Joost VandeVondele, Jerry Donald Watson, Mike Whiteley, xoto10,
and I hope that I haven't forgotten anybody.

Perpetual renaming thread for suggestions:

No functional change.

3 years agoMake using quiescence search implicit
Joost VandeVondele [Thu, 15 Mar 2018 08:21:34 +0000 (09:21 +0100)]
Make using quiescence search implicit

If search depth is less than ONE_PLY call qsearch(), no need to check the
depth condition at various call sites of search().

Passed STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 14568 W: 3011 L: 2877 D: 8680

Also helps gcc to find some optimizations (smaller binary, some speedup).
Thanks to Aram and Stefan for identifying an oversight in an early version.


No functional change.

3 years agoCheck the clock every 1024 nodes
Stéphane Nicolet [Wed, 14 Mar 2018 20:35:57 +0000 (21:35 +0100)]
Check the clock every 1024 nodes

This patch checks the clock every 1024, instead of 4096 in current master.

This is a step towards a solution to alleviate the problem reported by
Gian-Carlo Pascutto in pull request #1471, about a situation where SF
would sometimes lose on time in endgames at time control 1min+1sec when
using Syzygy EGTB on a spinning drive.

We made four tests called "Estimate the Elo cost of calling now() every
N nodes", with N in {256,1024} and time control in {STC,LTC}. Each test
was 40000 games with auto-purge off, against master branch.

Here is a summary of the results (speed-up and Elo gain against master):

|   Time   |       N=256       |      N=1024      |
| Speed-up |    0.1% slower    |   0.2% faster    |
|   STC    |  -0.33 +-2.2 Elo  |  1.33 +-2.2 Elo  |
|   LTC    |   1.08 +-2.3 Elo  |  2.34 +-2.2 Elo  |

Based on these results, we tested N=1024 as a non-regression against
master at LTC:

LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 80746 W: 12430 L: 12399 D: 55917


No functional change.

3 years agoUse intrinsics only for LSB/MSB
lucasart [Sun, 11 Mar 2018 22:56:14 +0000 (06:56 +0800)]
Use intrinsics only for LSB/MSB

The NO_BSF does not cover any real life use-case today. The only compilers that
can compile SF today, with the current Makefile and no source code changes, are
either GCC compatible (define __GNUC__) or MSVC compatible (define _MSC_VER). So
they all support LSB/MSB intrinsics.

This patch simplifies away the software fall-backs of LSB/MSB that were still
in Stockfish code, but unused in any of the officially supported compilers.

Note the (legacy) MSVC/WIN32 case, where we use a 32-bit BSF/BSR solution, as
64-bit intrinsics aren't available there.

Discussed in:

No functional change.

3 years agoSimplify condition for ProbCut move count pruning
Jerry Donald Watson [Tue, 13 Mar 2018 09:15:42 +0000 (09:15 +0000)]
Simplify condition for ProbCut move count pruning

We retire depth-dependence in ProbCut move count pruning,
the move count limit condition is now : "probCutCount < 3"

LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 33895 W: 6995 L: 6897 D: 20003

LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 28959 W: 4441 L: 4333 D: 20185

Ideas for future work:

• Is a flat move count limit in ProbCut ideal? Depth dependence, or
  dependence on some other variable, could possibly be reintroduced.

• The move count limit 3 is untuned and a better value may exist.


Bench: 5741807

3 years agoTweak probcut margin with 'improving' flag
Jerry Donald Watson [Tue, 13 Mar 2018 22:19:36 +0000 (23:19 +0100)]
Tweak probcut margin with 'improving' flag

Adjust ProbCut rBeta by whether the score is improving, and also
set improving to false when in check. More precisely, this patch
has two parts:

1) the increased beta threshold for ProbCut is now adjusted based
   on whether the score is improving
2) when in check, improving is always set to false.

Co-authored by Joost VandeVondele (@vondele) and Bill Henry (@VoyagerOne).

LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 13480 W: 2840 L: 2648 D: 7992

LLR: 2.97 (-2.94,2.94) [0.00,5.00]
Total: 25895 W: 4099 L: 3880 D: 17916

In terms of opportunities for future work opened up by this patch,
the ProbCut rBeta formula could probably be tuned to gain more Elo.


Bench: 5328254

3 years agoUse quiescence search for Probcut
VoyagerOne [Tue, 13 Mar 2018 07:20:20 +0000 (08:20 +0100)]
Use quiescence search for Probcut

Perform qsearch for the preliminary search in Probcut

Passed STC with sprt[-3..1] bounds:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 31090 W: 6386 L: 6283 D: 18421

Passed LTC with sprt[0..4] bounds:
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 104056 W: 15990 L: 15531 D: 72535


Bench: 5404567

3 years agoqsearch(): remove inCheck as a template parameter
Joost VandeVondele [Tue, 13 Mar 2018 07:10:59 +0000 (08:10 +0100)]
qsearch(): remove inCheck as a template parameter

Simplifies a bit, and avoids bugs as in #1478

Passed STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 104862 W: 21302 L: 21337 D: 62223


No functional change

3 years agoAdjust initiative in pure pawn endgames
Jerry Donald Watson [Mon, 12 Mar 2018 09:09:02 +0000 (09:09 +0000)]
Adjust initiative in pure pawn endgames

King and pawn endgames are typically decisive, and a small
advantage is often sufficient to win. Therefore we now take
this into account when computing the initiative adjustment.

This idea came from a series of patches by Gian-Carlo Pascutto.

LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 48770 W: 10203 L: 9845 D: 28722

LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 22252 W: 3572 L: 3366 D: 15314

Ideas for future developement:

- There have been a number of changes to the initiative
  calculation lately. Perhaps the coefficients could be
  tuned again.

- It may be possible to add special knowledge for other
  endgames in the initiative calculation.


Bench: 5750110

3 years agoMovePicker: combine countermove with killers.
protonspring [Mon, 12 Mar 2018 01:47:35 +0000 (02:47 +0100)]
MovePicker: combine countermove with killers.

Handle the countermove in the same way we use stages to progress
through the killer moves, using a common array called "refutations".
Removes some lines of code and simplifies a bit the jump table.

STC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 71707 W: 14622 L: 14595 D: 42490

LTC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 22320 W: 3470 L: 3352 D: 15498


No functional change.

3 years agoConnectivity Score S(3,1) is stronger than S(2,2)
protonspring [Mon, 12 Mar 2018 00:51:12 +0000 (01:51 +0100)]
Connectivity Score S(3,1) is stronger than S(2,2)

I believe my tests were conclusive enough to demonstrate
that a connectivity score of S(3,1) is stronger than S(2,2).

LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 16175 W: 3386 L: 3165 D: 9624

LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 98685 W: 15209 L: 14765 D: 68711

Bench 5601228

3 years agoImplement an old Russian proverb
protonspring [Sat, 10 Mar 2018 10:46:44 +0000 (11:46 +0100)]
Implement an old Russian proverb

"Loose pieces drop, in blitz keep everything protected"

Adding a small S(2,2) bonus for knights, bishops, rooks, and
queens that are "connected" to each other (in the sense that
they are under attack by our own pieces) apparently is a good
thing. It probably helps the pieces work together a bit better.

LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 12317 W: 2655 L: 2467 D: 7195

LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 35725 W: 5516 L: 5263 D: 24946

How to continue from there (by Stefan Geschwentner)?

• First we should identify all other eval terms which have an overlap
  with new connectivity bonus (like the outpost bonus). A simple way
  would be subtract the connectivity bonus from them and look if this
  better, or use a SPSA session for these terms.

• Tuning Connectivity himself with SPSA seems not so promising because
  of the small range which is useful. Here manual testing changes of
  Connectivity like +-1 seems better.

• The eg value is more important because in endgame the position gets
  more open and so attacks on pieces are easier. Another important point
  is that when defending/fortress-like positions each defending piece
  needs a protection, otherwise attacks on them can break defense.


Bench: 5318575

3 years agoAssign improving only once
Joost VandeVondele [Sat, 10 Mar 2018 09:35:10 +0000 (10:35 +0100)]
Assign improving only once

Avoid duplicated code after recent commit "Use evaluation trend
to adjust futility margin". We initialize the improving variable
to true in the check case, which allows to avoid redundant code
in the general case.

Tested for speed by snicolet, patch seems about 0.4% faster.

No functional change.

Note: initializing the improving variable to false in the check
case was tested as a functional change, ending yellow in both STC
and LTC. This change is not included in the commit, but it is an
interesting result that could become part of a future patch about
improving or LMR. Reference of the LTC yellow test:

3 years agoTwo steps slider threats on queen
Alain SAVARD [Fri, 9 Mar 2018 01:04:33 +0000 (20:04 -0500)]
Two steps slider threats on queen

Allow a potential slider threat from a square currently occupied
by a harmless attacker, just as the recent "knight on queen" patch.
Also from not completely safe squares, use the mobilityArea instead
of excluding all pawns for both SlidersOnQueen and KnightOnQueen

We now compute the potential sliders threat on queen only if opponent
has one queen.

Run as SPRT [0,4] since it is some kind of simplification but maybe
not clearly one.

LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 22997 W: 4817 L: 4570 D: 13610

LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 11926 W: 1891 L: 1705 D: 8330

After this patch is committed, we may try to:

• re-introduce some "threat by queen" bonus to make Stockfish's queen
  more aggressive (attacking aspect)

• introduce a concept of "queen overload" to force the opponent queen
  into passivity and protecting duties (defensive aspect)

• more generally, re-tune the queen mobility array since patches in the
  last three months have affected a lot the location/activity of queens.


bench: 5788691

3 years agoSimplification: use Arctan for the optimism S-curve
IIvec [Mon, 5 Mar 2018 21:24:26 +0000 (22:24 +0100)]
Simplification: use Arctan for the optimism S-curve

This was an idea of Gontran Lemaire (gonlem), but the graphs
he published did not seem accurate to me. I did my own graphs,
got my own constants and here is the result:

LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 42179 W: 8704 L: 8622 D: 24853

LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 17737 W: 2702 L: 2577 D: 12458

Note: we are now back to 70% draw rate in selfplay mode!

Bench: 5544908

3 years agoUse evaluation trend to adjust futility margin
Jerry Donald Watson [Wed, 7 Mar 2018 21:31:51 +0000 (22:31 +0100)]
Use evaluation trend to adjust futility margin

Adjust futility margin in the child node based on whether the
static evaluation is improving.

LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 15271 W: 3157 L: 2958 D: 9156

LLR: 2.97 (-2.94,2.94) [0.00,5.00]
Total: 6617 W: 1053 L: 908 D: 4656

Ideas for future work:

- Tune the new margins.
- Try to get this idea to work for futility pruning in parent
  nodes as well.

Bench: 5779242

3 years agoKnight threats on Queen
Stéphane Nicolet [Wed, 7 Mar 2018 21:12:29 +0000 (22:12 +0100)]
Knight threats on Queen

We give a S(21,11) bonus for knight threats on the next moves
against enemy queen. The threats are from squares which are
"not strongly protected" and which may be empty, contain enemy
pieces or even one of our piece at the moment (N,B,Q,R) -- hence
be two-steps threats in the later case because we will have to
move our piece and *then* attack the enemy queen with the knight.

LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 35129 W: 7346 L: 7052 D: 20731

LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 42442 W: 6695 L: 6414 D: 29333

How to continue from there?

• Trying to refine the threat condition ("not strongly protected")
• Trying the two-steps idea for bishops or rooks threats against queen

Bench: 6051247

3 years agoRemove popcount trick from space evaluation
Torsten Franz [Mon, 5 Mar 2018 13:10:13 +0000 (14:10 +0100)]
Remove popcount trick from space evaluation

Similar removal of superposition code trick as in the
"Simplify tropism computation" patch. This simplification
of the space() function will allow us to specify space
masks which can reach into enemy territory.

passed STC:
LLR: 3.38 (-2.94,2.94) [-3.00,1.00]
Total: 184630 W: 40581 L: 40758 D: 103291

passed LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 231799 W: 37647 L: 37858 D: 156294

No functional change.

3 years agoFix a warning in GCC for Windows
Stéphane Nicolet [Tue, 6 Mar 2018 21:11:45 +0000 (22:11 +0100)]
Fix a warning in GCC for Windows

No functional change

3 years agoCode style in Razoring and ProbCut
joergoster [Fri, 2 Mar 2018 10:38:11 +0000 (11:38 +0100)]
Code style in Razoring and ProbCut

No functional change.

3 years agoIntroduce variadic make_bitboard()
Chris Cain [Tue, 6 Mar 2018 00:32:16 +0000 (01:32 +0100)]
Introduce variadic make_bitboard()

Adds a helper function to make a bitboard from a list of squares.

No functional change

3 years agoUsing a S-curve for the optimism measure
Stefano Cardanobile [Sun, 4 Mar 2018 15:50:19 +0000 (16:50 +0100)]
Using a S-curve for the optimism measure

Add a logarithmic term in the optimism computation, increase
the maximal optimism and lower the contempt offset.

This increases the dynamics of the optimism aspects, giving
a boost for balanced positions without skewing too much on
unbalanced positions (but this version will enter panic mode
faster than previous master when behind, trying to draw faster
when slightly behind). This helps, since optimism is in general
a good thing, for instance at LTC, but too high optimism
rapidly contaminates play.

passed STC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 159343 W: 34489 L: 33588 D: 91266

passed LTC:
LLR: 2.97 (-2.94,2.94) [0.00,5.00]
Total: 47491 W: 7825 L: 7517 D: 32149

It must be mentioned that a version of the PR with contempt 0
did not pass STC [0,5]. The version in the patch, which uses
default contempt 12, was found to be as strong as current master
on different matches against SF7 and SF8, both at STC and LTC.

One drawback maybe is that it raises the draw rate in self-play
from 56% to 59%, giving a little bit less sensitivity for SF
developpers to find evaluation improvements by selfplay tests
in fishtest.

Possible further work:

• tune the values accurately, while keeping in mind the drawrate issue
• check whether it is possible to remove linear and offset term
• try to simplify the S-shape curve

Bench: 5934644

3 years agoNo extra stage for QS recaptures.
Joost VandeVondele [Tue, 27 Feb 2018 19:31:13 +0000 (20:31 +0100)]
No extra stage for QS recaptures.

remove the QRECAPTURES and QSEARCH_RECAPTURES stages as they can be
incoorporated in QCAPTURES stage with a simple condition on depth.

passed STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 214964 W: 46188 L: 46443 D: 122333

passed LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 14552 W: 2404 L: 2274 D: 9874

Bench: 6361582

3 years agoDo move-count pruning in probcut
VoyagerOne [Sat, 3 Mar 2018 11:03:38 +0000 (12:03 +0100)]
Do move-count pruning in probcut

LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 4928 W: 1163 L: 1007 D: 2758

LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 20368 W: 3441 L: 3238 D: 13689

Bench: 6361568

3 years agoMerge Stats tables
Marco Costalba [Sat, 3 Mar 2018 10:29:29 +0000 (11:29 +0100)]
Merge Stats tables

Use a recursive std::array with variadic template
parameters to get rid of the last redundacy.

The first template T parameter is the base type of
the array, the W parameter is the weight applied to
the bonuses when we update values with the << operator,
the D parameter limits the range of updates (range is
[-W * D, W * D]), and the last parameters (Size and
Sizes) encode the dimensions of the array.

This allows greater flexibility because we can now tweak
the range [-W * D, W * D] for each table.

Patch removes more lines than what adds and streamlines
the Stats soup in movepick.h

Closes PR#1422 and PR#1421

No functional change.

3 years agoBetter indentation in Makefile
Stéphane Nicolet [Sat, 3 Mar 2018 10:07:23 +0000 (11:07 +0100)]
Better indentation in Makefile

No functional change

3 years agoReintroduce depth 2 razoring (with additional margin)
Tom Vijlbrief [Wed, 28 Feb 2018 12:41:24 +0000 (13:41 +0100)]
Reintroduce depth 2 razoring (with additional margin)

The first depth 2 margin triggers the verification quiescence search.
This qsearch() result has to be better then the second lower margin,
so we only skip the razoring when the qsearch gives a significant

Passed STC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 32133 W: 7395 L: 7101 D: 17637

Passed LTC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 17382 W: 3002 L: 2809 D: 11571

This Elo-gaining version was further simplified following a suggestion
of Marco Costalba:

LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 15553 W: 3505 L: 3371 D: 8677

LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 13253 W: 2270 L: 2137 D: 8846

How to continue after this patch?

Reformating the razoring code (step 7 in search()) to unify the
depth 1 and depth 2 treatements seems quite possible, this could
possibly lead to more simplifications.

Bench: 5765806

3 years agoBlocked pawn storm
Stefan Geschwentner [Wed, 28 Feb 2018 12:00:45 +0000 (13:00 +0100)]
Blocked pawn storm

In pawn structures like white pawns f6,h6 against black pawns f7,g6,h7
the attack on the king is blocked by the own pawns. So decrease the
penalty for king safety.

See diagram and discussion in

A sample position that this patch wants to avoid is the following
1rr2bk1/3q1p1p/2n1bPpP/pp1pP3/2pP4/P1P1B3/1PBQN1P1/1K3R1R w - - 0 1

White pawn storm on the king side was a disaster, it locked the king
side completely. Therefore, all the king tropism bonus that white have
on the king side are useless, and kingadjacent attacks too. Master
gives White a static +4.5 advantage, but White cannot win that game.
The patch is lowering this evaluation artefact.

LLR: 2.94 (-2.94,2.94) [0.00,5.00]
Total: 16467 W: 3750 L: 3537 D: 9180

LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 64242 W: 11130 L: 10745 D: 42367

This version includes reformatting and speed optimization by Alain Savard.

Bench: 5643527

3 years agoTweak time management
Leonid Pechenik [Wed, 28 Feb 2018 11:36:36 +0000 (12:36 +0100)]
Tweak time management

Using a SPSA tuning session to optimize the time management

With SPSA tuning it is not always possible to say where improvements
came from. Maybe some variables changed randomly or because result
was not sensitive enough to them. So my explanation of changes will
not be necessarily correct, but here it is.

• When decrease of thinking time was added by Joost a few months ago
if best move has not changed for several plies, one more competing
indicator  was introduced for the same purpose along with increase
in score and absence of fail low at root. It seems that tuning put
relatively more importance on that new indicator what allowed to save
• Some of this saved time is distributed proportionally between all
moves and some more time were given to moves when score dropped a lot
or best move changed.
• It looks also that SPSA redistributed more time from the beginning to
later stages of game via other changes in variables - maybe because
contempt made game to last longer or for whatever reason.

All of this is just small tweaks here and there (a few percentages changes).

STC (10+0.1):
LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 18970 W: 4268 L: 4029 D: 10673

LTC (60+0.6):
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 72027 W: 12263 L: 11878 D: 47886

Additional non-regression tests at other time controls

Sudden death 60s:
LLR: 2.95 (-2.94,2.94) [-4.00,0.00]
Total: 14444 W: 2715 L: 2608 D: 9121

40 moves repeating at LTC:
LLR: 2.95 (-2.94,2.94) [-4.00,0.00]
Total: 10309 W: 1880 L: 1759 D: 6670

This is a functional patch only for time management, but the bench
does not reflect this because it uses fixed depth search, so the number
of nodes does not change during bench.

No functional change.

3 years agoSimplify tropism computation
Stéphane Nicolet [Tue, 27 Feb 2018 18:10:40 +0000 (19:10 +0100)]
Simplify tropism computation

Simplification. Tests show that the "shift-and-superpose" trick is no longer
necessary. The speed benefit of avoiding a popcount is no longer relevant
on modern machines.

Passed STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 41675 W: 9168 L: 9086 D: 23421

Passed LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 117728 W: 19875 L: 19911 D: 77942

No functional change.

3 years agoStat score initialization: grandchildren
Stefan Geschwentner [Tue, 27 Feb 2018 17:38:08 +0000 (18:38 +0100)]
Stat score initialization: grandchildren

This is the sequel of the previous patch, we now let the parent node initialize
stat score to zero once for all grandchildren.

Initialize statScore to zero for the grandchildren of the current position.
So statScore is shared between all grandchildren and only the first grandchild
starts with statScore = 0. Later grandchildren start with the last calculated
statScore of the previous grandchild. This influences the reduction rules in
LMR which are based on the statScore of parent position.

Tests results against the previous patch:

LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 23676 W: 5417 L: 5157 D: 13102

LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 35485 W: 6168 L: 5898 D: 23419

Bench: 5643520

3 years agoStat score initialization: children
Stefan Geschwentner [Tue, 27 Feb 2018 17:18:07 +0000 (18:18 +0100)]
Stat score initialization: children

Let the parent node initialize stat score to zero once for all siblings.

Initialize statScore to zero for the children of the current position.
So statScore is shared between sibling positions and only the first sibling
starts with statScore = 0. Later siblings start with the last calculated
statScore of the previous sibling. This influences the reduction rules in
in LMR which are based on the statScore of parent position.

LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 22683 W: 5202 L: 4946 D: 12535

LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 48548 W: 8346 L: 8035 D: 32167

Bench: 5833683

3 years agoNo Tempo for draw scores given by heuristic functions
Stéphane Nicolet [Wed, 21 Feb 2018 00:07:35 +0000 (01:07 +0100)]
No Tempo for draw scores given by heuristic functions

The current master applies Eval::Tempo even to leaves evaluated
as draw by some of the static evaluation functions of endgame.cpp
(for instance KNN vs K or stalemates in KP vs K). This results in
some lines being reported as +0.07 or -0.07 when the terminal
position has reached such endgames (0.07 being about the value
of a tempo for Stockfish).

This patch does not apply Eval::tempo to these positions. This leads
to more nodes being evaluated as VALUE_DRAW during search, giving more
opportunities for cut-offs in alpha-beta.

LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 52602 W: 11776 L: 11403 D: 29423

LLR: 2.97 (-2.94,2.94) [0.00,4.00]
Total: 156613 W: 26820 L: 26158 D: 103635

Bench: 4924749

3 years agoSpeedup and simplify pinners and blockers
Marco Costalba [Tue, 27 Feb 2018 00:18:33 +0000 (01:18 +0100)]
Speedup and simplify pinners and blockers

To compute dicovered check or pinned pieces we use some bitwise
operators that are not really needed because already accounted for
at the caller site.

For instance in evaluation we compute:

     pos.pinned_pieces(Us) & s

Where pinned_pieces() is:

     st->blockersForKing[c] & pieces(c)

So in this case the & operator with pieces(c) is useless,
given the outer '& s'.

There are many places where we can use the naked blockersForKing[]
instead of the full pinned_pieces() or discovered_check_candidates().

This path is simpler than original and gives around 1% speed up for me.
Also tested for speed by mstembera and snicolet (neutral in both cases).

No functional change.

3 years agoUnify use of -mdynamic-no-pic
erbsenzaehler [Sat, 10 Feb 2018 01:39:57 +0000 (02:39 +0100)]
Unify use of -mdynamic-no-pic

Apply -mdynamic-no-pic in a single place in the Makefile instead of 5 places.

Verified on three different Macs:
- a MacBook from 2013
- a MacBook running MacOS 10.9.5
- an iMac running MacOS 10.13.3

No functional change.

3 years agoShallow search to verify probcut
AndyGrant [Mon, 26 Feb 2018 02:01:37 +0000 (03:01 +0100)]
Shallow search to verify probcut

Perform a preliminary shallow search to verify a probcut before doing
the normal "depth - 4 plies" search.

LLR: 4.73 (-2.94,2.94) [0.00,5.00]
Total: 36281 W: 8221 L: 7830 D: 20230

LLR: 2.97 (-2.94,2.94) [0.00,5.00]
Total: 22907 W: 3954 L: 3738 D: 15215

Happy to see something from Ethereal work for Stockfish :)

Bench: 5882274

3 years agoCount passed pawns in asymmetry measure
Stéphane Nicolet [Sun, 25 Feb 2018 23:55:01 +0000 (00:55 +0100)]
Count passed pawns in asymmetry measure

The previous asymmetry measure of the pawn structure only used to
consider the number of pawns on semi-opened files in the position.
With this patch we also increase the measure by the number of passed
pawns for both players.

Many thanks to the community for the nice feedback on the previous
version, with special mentions to Alain Savard and Marco Costalba
for clarity and speed suggestions.

LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 13146 W: 3038 L: 2840 D: 7268

LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 27776 W: 4771 L: 4536 D: 18469

How to continue after this patch?

Stockfish will now evaluate more positions with passed pawns, so
tuning the passed pawns values may bring Elo. The patch has also
consequences on the initiative term, where we might want to give
different weights to passed pawns and semi-openfiles (idea by
Stefano Cardanobile).

Bench: 5302866

3 years agoCombine killer moves
Joost VandeVondele [Sun, 25 Feb 2018 21:33:40 +0000 (22:33 +0100)]
Combine killer moves

Move the first killer move out of the capture stage, combining treatment
of first and second killer move.

passed STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 55777 W: 12367 L: 12313 D: 31097

Similar to an earlier proposition of Günther Demetz, see pull request #1075.
I think it is more robust and readable than master, why hand-unroll the loop
over the killer array, and duplicate code ?

This version includes review comments from Marco Costalba.

Bench: 5227124

3 years agoRevert "Count passed pawns in asymmetry measure"
Stéphane Nicolet [Sun, 25 Feb 2018 14:12:19 +0000 (15:12 +0100)]
Revert "Count passed pawns in asymmetry measure"

3 years agoCount passed pawns in asymmetry measure
Stéphane Nicolet [Sun, 25 Feb 2018 12:12:09 +0000 (13:12 +0100)]
Count passed pawns in asymmetry measure

The previous asymmetry measure of the pawn structure only used to
consider the number of pawns on semi-opened files in the postions.
With this patch we also increase the measure by the number of passed
pawns for both players.

LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 13146 W: 3038 L: 2840 D: 7268

LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 27776 W: 4771 L: 4536 D: 18469

How to continue from there: Stockfish will now evaluate more positions
with passed pawns, so tuning the passed pawns values may bring Elo.
The patch also has consequences on the initiative term.

Bench: 5302866

3 years agoJoin all capture init stages in MovePicker
Joost VandeVondele [Sun, 25 Feb 2018 11:49:03 +0000 (12:49 +0100)]
Join all capture init stages in MovePicker

Passed STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 16789 W: 3685 L: 3554 D: 9550

Passed LTC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 21293 W: 3527 L: 3407 D: 14359

No functional change

3 years agoMore robust interaction of singular search and iid
DU-jdto [Sun, 25 Feb 2018 00:14:29 +0000 (01:14 +0100)]
More robust interaction of singular search and iid

When iid (Internal iterative deepening) is invoked, the prior value of ttValue is
not guaranteed to be VALUE_NONE. As such, it is currently possible to enter a state
in which ttValue has a specific value which is inconsistent with tte->bound() and
tte->depth(). Currently, ttValue is only used within the search in a context that
prevents this situation from making a difference (and so this change is non-functional,
but this is not guaranteed to remain the case in the future.

For instance, just changing the tt depth condition in singular extension node to be

    tte->depth() >= depth - 4 * ONE_PLY

instead of

    tte->depth() >= depth - 3 * ONE_PLY

interacts badly with the absence of ttMove in iid. For the ttMove to become a singular
extension candidate, singularExtensionNode needs to be true. With the current master,
this requires that tte->depth() >= depth - 3 * ONE_PLY. This is not currently possible
if tte comes from IID, since the depth 'd' used for the IID search is always less than
depth - 4 * ONE_PLY for depth >= 8 * ONE_PLY (below depth 8 singularExtensionNode can
never be true anyway). However, with DU-jdto/Stockfish@251281a , this condition can be
met, and it is possible for singularExtensionNode to become true after IID. There are
then two mechanisms by which this patch can affect the search:

• If ttValue was VALUE_NONE prior to IID, the fact that this patch sets ttValue allows
  the 'ttValue != VALUE_NONE' condition of singularExtensionNode to be met.

• If ttValue wasn't VALUE_NONE prior to IID, the fact that this patch modifies ttValue's
  value causes a different 'rBeta' to be calculated if the singular extension search is

Tested at STC for non-regression:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 76981 W: 17060 L: 17048 D: 42873

No functional change

3 years agoSimplification: do razoring only for depth 1
DU-jdto [Sat, 24 Feb 2018 12:06:18 +0000 (13:06 +0100)]
Simplification: do razoring only for depth 1

The razoring heuristic is quite a drastic pruning technique,
using a depth 0 search at internal nodes of the search tree
to estimate the true value of depth n nodes. This patch limits
this razoring to the case of internal nodes of depth 1.
Author: Jarrod Torriero (DU-jdto)

LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 8043 W: 1865 L: 1716 D: 4462

LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 32890 W: 5577 L: 5476 D: 21837

Opportunities opened by this patch: it would be interesting to
know if it brings Elo to re-introduce razoring or soft razoring
at depth >= 2, maybe using a larger margin to compensate for the
increased pruning effect.

Bench: 5227124

3 years agoLower razor depth to < 3 and adjust margin
Tom Vijlbrief [Thu, 15 Feb 2018 07:47:30 +0000 (08:47 +0100)]
Lower razor depth to < 3 and adjust margin

Various margins were tested: 600, 560, 585, 580, 590 and 595.

Only 590 (this patch) passed both STC and LTC.
Higher margins appear to be better for longer time controls.

LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 24496 W: 5470 L: 5210 D: 13816

LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 74540 W: 12888 L: 12491 D: 49161

Bench: 5475941

3 years agoReformat SEE to better document the function
Marco Costalba [Fri, 23 Feb 2018 21:02:10 +0000 (22:02 +0100)]
Reformat SEE to better document the function

This is one of the most difficult to understand but also
most important and speed critical functions of SF.

This patch rewrites some part of it to hopefully
make it clearer and drop some redundant variables
in the process.

Same speed than master (or even a bit more).

Thanks to Chris Cain for useful feedback.

No functional change.

3 years agoMove pawn_attacks_bb() helper to bitboard.h
Stéphane Nicolet [Wed, 21 Feb 2018 21:31:38 +0000 (22:31 +0100)]
Move pawn_attacks_bb() helper to bitboard.h

No functional change.

3 years agorename shift variables.
Mike Whiteley [Wed, 21 Feb 2018 20:46:25 +0000 (21:46 +0100)]
rename shift variables.

Where variable names are explicitly incorrect, I feel morally obligated to at least
suggest an alternative. There are many, but these two are especially egregious.

No functional change.

3 years agoAvoid a compilation warning
Alain SAVARD [Tue, 20 Feb 2018 23:52:26 +0000 (00:52 +0100)]
Avoid a compilation warning

Avoid a warning while compiling with gcc version 4.9.2

No functional change.

3 years agoCode style in evaluate.cpp
Marco Costalba [Tue, 20 Feb 2018 16:10:37 +0000 (17:10 +0100)]
Code style in evaluate.cpp

Passed STC
LLR: 2.95 (-2.94,2.94) [-4.00,0.00]
Total: 75666 W: 16482 L: 16616 D: 42568

No functional change.

3 years agoUpdate list of authors after Stockfish 9
Stéphane Nicolet [Sun, 18 Feb 2018 00:51:35 +0000 (01:51 +0100)]
Update list of authors after Stockfish 9

No functional change.

3 years agoSimplify trapped rook
Mike Whiteley [Thu, 15 Feb 2018 18:34:23 +0000 (19:34 +0100)]
Simplify trapped rook

As far as can tell, semiopenFiles are set if there is a pawn anywhere on
the file. The removed condition would be true even if the pawns were very
advanced, which doesn't make sense if we're looking for a trapped rook.
Seems the engine fairs better with this removed. My guess s that the
condition that mobility is 3 or less does this well enough.

Begs the question whether this is a mobility issue alone... not sure.
Should I do LTC test?

LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 13377 W: 3009 L: 2871 D: 7497

Passed LTC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 16288 W: 2813 L: 2685 D: 10790

Bench: 5006365

3 years agoFix gcc PGO build on Windows
Ronald de Man [Sat, 10 Feb 2018 00:44:05 +0000 (01:44 +0100)]
Fix gcc PGO build on Windows

This fixes the issue #1375 of the PGO builds failing under Windows:

Solution found during this discussion in the fishcooking forum:!topic/fishcooking/RjIPgeFFLPQ

Closes #1408.

No functional change.

3 years agoCode style fixes in search.cpp
Marco Costalba [Mon, 12 Feb 2018 21:57:42 +0000 (22:57 +0100)]
Code style fixes in search.cpp

Some code style triviality.

No functional change.

3 years agoUpdate travis CI to g++7
Marco Costalba [Sun, 11 Feb 2018 11:25:48 +0000 (12:25 +0100)]
Update travis CI to g++7

Use newer g++ 7 instead of 6 in travis CI tests.

No functional change.

3 years agoIntroduce dynamic contempt
Stefano Cardanobile [Fri, 9 Feb 2018 17:43:53 +0000 (18:43 +0100)]
Introduce dynamic contempt

Make contempt dependent on the current score of the root position.

The idea is that we now use a linear formula like the following to decide
on the contempt to use during a search :

    contempt = x + y * eval

where x is the base contempt set by the user in the "Contempt" UCI option,
and y * eval is the dynamic part which adapts itself to the estimation of
the evaluation of the root position returned by the search. In this patch,
we use x = 18 centipawns by default, and the y * eval correction can go
from -20 centipawns if the root eval is less than -2.0 pawns, up to +20
centipawns when the root eval is more than 2.0 pawns.

To summarize, the new contempt goes from -0.02 to 0.38 pawns, depending if
Stockfish is losing or winning, with an average value of 0.18 pawns by default.

LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 110052 W: 24614 L: 23938 D: 61500

LLR: 2.97 (-2.94,2.94) [0.00,5.00]
Total: 16470 W: 2896 L: 2705 D: 10869

A second match at LTC was organised against the current master:

ELO: 1.45 +-2.9 (95%) LOS: 84.0%
Total: 19369 W: 3350 L: 3269 D: 12750

Finally, we checked that there is no apparent problem with multithreading,
despite the fact that some threads might have a slightly different contempt
level that the main thread.

Match of this version against master, both using 5 threads, time control 30+0.3:
ELO: 2.18 +-3.2 (95%) LOS: 90.8%
Total: 14840 W: 2502 L: 2409 D: 9929

Include suggestions from Marco Costalba, Aram Tumanian, Ronald de Man, etc.

Bench: 5207156

3 years agoRetire "Extra thinking before accepting draw PVs"
Leonid Pechenik [Tue, 6 Feb 2018 10:14:55 +0000 (05:14 -0500)]
Retire "Extra thinking before accepting draw PVs"

This patch simplifies the time management code, removing the extra
thinking time for moves with draw PV and increasing thinking time
for all moves proportionally by around 4%.

Last time when the time management was carefully tuned was 1.5-2 years
ago. As new patches were getting added, time management was drifting out
of optimum. This happens because when search becomes more precise pv and
score are becoming more stable, there are less fail lows, best move is
picked earlier and there are less best move changes. All this factors are
entering in time management, and average time per move is decreasing with
more and more good patches. For individual patches such effect is small
(except some) and may be up or down, but when there are many of them,
effect is more substantial. The same way benchmark with more and more
patches is slowly drifting down on average.

So my understanding that back in October adding more think time for draw
PV showed positive Elo because time management was not well tuned, there
was more time available, and think_hard patch applied this additional time
to moves with draw PV, while just retuning back to optimum would recover Elo
anyway. It is possible that absence of contempt also helped, as SF9 is showing
less 0.0 scores than the October version.

Anyway, to me it seems that proper place to deal with draw PV is search, and
contempt sounds as much better solution. In time management there is little
additional elo, and if some code is not helping like removed here, it is better
to discard it. It is simpler to find genuine improvement if code is clean.

• Passed STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 20487 W: 4558 L: 4434 D: 11495

• Passed LTC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 41960 W: 7145 L: 7058 D: 27757

• Passed an additional non-regression [-5..0] test at the time control
of 60sec for the game (sudden death) with disabled draw adjudication:
LLR: 2.95 (-2.94,2.94) [-5.00,0.00]
Total: 8438 W: 1675 L: 1586 D: 5177

• Passed an additional non-regression [-5..0] test at the time control
of 1sec+1sec per move with disabled draw adjudication:
LLR: 2.97 (-2.94,2.94) [-5.00,0.00]
Total: 27664 W: 5575 L: 5574 D: 16515

This is a functional change for the time management code.

Bench: 4983414

3 years agoFix bug for 'eval' command in terminal
Stéphane Nicolet [Fri, 9 Feb 2018 00:10:27 +0000 (01:10 +0100)]
Fix bug for 'eval' command in terminal

The 'eval' debugging command in Terminal did not initialize the Eval::Contempt
variable, leading to random output during debugging sessions (normal search
was unaffected by the bug).

Example of session where the two 'eval' commands should give the same output,
but did not:

position startpos
go depth 20

The bug is fixed by initializing Eval::Contempt to SCORE_ZERO in Eval::trace

No functional change.

3 years agoA combo of 3 successful tuning patches
FauziAkram [Thu, 8 Feb 2018 14:13:26 +0000 (15:13 +0100)]
A combo of 3 successful tuning patches

Shelter Weakness by Fauzi Akram Dabat
Threats by Alain Savard
Passed Pawns by Alain Savard

LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 51378 W: 11592 L: 11223 D: 28563

LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 21631 W: 3888 L: 3661 D: 14082

Bench: 4983414

3 years agoObey skipQuiets strictly in MovePicker
protonspring [Thu, 8 Feb 2018 09:45:45 +0000 (10:45 +0100)]
Obey skipQuiets strictly in MovePicker

The current logic in master is to continue return quiet moves if their
history score is above 0. It appears as though this check can be
removed, which is also more logically consistent with the “skipQuiets”
semantics used in search.cpp.

This patch may open new opportunitiesto get Elo by changing or
tuning the definition of 'moveCountPruning' in line 830 of search.cpp,
because obeying skipQuiets without checking the history scores makes
the search more sensitive to 'moveCountPruning'.

LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 34780 W: 7680 L: 7584 D: 19516

LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 38757 W: 6732 L: 6641 D: 25384

Bench 4954595

3 years agoMore robust bench extraction
Joost VandeVondele [Wed, 7 Feb 2018 00:26:46 +0000 (01:26 +0100)]
More robust bench extraction

Allow travis.yml to recognize a variety of bench formats in commit messages, for instance:

Bench: 5023593. (really).
bench: 5023593 (it was 1234567)
bench : 5023593 (blah blah)
Bench: 5023593. 567 something (1234567) 563

No functional change.

3 years agoEnable LTO for clang
syzygy1 [Mon, 5 Feb 2018 23:43:29 +0000 (00:43 +0100)]
Enable LTO for clang

Enable link-time optimization in the Makefile when compiling with clang.
Also update travis.yml to use clang++-5.0 and llvm-5.0-dev.

No functional change.

3 years ago Don’t score and sort all captures in RECAPTURES stage.
protonspring [Mon, 5 Feb 2018 16:27:59 +0000 (17:27 +0100)]
Don’t score and sort all captures in RECAPTURES stage.

    For these recaptures, we’re are only considering those captures
    that recapture the recapture square (small portion of all the
    captures). Therefore, scoring all of the captures and pick_besting
    out of the whole group is not necessary.

    LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
    Total: 85583 W: 18978 L: 18983 D: 47622

    LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
    Total: 20231 W: 3533 L: 3411 D: 13287

    Bench: 5023593

3 years agoRevert "Implement old 'multipv' search"
Stéphane Nicolet [Sun, 4 Feb 2018 20:42:56 +0000 (21:42 +0100)]
Revert "Implement old 'multipv' search"

This revert the following commit:

Bug report by Ronald de Man in issue:

Bench: 5023629

3 years agoSimplify qsearch stages in MovePicker
protonspring [Sun, 4 Feb 2018 13:57:57 +0000 (14:57 +0100)]
Simplify qsearch stages in MovePicker

The difference between QCAPTURES_1 and QCAPTURES_2 quiescence search stages
boils down to a simple check of depth. The way it's being done now is
unnecessarily complex.

This patch is simpler, clearer, and easier to understand.

Passed SPRT[-3..1] test at STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 99755 W: 22158 L: 22192 D: 55405

No functional change.

3 years agoImplement 'old' multipv search.
joergoster [Wed, 31 Jan 2018 17:23:57 +0000 (18:23 +0100)]
Implement 'old' multipv search.

It seems to be a waste of time to loop through all remaining root moves
after finishing each PV line. This patch skips this until we have reached
the last PV line (this is the way it was done in Glaurung and very early
versions of Stockfish).

No functional change in Single PV mode.

MultiPV=3 STC and LTC tests
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 3113 W: 1248 L: 1064 D: 801

LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 2260 W: 848 L: 679 D: 733

Bench: 5023629

3 years agoRestore development version
Stéphane Nicolet [Sun, 4 Feb 2018 01:08:09 +0000 (02:08 +0100)]
Restore development version

No functional change.

3 years agoImproved spelling, grammar and comment
Stéphane Nicolet [Sat, 3 Feb 2018 23:13:56 +0000 (00:13 +0100)]
Improved spelling, grammar and comment

Author: Ben Koshy

No functional change

3 years agoStockfish 9
mstembera [Wed, 31 Jan 2018 10:41:09 +0000 (02:41 -0800)]
Stockfish 9

Official release version of Stockfish 9

Bench 5023629

3 years agoRetire lever (#1378)
Torsten Franz [Tue, 30 Jan 2018 08:40:56 +0000 (09:40 +0100)]
Retire lever (#1378)

Retire the lever bonus from pawns evaluation

LLR: 2.94 (-2.94,2.94) [-3.00,1.00]
Total: 88290 W: 19549 L: 19560 D: 49181

LLR: 3.22 (-2.94,2.94) [-3.00,1.00]
Total: 104603 W: 18105 L: 18108 D: 68390

Bench 5023629

4 years agoLimit the king distance factor when evaluating passed pawns (#1373)
Rocky640 [Sun, 28 Jan 2018 13:56:45 +0000 (08:56 -0500)]
Limit the king distance factor when evaluating passed pawns (#1373)

Limit the king distance factor when evaluating passed pawns
Passed STC
LLR: 3.31 (-2.94,2.94) [0.00,5.00]
Total: 23987 W: 5550 L: 5281 D: 13156

and LTC
LLR: 2.97 (-2.94,2.94) [0.00,5.00]
Total: 16926 W: 3014 L: 2820 D: 11092

Bench: 5059457

4 years agoThis modifies the in-search TB probing to continue searching for a mate "behind"...
syzygy1 [Sun, 28 Jan 2018 13:40:07 +0000 (14:40 +0100)]
This modifies the in-search TB probing to continue searching for a mate "behind" a TB win (or loss). (#1285)

It does the following:

- If a TB win or loss value allows an alpha or beta cutoff, the cutoff is taken.
- Otherwise, the search of the current subtree continues. In PV nodes, the final value returned is adjusted to reflect that the position is a TB win (or loss).

The patch also fixes a potential problem caused by root_probe() and root_probe_wdl() dirtying the root-move scores.

This patch removes the limitation of current master that a mate is never found if the root position is not yet in the TBs, but the path to mate at some point enters the TBs. The patch is intended to preserve the efficiency and effectiveness of the current TB probing approach.

No functional change (withouth TB)

4 years agoTop CPU Contributors as of January 2018 (#1367)
mibere [Wed, 24 Jan 2018 15:54:04 +0000 (16:54 +0100)]
Top CPU Contributors as of January 2018 (#1367)

No functional change.

4 years agoContempt 20
Stéphane Nicolet [Mon, 22 Jan 2018 11:59:00 +0000 (12:59 +0100)]
Contempt 20

Set the default contempt value of Stockfish to 20 centipawns.

The contempt feature of Stockfish tries to prevent the engine from
simplifying the position too quickly when it feels that it is very
slightly behind, instead keeping the tension a little bit longer.

Various tests in November 2017 have proved that our current imple-
mentation works well against SF7 (which is about 130 Elo weaker than
current master) and than the Elo gain is an increasing function of
contempt, going (against SF7) from +0 Elo when contempt is set at
zero centipawns, to +30 Elo when contempt is 40 centipawns.

See pull request 1325 for details:

This november discussion left open the decision of which "default"
value for contempt we should use for Stockfish, taking into account
the various uses ofStockfish (opening preparation for humans, computer
online tournaments,analysis tool for web pages, human/computer play,

This pull request proposes to set the default contempt value of SF
to twenty centipawns, which turns out to be the highest value which
is not a regression against current master, as this seemed to be a
good compromise between risk and safety. A couple of SPRT[-3..1]
tests were done to bisect this value:

Contempt 10: (PASSED)
Contempt 15: (PASSED)
Contempt 20: (PASSED)
Contempt 25: (FAILED)

Surprisingly, a test at "very long time control" hinted that using
contempt 20 is not only be non-regressive against contempt 0, but
may actually exhibit some small Elo gain, giving a likehood of superio-
rity of 88.7% after 8500 games:

ELO: 2.28 +-3.7 (95%) LOS: 88.7%
Total: 8521 W: 1096 L: 1040 D: 6385

Finally, there was some concerns that a contempt value of 20 would
be worse than a value of 7, but a test with 20000 games at STC was

ELO: 0.45 +-3.1 (95%) LOS: 61.2%
Total: 20000 W: 4222 L: 4196 D: 11582

See the comments in pull request 1361 for the long, nice discussion
(180 entries :-)) leading to the decision to propose contempt 20 as
the default value:

Whether Stockfish should strictly adhere to the Komodo and Houdini
semantics and add the UCI commands to force the contempt to be White
in the so-called "analysis mode" is still under discussion, and may
be or may not be the object of a future commit.

Bench: 5783344

4 years agoMake razor margin depth independent
Tom Vijlbrief [Tue, 16 Jan 2018 07:21:41 +0000 (08:21 +0100)]
Make razor margin depth independent

LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 37171 W: 6680 L: 6587 D: 23904

LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 11632 W: 1574 L: 1442 D: 8616

bench: 5098576

4 years agoSimplify away redundant SEE pruning condition (#1363)
Fabian Fichter [Tue, 23 Jan 2018 13:05:48 +0000 (14:05 +0100)]
Simplify away redundant SEE pruning condition (#1363)

SEE immediately returns true for promotions,
so excluding them before checking SEE is redundant.

LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 56758 W: 10166 L: 10106 D: 36486

No functional change.

4 years agoFix bench number
Marco Costalba [Sat, 13 Jan 2018 08:21:23 +0000 (09:21 +0100)]
Fix bench number

Incorrect bench number in master. Fix it.

bench: 4971497

4 years agoSimplify verification search (#1362)
Günther Demetz [Sat, 13 Jan 2018 08:01:23 +0000 (09:01 +0100)]
Simplify verification search (#1362)

1. avoid recursive call of verification.
   For the interested side to move recursion makes no sense.
   For the other side it could make sense in case of mutual zugzwang,
   but I was not able to figure out any concrete problematic position.
   Allows the removal of 2 local variables.

2. avoid further reduction by removing R += ONE_PLY;

Benchmark with zugzwang-suite (see #1338), max 45 secs per position:
Patch  solves 33 out of 37
Master solves 31 out of 37

LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 76188 W: 13866 L: 13840 D: 48482

LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 40479 W: 5247 L: 5152 D: 30080

bench: 5340015

4 years agoRevert to old time management (#1351)
IIvec [Sat, 13 Jan 2018 07:59:20 +0000 (08:59 +0100)]
Revert to old time management (#1351)

As many users reported some problems with new time management,
and recent tests on longer time controls

are even little in favor of old time management, this revert seems as a logical step.

LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 14060 W: 2562 L: 2430 D: 9068

LLR: 3.44 (-2.94,2.94) [-3.00,1.00]
Total: 31611 W: 3958 L: 3827 D: 23826

bench: 5365777 (same as master)

4 years agoUse mobility in kingsafety (#1360)
mbootsector [Sat, 13 Jan 2018 07:56:42 +0000 (08:56 +0100)]
Use mobility in kingsafety (#1360)

Use mobility in kingsafety

LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 32651 W: 6057 L: 5792 D: 20802

LLR: 2.94 (-2.94,2.94) [0.00,5.00]
Total: 17875 W: 2421 L: 2245 D: 13209

bench: 5365777

4 years agoRemove ThreatByHangingPawn bonus (#1356)
hxim [Thu, 4 Jan 2018 21:31:30 +0000 (22:31 +0100)]
Remove ThreatByHangingPawn bonus (#1356)

* no ThreatByHangingPawn

* bench: 4919682

4 years agoNew Year 2018
Joost VandeVondele [Mon, 1 Jan 2018 09:33:07 +0000 (10:33 +0100)]
New Year 2018

Adjust copyright headers.

No functional change.

4 years agoExplicitly zero TT upon resize.
Joost VandeVondele [Mon, 1 Jan 2018 09:10:41 +0000 (10:10 +0100)]
Explicitly zero TT upon resize.

as discussed in issue #1349, the way pages are allocated with calloc might imply some overhead on first write.
This overhead can be large and slow down the first search after a TT resize significantly, especially for large TT.
Using an explicit clear of the TT on resize fixes this problem.

Not implemented, but possibly useful for large TT, is to do this zero-ing using all search threads. Not only would this be faster, it could also lead to a more favorable memory allocation on numa systems with a first touch policy.

No functional change.

4 years agoInclude x-ray attacks through all queens independently of the color.
Guenther Demetz [Fri, 22 Dec 2017 10:50:09 +0000 (11:50 +0100)]
Include x-ray attacks through all queens independently of the color.

When calculating attacks from rooks/bishops current master includes
x-rays through own queen. This patch includes also x-rays through
opponent queen.

Credits go to Brian who inspired for this idea!topic/fishcooking/Z3APRYpQeMU

LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 41549 W: 7544 L: 7244 D: 26761
Elo 2.05 [-0.29,4.19] (95%)

LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 110010 W: 14208 L: 13739 D: 82063
Elo 1.20 [-0.27,2.55] (95%)

bench: 5544445