stockfish
18 months agoSimplifying away the progressKey
Stéphane Nicolet [Mon, 21 May 2018 07:37:16 +0000 (09:37 +0200)]
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
http://tests.stockfishchess.org/tests/view/5b015a1c0ebc5914abc126e5

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

No functional change.

19 months agoFix MSVC errors in tbprobe.cpp
mstembera [Wed, 16 May 2018 21:38:13 +0000 (23:38 +0200)]
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.

19 months agoUse cycle detection to bound search value
Tom Truscott [Wed, 16 May 2018 20:47:41 +0000 (22:47 +0200)]
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
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
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

19 months agoUpdate search.cpp
VoyagerOne [Mon, 14 May 2018 04:52:16 +0000 (06:52 +0200)]
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
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
http://tests.stockfishchess.org/tests/view/5af85dd40ebc591fdf408b87

Also use local variable excludedMove in NMP (marotear)

Bench:  5294316

19 months agoTweak kingAttackersCount and KingAttackWeights
Stéphane Nicolet [Sun, 13 May 2018 05:20:39 +0000 (07:20 +0200)]
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
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
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

19 months agoInclude all blockers in king danger
mstembera [Thu, 10 May 2018 20:49:56 +0000 (13:49 -0700)]
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

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

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

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.

19 months agoConsolidate pawn storm types
protonspring [Thu, 10 May 2018 13:46:13 +0000 (15:46 +0200)]
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
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
http://tests.stockfishchess.org/tests/view/5af3b2e20ebc5968e6524013

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

Bench: 5244314

19 months agoTune null move pruning
Stefan Geschwentner [Thu, 10 May 2018 10:27:14 +0000 (12:27 +0200)]
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
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
http://tests.stockfishchess.org/tests/view/5af3cf820ebc5968e6524022

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

Bench: 4777674

19 months agoTuned some pawns and evaluation constants
candirufish [Wed, 9 May 2018 07:18:22 +0000 (09:18 +0200)]
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
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
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

19 months agoRemove goto, limit skipping to NMP
Joost VandeVondele [Tue, 8 May 2018 23:40:32 +0000 (01:40 +0200)]
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
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
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

19 months agoTweak null move pruning conditions
Stefan Geschwentner [Tue, 8 May 2018 17:03:22 +0000 (19:03 +0200)]
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
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
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

19 months agoDrop the lever condition for backwards
Alain SAVARD [Tue, 8 May 2018 09:00:51 +0000 (11:00 +0200)]
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
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
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

19 months agoRemove skipEarlyPruning argument to search()
Joost VandeVondele [Tue, 8 May 2018 08:43:46 +0000 (10:43 +0200)]
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
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
http://tests.stockfishchess.org/tests/view/5aefd4b80ebc5902a409a164

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

Bench: 4953556

19 months agoImprove signature script
Joost VandeVondele [Tue, 8 May 2018 08:31:20 +0000 (10:31 +0200)]
Improve signature script

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

No functional change

19 months agoSimplify the backward pawns code
protonspring [Sun, 6 May 2018 07:42:49 +0000 (09:42 +0200)]
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
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
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

19 months agoTweak the connected[] array value for pawns on rank 5
Stéphane Nicolet [Wed, 2 May 2018 19:49:54 +0000 (21:49 +0200)]
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
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
http://tests.stockfishchess.org/tests/view/5aea34a40ebc5902a104ebe5

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

Bench: 5186783

19 months agoCorrect a bug introduced by Stéphane in the previous patch.
Stéphane Nicolet [Wed, 2 May 2018 11:20:47 +0000 (13:20 +0200)]
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

19 months agoUse special rule for BlockedByKing
protonspring [Tue, 1 May 2018 21:50:23 +0000 (23:50 +0200)]
Use special rule for BlockedByKing

Simplification: remove BlockedByKing from storm array and use a special rule.

The BlockedByKing section in the storm array is substantially similar to the
Unopposed section except for two extreme values V(-290), V(-274). Turns out
removing BlockedByKing and using a special rule for these two values shows
no Elo loss. All the other values in the BlockedByKing section are apparently
irrelevant. BlockedByKing now falls under unopposed which (to me) is a bit
more logical since there is no defending pawn on this file. Also, retuning
the Unopposed section may be another improvement.

GOOD) This is a simplification because the entire BlockedByKing section of
the storm array goes away reducing a few lines of code (and less values to
tune). This also brings clarity because the special rule is self documenting.

BAD) It takes execution time to apply the special rule. This should be negli-
gible because it is based on a template parameter and is boiled down to two
bitwise AND's.

STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 33470 W: 6820 L: 6721 D: 19929
http://tests.stockfishchess.org/tests/view/5ae7b6e60ebc5926dba90e13

LTC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 47627 W: 7045 L: 6963 D: 33619
http://tests.stockfishchess.org/tests/view/5ae859ff0ebc5926dba90e85

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

Bench: 5512000

-----------

How to continue after this patch?

This patch may open the possibility to move the special rule to evaluate.cpp
in the evaluate::king() function, where we could refine the rule using king
danger information. For instance, with a king in H2 blocking an opponent pawn
in H3, it may be critical to know that the opponent has no safe check in G2
before giving the bonus :-)

19 months agoPenalty for bad bishop with blocked central files
MJZ1977 [Tue, 1 May 2018 05:12:17 +0000 (07:12 +0200)]
Penalty for bad bishop with blocked central files

We increase the penalty for bad bishops by a factor proportional
to the number of our blocked pawns in the center files C, D, E or F.

STC:
LLR: 2.97 (-2.94,2.94) [0.00,5.00]
Total: 8868 W: 1870 L: 1700 D: 5298
http://tests.stockfishchess.org/html/live_elo.html?5ae7674f0ebc590e39268b34

LTC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 5813 W: 950 L: 808 D: 4055
http://tests.stockfishchess.org/html/live_elo.html?5ae77bae0ebc5926dba90dd9

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

Bench: 5364190

19 months agoAlways scale using pawn contribution
Stefano80 [Sun, 29 Apr 2018 05:23:32 +0000 (07:23 +0200)]
Always scale using pawn contribution

This is a further step in the long quest for a simple way of determining
scale factors for the endgame.

Here we remove the artificial restriction in evaluate_scale_factor()
based on endgame score. Also SCALE_FACTOR_ONEPAWN can be simplified
away. The latter is a small non functional simplification with respect
to the version that was testedin the framework, verified on bench with
depth 22 for good measure.

Passed STC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 49438 W: 9999 L: 9930 D: 29509
http://tests.stockfishchess.org/tests/view/5ae20c8b0ebc5963175205c8

Passed LTC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 101445 W: 15113 L: 15110 D: 71222
http://tests.stockfishchess.org/tests/view/5ae2a0560ebc5902a1998986

How to continue from there?

Maybe the general case could be scaled with pawns from both colors
without losing Elo. If that is the case, then this could be merged
somehow with the scaling in evaluate_initiative(), which also uses
a additive malus down when the number of pawns in the position goes
down.

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

Bench: 5254862

19 months agoSimplifiy IID condition
Joost VandeVondele [Thu, 26 Apr 2018 14:56:52 +0000 (16:56 +0200)]
Simplifiy IID condition

do IID for all sufficiently deep searches without TT move.

passed STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 25494 W: 5313 L: 5199 D: 14982
http://tests.stockfishchess.org/tests/view/5ae1e8dd0ebc596317520583

passed LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 80582 W: 12162 L: 12130 D: 56290
http://tests.stockfishchess.org/tests/view/5ae1f5ab0ebc5963175205a4

Bench: 4966970

19 months agoFix 'make strip' for mingw.
Joost VandeVondele [Thu, 26 Apr 2018 22:07:56 +0000 (00:07 +0200)]
Fix 'make strip' for mingw.

Currently the make strip target is broken on mingw as the exe name is wrong (stockfish instead of stockfish.exe).

Needs some testing by mingw users (both profile-build and strip, native and cross).

No functional change.

19 months agoUpdate various comments
Stéphane Nicolet [Sun, 29 Apr 2018 04:48:18 +0000 (06:48 +0200)]
Update various comments

Spotted by Alain Savard, Joost VandeVondele, Ronald de Man, Fabian Fichter, Chris Cain, xoto10

No functional change

19 months agoNo Queen in the MobilityArea
Alain SAVARD [Mon, 23 Apr 2018 19:49:34 +0000 (15:49 -0400)]
No Queen in the MobilityArea

Queen was recently excluded from the mobility area of friendly minor
pieces. Exclude queen also from the mobility area of friendly majors too.

Run as a simplification:

STC
http://tests.stockfishchess.org/tests/view/5ade396f0ebc59602d053742
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 46972 W: 9511 L: 9437 D: 28024

LTC
http://tests.stockfishchess.org/tests/view/5ade64b50ebc5949f20a24d3
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 66855 W: 10157 L: 10105 D: 46593

How to continue from there?

The mobilityArea is used in various places of the evaluation as a
soft proxy for "not attacked by the opponent pawns". Now that the
mobility area is getting smaller and smaller, it may be worth to
hunt for Elo gains by trying the more direct ~attackedBy[Them][PAWN]
instead of mobilityArea[Us] in these places.

Bench: 4650572

19 months agoSimplify the ShelterStrength[] array
Stéphane Nicolet [Mon, 23 Apr 2018 07:48:53 +0000 (09:48 +0200)]
Simplify the ShelterStrength[] array

Remove the distinction between the king file and the two neighbours
files in the ShelterStrength[] array. Instead we initialize the safety
variable in the evaluate_shelter() function with a -10 penalty if our
king is on a semi-open file (ie. if our king is on a file without a pawn
protection).

Also rename shelter_storm() to evaluate_shelter() while there.

STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 23153 W: 4795 L: 4677 D: 13681
http://tests.stockfishchess.org/tests/view/5adcb83d0ebc595ec7ff8aa7

LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 25728 W: 3934 L: 3821 D: 17973
http://tests.stockfishchess.org/tests/view/5adcdcb60ebc595ec7ff8adb

See the commit history in PR#1559 for the proof that the committed
version is equivalent to the version in the tests above:
https://github.com/official-stockfish/Stockfish/pull/1559

Full credit to @protonspring for the renormalized values of the
ShelterStrength[] array used for the simplification. Thanks!

Bench: 4703935

19 months agoAlternative formula for dynamic contempt
ceebo [Mon, 23 Apr 2018 07:13:07 +0000 (09:13 +0200)]
Alternative formula for dynamic contempt

Replace the formula involving arctan with something having similar
behaviour that can be implemented using integer-only operations.

STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 34781 W: 7189 L: 7093 D: 20499
http://tests.stockfishchess.org/tests/view/5ad7c95f0ebc595700526e76

LTC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 39743 W: 5950 L: 5857 D: 27936
http://tests.stockfishchess.org/tests/view/5ad886ee0ebc595700526e9b

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

Bench: 5549801

19 months agoRemove template W param
Joost VandeVondele [Mon, 23 Apr 2018 06:45:50 +0000 (08:45 +0200)]
Remove template W param

Different W template parameters for the different statEntries are
not needed, simplify by consistently using 32.

Passed STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 21683 W: 4545 L: 4424 D: 12714
http://tests.stockfishchess.org/tests/view/5ad797550ebc595700526e59

Passed LTC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 110391 W: 16551 L: 16562 D: 77278
http://tests.stockfishchess.org/tests/view/5ad7a88f0ebc595700526e61

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

Bench: 5120532

19 months agoAllow UCI parameters to be double
Stéphane Nicolet [Thu, 19 Apr 2018 02:16:19 +0000 (04:16 +0200)]
Allow UCI parameters to be double

Change the operators of the Option type in uci.h to accept floating
point numbers in double precision on input as the numerical type for
the "spin" values of the UCI protocol.

The output of Stockfish after the "uci" command is unaffected.

This change is compatible with all the existing GUI (as they will
continue sending integers that we can interpret as doubles in SF),
and allows us to pass double parameters to Stockfish in the console
via the "setoption" command. This will be useful if we implement
another tuner as an alternative for SPSA.

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

No functional change.

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

A example of the new functionality in action in the branch `tune_float2'`:
https://github.com/snicolet/Stockfish/commit/876c322d0f20ee232da977b4d3489c4cc929765e

I have added the following lines in ucioptions.cpp:

```C++

void on_pi(const Option& o)
{
      double x = Options["PI"];  // or double x = o;
      std::cerr << "received value is x = " << x << std::endl;
}

...

o["PI"]   << Option(3.1415926, -1000000010000000, on_pi);
```

Then I can change the value of Pi in Stockfish via the command line, and
check that Stockfish understands a floating point:

````
> ./stockfish
> setoption name PI value 2.7182818284

received value is x = 2.71828
````

On output, the default value of Pi is truncated to 3 (to remain compatible
with the UCI protocol and GUIs):

````
> uci

[...]
option name SyzygyProbeLimit type spin default 6 min 0 max 6
option name PI type spin default 3 min -10000000 max 10000000
uciok
````

19 months agoSimplify BlockedByKing in pawn storms
protonspring [Wed, 18 Apr 2018 18:03:37 +0000 (20:03 +0200)]
Simplify BlockedByKing in pawn storms

This patch is non-functional. Current master does four operations to determine
whether an enemy pawn on this file is blocked by the king or not

```
f == file_of(ksq) && rkThem == relative_rank(Us, ksq) + 1 )
```

By adding a direction (based on the template color), this is reduced to two
operations. This works because b is limited to enemy pawns that are ahead of
the king and on the current file.

```
shift<Down>(b) & ksq
```

I've added a line of code, but the number of executing instructions is reduced
(I think). I'm not sure if this counts as a simplification, but it should
theoretically be a little faster (barely). The code line length is also reduced
making it a little easier to read.

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

No functional change.

19 months agoSimplify the shelter mask
Stéphane Nicolet [Wed, 18 Apr 2018 17:53:39 +0000 (19:53 +0200)]
Simplify the shelter mask

The line 246 of pawns.cpp is not necessary, because we restrict the bitboards
to file_of(f) in lines 253 and 256 anyway.

No functional change.

19 months agoTidy up on Overload
Alain SAVARD [Wed, 18 Apr 2018 17:44:22 +0000 (19:44 +0200)]
Tidy up on Overload

Move new code in the if (defended | weak) {} section.

No functional change

19 months agoDocument Elo impact of the LMR part of search
Joost VandeVondele [Wed, 18 Apr 2018 17:17:16 +0000 (19:17 +0200)]
Document Elo impact of the LMR part of search

Similar to before, document Elo impact of various LMR steps

Tests run by @jerrydonaldwatson

t1 http://tests.stockfishchess.org/tests/view/5abece950ebc591a560aad0b
t2 http://tests.stockfishchess.org/tests/view/5abecf0c0ebc591a560aad0d
t3 http://tests.stockfishchess.org/tests/view/5abecf7b0ebc591a560aad0f
t4 http://tests.stockfishchess.org/tests/view/5abecfe70ebc591a560aad14
t5 http://tests.stockfishchess.org/tests/view/5abed42b0ebc591a560aad33
t6 http://tests.stockfishchess.org/tests/view/5abed0b90ebc591a560aad19
t7 http://tests.stockfishchess.org/tests/view/5abed1240ebc591a560aad1b
t8 http://tests.stockfishchess.org/tests/view/5abed1b90ebc591a560aad1d

No functional change.

19 months agoTablebases root ranking
syzygy1 [Wed, 18 Apr 2018 16:38:38 +0000 (18:38 +0200)]
Tablebases root ranking

This patch corrects both MultiPV behaviour and "go searchmoves" behaviour
for tablebases.

We change the logic of table base probing at root positions from filtering
to ranking. The ranking code is much more straightforward than the current
filtering code (this is a simplification), and also more versatile.

If the root is a TB position, each root move is probed and assigned a TB score
and a TB rank. The TB score is the Value to be displayed to the user for that
move (unless the search finds a mate score), while the TB rank determines which
moves should appear higher in a multi-pv search. In game play, the engine will
always pick a move with the highest rank.

Ranks run from -1000 to +1000:

901 to 1000   : TB win
900           : normally a TB win, in rare cases this could be a draw
1 to 899      : cursed TB wins
0             : draw
-1 to -899    : blessed TB losses
-900          : normally a TB loss, in rare cases this could be a draw
-901 to -1000 : TB loss

Normally all winning moves get rank 1000 (to let the search pick the best
among them). The exception is if there has been a first repetition. In that
case, moves are ranked strictly by DTZ so that the engine will play a move
that lowers DTZ (and therefore cannot repeat the position a second time).

Losing moves get rank -1000 unless they have relatively high DTZ, meaning
they have some drawing chances. Those get ranks towards -901 (when they
cross -900 the draw is certain).

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

No functional change (without tablebases).

19 months agoAnalysis Contempt combo box
syzygy1 [Wed, 18 Apr 2018 15:30:00 +0000 (17:30 +0200)]
Analysis Contempt combo box

This patch introduces an Analysis Contempt UCI combo box to control
the behaviour of contempt during analysis. The possible values are
Both, Off, White, Black. Technically, the engine is supposed to be in
analysis mode if UCI_AnalyseMode is set by the graphical user interface
or if the user has chosen infinite analysis mode ("go infinite").

Credits: the idea for the combo box is due to Michel Van den Bergh.

No functional change (outside analysis mode).

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

The so-called "contempt" is an optimism value that the engine adds
to one color to avoid simplifications and keep tension in the position
during its search. It was introduced in Stockfish 9 and seemed to give
good results during the TCEC 11 tournament (Stockfish seemed to play a
little bit more actively than in previous seasons).

The patch does not change the play during match or blitz play, but gives
more options for correspondance players to decide for which color(s) they
would like to use contempt in analysis mode (infinite time). Here is a
description of the various options:

* Both  : in analysis mode, use the contempt for both players (alternating)
* Off   : in analysis mode, use the contempt for none of the players
* White : in analysis mode, White will play actively, Black will play passively
* Black : in analysis mode, Black will play actively, White will play passively

20 months agoFix reported DTZ for mate-in-1-ply positions
syzygy1 [Sat, 14 Apr 2018 06:36:29 +0000 (08:36 +0200)]
Fix reported DTZ for mate-in-1-ply positions

This corrects a bug in Tablebases::probe_dtz() which sometimes causes
a higher DTZ value to be returned for the position one ply before mate
than for the position two plies before mate.

The problem was reported by Kolja Kühn here:
http://talkchess.com/forum/viewtopic.php?p=757497#757497

It is explained here:
http://talkchess.com/forum/viewtopic.php?p=757506#757506

I have also adjusted some comments to make clear that probe_dtz()
returns -1 for a mate position.

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

No functional change

20 months agoFurther documentation and coding style on TB code
Marco Costalba [Thu, 12 Apr 2018 07:22:40 +0000 (09:22 +0200)]
Further documentation and coding style on TB code

This patch adds some documentation and code cleanup to tablebase code.

It took me some time to understand the relation among the differrent
structs, although I have rewrote them fully in the past. So I wrote
some detailed documentation to avoid the same efforts for future readers.

Also noteworthy is the use a standard hash table implementation with a
more efficient 1D array instead of a 2D array. This reduces the average
lookup steps of 90% (from 343 to 38 in a bench 128 1 16 run) and reduces
also the table from 5K to 4K
entries.

I have tested on 5-men and no functional and no slowdown reported. It
should be verified on 6-men that the new hash does not overflow. It is
enough to run ./stockfish with 6-men available: if it does not assert at
startup it means everything is ok with 6-men too.

EDIT: verified for 6-men tablebase by Jörg Oster. Thanks!

No functional change.

20 months agoSimplify condition in space definition
Jerry Donald Watson [Mon, 9 Apr 2018 23:28:26 +0000 (00:28 +0100)]
Simplify condition in space definition

We remove an unnecessary condition in the definition of safe squares
in the space evaluation. Only the squares which are occupied by our
pawns or attacked by our opponent's pawns are now excluded.

STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 21096 W: 4321 L: 4199 D: 12576
http://tests.stockfishchess.org/tests/view/5acbf7510ebc59547e537d4e

LTC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 23437 W: 3577 L: 3460 D: 16400
http://tests.stockfishchess.org/tests/view/5acc0f750ebc59547e537d6a

It may be possible to further refine the definition of such safe squares.

Bench: 5351765

20 months agoReset negative statScore on fail high
VoyagerOne [Sat, 7 Apr 2018 13:46:29 +0000 (09:46 -0400)]
Reset negative statScore on fail high

STC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 9073 W: 1937 L: 1766 D: 5370

LTC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 53530 W: 8139 L: 7823 D: 37568

Bench: 5170165

20 months agoIntroduce Overload
Mark Tenzer [Fri, 6 Apr 2018 23:20:48 +0000 (01:20 +0200)]
Introduce Overload

This patch applies a S(10, 5) bonus for every square that is:

- Occupied by an enemy piece which is not a pawn
- Attacked exactly once by our pieces
- Defended exactly once by enemy pieces

The idea is that these pieces must be defended. Their defenders have
dramatically limited mobility, and they are vulnerable to our future
attack.

As with connectivity, there are probably many more tests to be run in
this area. In particular:

- I believe @snicolet's queen overload tests have demonstrated a potential
  need for a queen overload bonus above and beyond this one; however, the
  conditions for "overload" in this patch are different (excluding pieces
  we attack twice).  My next test after this is (hopefully) merged will be
  to intersect the Bitboard I define here with the enemy's queen attacks and
  attempt to give additional bonus.
- Perhaps we should exclude pieces attacked by pawns--can pawns really be
  overloaded? Should they have the same weight, or less?  This didn't work
  with a previous version, but it could work with this one.
- More generally, different pieces may need more or less bonus. We could
  change bonuses based on what type of enemy piece is being overloaded, what
  type of friendly piece is attacking, and/or what type of piece is being
  defended by the overloaded piece and attacked by us, or any intersection
  of these three.  For example, here attacked/defended pawns are excluded,
  but they're not totally worthless targets, and could be added again with
  a smaller bonus.
- This list is by no means exhaustive.

STC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 17439 W: 3599 L: 3390 D: 10450
http://tests.stockfishchess.org/tests/view/5ac78a2e0ebc59435923735e

LTC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 43304 W: 6533 L: 6256 D: 30515
http://tests.stockfishchess.org/tests/view/5ac7a1d80ebc59435923736f

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

Bench: 5248871

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

This is my first time opening a PR, so I apologize if there are errors.
There are too many people to thank since I submitted my first test just
over a month ago. Thank you all for the warm welcome and here is to more
green patches!

In particular, I would like to thank:
- @crossbr, whose comment in a FishCooking thread first inspired me to
            consider the overloading of pieces other than queens,
- @snicolet, whose queen overload tests inspired this one and served as
             the base of my first overload attempts,
- @protonspring, whose connectivity tests inspired this one and who provided
                 much of the feedback needed to take this from red to green,
- @vondele, who kindly corrected me when I submitted a bad LTC test,
- @Rocky640, who has helped me over and over again in the past month.

Thank you all!

20 months agoRemove the Queen from the mobility area of minor pieces
Alain SAVARD [Tue, 3 Apr 2018 21:55:52 +0000 (23:55 +0200)]
Remove the Queen from the mobility area of minor pieces

In master, we already remove the King from the mobility area of minor pieces
because the King simply stands in the way of other pieces, and since opponent
cannot capture the King, any piece which "protects" the King cannot recapture.

Similarly, this patch introduces the idea that it is rarely a need for a Queen
to be "protected" by a minor (unless it is attacked only by a Queen, in fact).
We used to have a LoosePiece bonus, and in a similar vein the Queen was excluded
from that penalty.

Idea came when reviewing an old game of Kholmov. He was a very good midgame
player, but in the opening his misplace his Queen (and won in the end :-) :
     http://www.chessgames.com/perl/chessgame?gid=1134645

Both white queen moves 10.Qd3 and 13.Qb3 are in the way of some minor piece.
I would prefer to not give a bishop mobility bonus at move 10 for the square d3,
or later a knight mobility bonus at move 13 for the square b3. And the textbook
move is 19.Qe3! which prepares 20.Nb3. This short game sample shows how much a
queen can be "in the way" of minor pieces.

STC
http://tests.stockfishchess.org/tests/view/5ac2c15f0ebc591746423fa3
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 22066 W: 4561 L: 4330 D: 13175

LTC
http://tests.stockfishchess.org/tests/view/5ac2d6500ebc591746423faf
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 25871 W: 3953 L: 3738 D: 18180

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

Ideas for future work in this area:

• tweak some more mobility areas for other piece type.
• construct a notion of global mobility for the whole piece set.
• bad bishops.

Bench: 4989125

20 months agoSimplify ThreatBySafePawn evaluation
Torsten Franz [Tue, 3 Apr 2018 21:33:55 +0000 (23:33 +0200)]
Simplify ThreatBySafePawn evaluation

Simplify ThreatBySafePawn evaluation by removing the 'if (weak)' speed
optimization check from threats evaluation. This is a non functional
change as it removes just a speed optimization conditional which was
probably useful before but does no longer provide benefits. This section
section had a few more lines not long ago, with ThreatByHangingPawn and
a loop through the threatened pieces, but now there is not much left.

Passed STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 47775 W: 9696 L: 9624 D: 28455
http://tests.stockfishchess.org/tests/view/5ac298910ebc591746423f8b

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

Non functional change.

20 months agoSimplify Singular Extension condition
Joost VandeVondele [Mon, 2 Apr 2018 22:13:35 +0000 (00:13 +0200)]
Simplify Singular Extension condition

Avoid defining a singly used variable, removes one condition.

passed STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 53489 W: 10814 L: 10752 D: 31923
http://tests.stockfishchess.org/tests/view/5ac08a8d0ebc590e9457cd94

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

No functional change.

20 months agoDocument Elo impact of various parts of search
Joost VandeVondele [Sun, 1 Apr 2018 01:13:29 +0000 (03:13 +0200)]
Document Elo impact of various parts of search

In order to understand better the impact of various techniques used in search,
Elo estimates have been run at STC for 60000 games (statistical error ~1.8 Elo),
disabling each feature in turn. This should help future improvements and
simplifications to pick suitable targets.

The list of tests is:
step  7 : http://tests.stockfishchess.org/tests/view/5abcbb4b0ebc5902926cf1ca
step  8 : http://tests.stockfishchess.org/tests/view/5abcbb680ebc5902926cf1cc
step  9 : http://tests.stockfishchess.org/tests/view/5abcbb850ebc5902926cf1ce
step 10 : http://tests.stockfishchess.org/tests/view/5abcbbeb0ebc5902926cf1d2
step 11 : http://tests.stockfishchess.org/tests/view/5abcbbbf0ebc5902926cf1d0
step 13 : http://tests.stockfishchess.org/tests/view/5abd03680ebc5902926cf20b
step 13a: http://tests.stockfishchess.org/tests/view/5abd29660ebc5902926cf22a
step 13b: http://tests.stockfishchess.org/tests/view/5abd29820ebc5902926cf22c
step 14 : http://tests.stockfishchess.org/tests/view/5abd03860ebc5902926cf20f
step 14a: http://tests.stockfishchess.org/tests/view/5abd2b6c0ebc5902926cf230
step 14b: http://tests.stockfishchess.org/tests/view/5abd2b8d0ebc5902926cf232
step 14c: http://tests.stockfishchess.org/tests/view/5abd2bad0ebc5902926cf234
step 14d: http://tests.stockfishchess.org/tests/view/5abd2bcf0ebc5902926cf236
step 14e: http://tests.stockfishchess.org/tests/view/5abd2bf10ebc5902926cf238

This patch documents this in the code.

Note that it will be a waste to recompute these estimates often, even a couple
of [0,5] patches are unlikely to change them by more than the error bars. The
interest of the Elo annotations in the code is not in the details, but in high-
lighting trends such as razoring (2 Elo) and singular extensions (60 Elo). These
estimates should be recomputed at most once a year.

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

No functional change.

20 months agoSome small changes
mstembera [Sun, 1 Apr 2018 00:32:17 +0000 (02:32 +0200)]
Some small changes

1) Use make_bitboard() in Bitboards::init()

2) Fix MSVC warning: search.h(85): warning C4244: '=': conversion from
   'TimePoint' to 'int', possible loss of data.

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

No functional change.

20 months agoSimplify KBPKB endgame with opposite bishops
Stéphane Nicolet [Sun, 1 Apr 2018 00:00:57 +0000 (02:00 +0200)]
Simplify KBPKB endgame with opposite bishops

When we reach a position with only two opposite colored bishops and
one pawn on the board, current master would give it a scale factor
of 9/64=0.14 in about one position out of 7200, and a scale factor
of 0.0 in the 7199 others. The patch gives a scale factor of 0.0 in
100% of the cases.

STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 55845 W: 11467 L: 11410 D: 32968
http://tests.stockfishchess.org/tests/view/5abc585f0ebc5902926cf15e

LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 11915 W: 1852 L: 1719 D: 8344
http://tests.stockfishchess.org/tests/view/5abc7f750ebc5902926cf18c

We also have exhaustive coverage analysis of this patch effect by
Alain Savard, comparing the perfect evaluation given by the Syzygy
tablebase with the heuristic play after this patch for the set of
all legal positions of the KBPKP endgame with opposite bishops, in
the comments thread for this pull request:
https://github.com/official-stockfish/Stockfish/pull/1520

Alain's conclusion:
> According to this definition and the data, I consider this PR is
> identical to master to "solve for draw" and slightly better than
> master to solve earlier for "wins".

Note: this patch is a side effect of an ongoing effort to improve
the evaluation of positions involving a pair of opposite bishops.
See the GitHub diff of this LTC test which almost passed at sprt[0..5]
for a discussion:
http://tests.stockfishchess.org/tests/view/5ab9030b0ebc5902932cbf93

No functional change (at small bench depths)

20 months agoRefine SEE threshold for capture pruning.
Joost VandeVondele [Sat, 31 Mar 2018 21:10:24 +0000 (23:10 +0200)]
Refine SEE threshold for capture pruning.

eloDoc suggests that this part of search is worth ~18 Elo.
This patch refines the depth dependence of the SEE threshold.

passed STC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 21398 W: 4474 L: 4245 D: 12679
http://tests.stockfishchess.org/tests/view/5abfb0630ebc591a560aae07

passed LTC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 9028 W: 1439 L: 1285 D: 6304
http://tests.stockfishchess.org/tests/view/5abfbff30ebc591a560aae11

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

Bench: 6036915

20 months agoCandidate Passed Pawn
Alain SAVARD [Thu, 29 Mar 2018 11:59:35 +0000 (07:59 -0400)]
Candidate Passed Pawn

Include some not fully supported levers in the (candidate) passed pawns
bitboard, if otherwise unblocked. Maybe levers are usually very short
lived, and some inaccuracy in the lever balance for the definition of
candidate passed pawns just triggers a deeper search.

Here is a example of a case where the patch has an effect on the definition
of candidate passers: White c5/e5 pawns, against Black d6 pawn. Let's say
we want to test if e5 is a candidate passer. The previous master looks
only at files d, e and f (which is already very good) and reject e5 as
a candidate. However, the lever d6 is challenged by 2 pawns, so it should
not fully count. Indirectly, this patch will view such case (and a few more)
to be scored as candidates.

STC
http://tests.stockfishchess.org/tests/view/5abcd55d0ebc5902926cf1e1
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 16492 W: 3419 L: 3198 D: 9875

LTC
http://tests.stockfishchess.org/tests/view/5abce1360ebc5902926cf1e6
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 21156 W: 3201 L: 2990 D: 14965

This was inspired by this test of Jerry Donald Watson, except the case of
zero supporting pawns against two levers is excluded, and it seems that
not excluding that case is bad, while excluding is it beneficial. See the
following tests on fishtest:

https://github.com/official-stockfish/Stockfish/pull/1519
http://tests.stockfishchess.org/tests/view/5abccd850ebc5902926cf1dd
http://tests.stockfishchess.org/tests/view/5abcdd490ebc5902926cf1e4

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

Bench: 5568461

----

Comments by Jerry Donald Watson:

> My thinking as to why this works:
>
> The evaluation is either called in an interior node or in the qsearch.
> The calls at the end of the qsearch are the more important as they
> ultimately determine the scoring of each move, whereas the internal
> values are mainly used for pruning decisions with a margin. Some strong
> engines don't even call the eval at all nodes. Now the whole point of
> the qsearch is to find quiet positions where captures do not change the
> evaluation of the position with regards to the search bounds - i.e. if
> there were good captures they would be tried.* So when a candidate lever
> appears in the evaluation at the end of the qsearch, the qsearch has
> guaranteed that it cannot just be captured, or if it can, this does not
> take the score past the search bounds. Practically this may mean that
> the side with the candidate lever has the turn, or perhaps the stopping
> lever pawn is pinned, or that side is forced for other reasons to make
> some other move (e.g. d6 can only take one of the pawns in the example
> above).
>
> Hence granting the full score for only one lever defender makes some
> sense, at least, to me.
>
> IMO this is also why huge bonuses for possible captures in the evaluation
> (e.g. threat on queen and our turn), etc. don't tend to work. Such things
> are best left to the search to figure out.

20 months 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
effects:

 * 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
http://tests.stockfishchess.org/tests/view/5aa93a5a0ebc5902952892e6

5+0.05, Threads=8:
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 27164 W: 4974 L: 4983 D: 17207
http://tests.stockfishchess.org/tests/view/5ab2639b0ebc5902a6fbefd5

5+0.5, Threads=16:
LLR: -2.97 (-2.94,2.94) [0.00,5.00]
Total: 41396 W: 7127 L: 7082 D: 27187
http://tests.stockfishchess.org/tests/view/5ab124220ebc59029516cb62

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
http://tests.stockfishchess.org/tests/view/5ab4b6580ebc5902932aeca2

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
http://tests.stockfishchess.org/tests/view/5ab4e8500ebc5902932aecb3

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
http://tests.stockfishchess.org/tests/view/5ab636450ebc590295d88536

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
http://tests.stockfishchess.org/tests/view/5ab62e680ebc590295d88524

---
***FAQ***

**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.

---

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

No functional change -- in single thread mode.

20 months 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.

Closes https://github.com/official-stockfish/Stockfish/pull/1518
and    https://github.com/official-stockfish/Stockfish/pull/1490

No functional change.

20 months 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.

STC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 35908 W: 7382 L: 7087 D: 21439
http://tests.stockfishchess.org/tests/view/5aba723a0ebc5902a4743e8f

LTC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 23087 W: 3584 L: 3378 D: 16125
http://tests.stockfishchess.org/tests/view/5aba89070ebc5902a4743ea9

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

20 months 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]:

LTC:
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 20651 W: 3191 L: 2980 D: 14480
http://tests.stockfishchess.org/tests/view/5ab73faa0ebc5902932cbdca

LTC:
LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 89111 W: 13647 L: 13233 D: 62231
http://tests.stockfishchess.org/tests/view/5ab8c0e50ebc5902932cbeae

See https://github.com/official-stockfish/Stockfish/pull/1511
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

20 months 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
compromise.

STC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 36597 W: 7522 L: 7429 D: 21646
http://tests.stockfishchess.org/tests/view/5ab935f30ebc5902932cc016

LTC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 100690 W: 15373 L: 15372 D: 69945
http://tests.stockfishchess.org/tests/view/5ab9501f0ebc5902932cc042

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

Bench: 5980822

20 months 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
http://tests.stockfishchess.org/tests/view/5aaa47cb0ebc590297330403

LTC (MultiPV=3):
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 2390 W: 874 L: 706 D: 810
http://tests.stockfishchess.org/tests/view/5aaa593a0ebc59029733040b

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
http://tests.stockfishchess.org/tests/view/5aaf983e0ebc5902a182131f

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
http://tests.stockfishchess.org/tests/view/5aabccee0ebc5902997ff006

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 https://github.com/official-stockfish/Stockfish/pull/1491 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

20 months 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:

        https://gist.github.com/WOnder93/b5fcf9c989b4a1715684d5c82367cdbe

   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' ./check_benches.sh 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 :)

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

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

No functional change.

20 months 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

20 months 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:          https://github.com/official-stockfish/Stockfish/issues/1498
Closes pull request:  https://github.com/official-stockfish/Stockfish/pull/1510

No functional change.

20 months 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.

STC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 34000 W: 7167 L: 6877 D: 19956
http://tests.stockfishchess.org/tests/view/5ab8216d0ebc5902932cbe64

LTC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 22574 W: 3576 L: 3370 D: 15628
http://tests.stockfishchess.org/tests/view/5ab84e6a0ebc5902932cbe72

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.

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

Bench: 5934103

20 months 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
http://tests.stockfishchess.org/tests/view/5ab54a240ebc590295d8847d

Passed LTC:
LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 46665 W: 7187 L: 6898 D: 32580
http://tests.stockfishchess.org/tests/view/5ab5ba690ebc590295d884b4

Possible work in this area after this change:

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

Bench: 5851102

20 months 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
http://tests.stockfishchess.org/tests/view/5ab0aaf00ebc59029fb6f6c3

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

No functional change.

20 months 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.

20 months 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
http://tests.stockfishchess.org/tests/view/5a99b9df0ebc590297cc8f04

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

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

No functional change.

20 months 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
http://tests.stockfishchess.org/tests/view/5aae11450ebc590299abf52f

No functional change.

20 months 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.

21 months 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.

21 months 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:
https://github.com/official-stockfish/Stockfish/issues/1426

No functional change.

21 months 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
http://tests.stockfishchess.org/tests/view/5aa846190ebc59029781015b

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

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

No functional change.

21 months 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.

http://tests.stockfishchess.org/tests/view/5aa4f37c0ebc59029780ff2d
http://tests.stockfishchess.org/tests/view/5aa4f3080ebc59029780ff2b
http://tests.stockfishchess.org/tests/view/5aa5cbb50ebc59029780ffce
http://tests.stockfishchess.org/tests/view/5aa5cb730ebc59029780ffcc

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
http://tests.stockfishchess.org/tests/view/5aa7ba660ebc590297810116

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

No functional change.

21 months 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: https://github.com/official-stockfish/Stockfish/pull/1447
and:          https://github.com/official-stockfish/Stockfish/pull/1479

No functional change.

21 months 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"

STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 33895 W: 6995 L: 6897 D: 20003
http://tests.stockfishchess.org/tests/view/5aa6eaba0ebc59029781009d

LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 28959 W: 4441 L: 4333 D: 20185
http://tests.stockfishchess.org/tests/view/5aa73dfa0ebc5902978100be

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.

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

Bench: 5741807

21 months 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).

STC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 13480 W: 2840 L: 2648 D: 7992
http://tests.stockfishchess.org/tests/view/5aa693fe0ebc59029781004c

LTC:
LLR: 2.97 (-2.94,2.94) [0.00,5.00]
Total: 25895 W: 4099 L: 3880 D: 17916
http://tests.stockfishchess.org/tests/view/5aa6ac940ebc59029781006e

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

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

Bench: 5328254

21 months 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
http://tests.stockfishchess.org/tests/view/5aa598ed0ebc59029780ff9f

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
http://tests.stockfishchess.org/tests/view/5aa5b0f30ebc59029780ffa9

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

Bench: 5404567

21 months 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
http://tests.stockfishchess.org/tests/view/5aa6de1b0ebc590297810097

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

No functional change

21 months 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.

STC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 48770 W: 10203 L: 9845 D: 28722
http://tests.stockfishchess.org/tests/view/5aa58cce0ebc59029780ff8d

LTC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 22252 W: 3572 L: 3366 D: 15314
http://tests.stockfishchess.org/tests/view/5aa5b27c0ebc59029780ffad

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.

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

Bench: 5750110

21 months 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
http://tests.stockfishchess.org/tests/view/5aa003cf0ebc590297cb6276

LTC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 22320 W: 3470 L: 3352 D: 15498
http://tests.stockfishchess.org/tests/view/5aa051020ebc590297cb62ba

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

No functional change.

21 months 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).

STC
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 16175 W: 3386 L: 3165 D: 9624
http://tests.stockfishchess.org/tests/view/5aa48b150ebc59029780fef6

LTC
LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 98685 W: 15209 L: 14765 D: 68711
http://tests.stockfishchess.org/tests/view/5aa496f50ebc59029780fefa

Bench 5601228

21 months 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.

STC
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 12317 W: 2655 L: 2467 D: 7195
http://tests.stockfishchess.org/tests/view/5aa2d86b0ebc590297cb6474

LTC
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 35725 W: 5516 L: 5263 D: 24946
http://tests.stockfishchess.org/tests/view/5aa2fc6f0ebc590297cb64a8

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.

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

Bench: 5318575

21 months 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:
http://tests.stockfishchess.org/tests/view/5aa131560ebc590297cb636e

21 months 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.

STC:
http://tests.stockfishchess.org/tests/view/5aa1ddf10ebc590297cb63d8
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 22997 W: 4817 L: 4570 D: 13610

LTC:
http://tests.stockfishchess.org/tests/view/5aa1fe6b0ebc590297cb63e5
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.

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

bench: 5788691

21 months 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:

STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 42179 W: 8704 L: 8622 D: 24853
http://tests.stockfishchess.org/tests/view/5a9db6270ebc590297cb611b

LTC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 17737 W: 2702 L: 2577 D: 12458
http://tests.stockfishchess.org/tests/view/5a9eb5b20ebc590297cb61b2

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

Bench: 5544908

21 months 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.

STC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 15271 W: 3157 L: 2958 D: 9156
http://tests.stockfishchess.org/tests/view/5a9f2f8c0ebc590297cb6216

LTC:
LLR: 2.97 (-2.94,2.94) [0.00,5.00]
Total: 6617 W: 1053 L: 908 D: 4656
http://tests.stockfishchess.org/tests/view/5a9f98390ebc590297cb6241

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

21 months 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.

STC: http://tests.stockfishchess.org/tests/view/5a9e442e0ebc590297cb6162
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 35129 W: 7346 L: 7052 D: 20731

LTC: http://tests.stockfishchess.org/tests/view/5a9e6e620ebc590297cb617f
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

21 months 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
http://tests.stockfishchess.org/tests/view/5a8433360ebc590297cc80c5

passed LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 231799 W: 37647 L: 37858 D: 156294
http://tests.stockfishchess.org/tests/view/5a96a34a0ebc590297cc8cfd

No functional change.

21 months 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

21 months 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.

21 months 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

21 months 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
http://tests.stockfishchess.org/tests/view/5a8db9340ebc590297cc85b6

passed LTC:
LLR: 2.97 (-2.94,2.94) [0.00,5.00]
Total: 47491 W: 7825 L: 7517 D: 32149
http://tests.stockfishchess.org/tests/view/5a9456a80ebc590297cc8a89

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

21 months 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
http://tests.stockfishchess.org/tests/view/5a98544b0ebc590297cc8e35

passed LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 14552 W: 2404 L: 2274 D: 9874
http://tests.stockfishchess.org/tests/view/5a9947b20ebc590297cc8e93

Bench: 6361582

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

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

LTC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 20368 W: 3441 L: 3238 D: 13689
http://tests.stockfishchess.org/tests/view/5a98bea40ebc590297cc8e5d

Bench: 6361568

21 months 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.

21 months 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

21 months 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
improvement.

Passed STC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 32133 W: 7395 L: 7101 D: 17637
http://tests.stockfishchess.org/tests/view/5a93198b0ebc590297cc8942

Passed LTC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 17382 W: 3002 L: 2809 D: 11571
http://tests.stockfishchess.org/tests/view/5a93b18c0ebc590297cc89c2

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

STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 15553 W: 3505 L: 3371 D: 8677
http://tests.stockfishchess.org/tests/view/5a964be90ebc590297cc8cc4

LTC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 13253 W: 2270 L: 2137 D: 8846
http://tests.stockfishchess.org/tests/view/5a9658880ebc590297cc8cca

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

21 months 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
https://github.com/official-stockfish/Stockfish/pull/1434

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.

STC:
LLR: 2.94 (-2.94,2.94) [0.00,5.00]
Total: 16467 W: 3750 L: 3537 D: 9180
http://tests.stockfishchess.org/tests/view/5a92102d0ebc590297cc87d0

LTC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 64242 W: 11130 L: 10745 D: 42367
http://tests.stockfishchess.org/tests/view/5a923dc80ebc590297cc8806

This version includes reformatting and speed optimization by Alain Savard.

Bench: 5643527

21 months 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
parameters.

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
time.
• 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
http://tests.stockfishchess.org/tests/view/5a9291a40ebc590297cc8881

LTC (60+0.6):
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 72027 W: 12263 L: 11878 D: 47886
http://tests.stockfishchess.org/tests/view/5a92d7510ebc590297cc88ef

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
http://tests.stockfishchess.org/tests/view/5a9445850ebc590297cc8a65

40 moves repeating at LTC:
LLR: 2.95 (-2.94,2.94) [-4.00,0.00]
Total: 10309 W: 1880 L: 1759 D: 6670
http://tests.stockfishchess.org/tests/view/5a9566ec0ebc590297cc8be1

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.

21 months 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
http://tests.stockfishchess.org/tests/view/5a840bcc0ebc590297cc80b5

Passed LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 117728 W: 19875 L: 19911 D: 77942
http://tests.stockfishchess.org/tests/view/5a8444800ebc590297cc80ca

No functional change.

21 months 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:

STC:
LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 23676 W: 5417 L: 5157 D: 13102
http://tests.stockfishchess.org/tests/view/5a9423a90ebc590297cc8a46

LTC:
LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 35485 W: 6168 L: 5898 D: 23419
http://tests.stockfishchess.org/tests/view/5a9435550ebc590297cc8a54

Bench: 5643520

21 months 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.

STC:
LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 22683 W: 5202 L: 4946 D: 12535
http://tests.stockfishchess.org/tests/view/5a93315f0ebc590297cc894f

LTC:
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 48548 W: 8346 L: 8035 D: 32167
http://tests.stockfishchess.org/tests/view/5a933ba90ebc590297cc8962

Bench: 5833683

21 months 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.

STC:
LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 52602 W: 11776 L: 11403 D: 29423
http://tests.stockfishchess.org/tests/view/5a8cb8f60ebc590297cc8546

LTC:
LLR: 2.97 (-2.94,2.94) [0.00,4.00]
Total: 156613 W: 26820 L: 26158 D: 103635
http://tests.stockfishchess.org/tests/view/5a8f452d0ebc590297cc865a

Bench: 4924749

21 months 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.

21 months 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.

21 months 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.

STC:
LLR: 4.73 (-2.94,2.94) [0.00,5.00]
Total: 36281 W: 8221 L: 7830 D: 20230
http://tests.stockfishchess.org/tests/view/5a921cb90ebc590297cc87f6

LTC:
LLR: 2.97 (-2.94,2.94) [0.00,5.00]
Total: 22907 W: 3954 L: 3738 D: 15215
http://tests.stockfishchess.org/tests/view/5a92672b0ebc590297cc8814

Happy to see something from Ethereal work for Stockfish :)

Bench: 5882274