Merge remote-tracking branch 'upstream/master'

Refactor final stats updates.

This PR refactors update_quiet_stats, update_capture_stats and search to more clearly reflect what is actually done.

Effectively, all stat updates that need to be done after search is finished and a bestmove is found,
are collected in a new function ```final_stats_update()```. This shortens our main search routine, and simplifies ```update_quiet_stats```.
The latter function is now more easily reusable with fewer arguments, as the handling of ```quietsSearched``` is only needed in ```final_stats_update```.
```update_capture_stats```, which was only called once is now integrated in ```final_stats_update```, which allows for removing a branch and reusing some ```stat_bonus``` calls. The need for refactoring was also suggested by the fact that the comments of ```update_quiet_stats``` and ```update_capture_stats``` were incorrect (e.g. ```update_capture_stats``` was called, correctly, also when the bestmove was a quiet and not a capture).

passed non-regression STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 75196 W: 16364 L: 16347 D: 42485
http://tests.stockfishchess.org/tests/view/5db004ec0ebc5902c06db9e1

The diff is most easily readable as ```git diff master --patience```

No functional change

Assorted trivial cleanups

- Cleanups by Alain
- Group king attacks and king defenses
- Signature of futility_move_count()
- Use is_discovery_check_on_king()
- Simplify backward definition
- Use static asserts in move generator
- Factor a statement in move generator

No functional change

Simplify reductions on singular extension

Current master employs a scheme to adjust reductions on singular
nodes that is somewhat controversial, see
https://github.com/official-stockfish/Stockfish/pull/2167

This patch removes this use of a search result outside of [a,b],
by observing that the main effect of this code is to adjust the
reduction by an average of ~2 (1.7) rather than 1.

Claims the first blue at STC and LTC:

STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 30142 W: 6547 L: 6442 D: 17153
http://tests.stockfishchess.org/tests/view/5daf16c40ebc5902c06da566

LTC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 45715 W: 7380 L: 7298 D: 31037
http://tests.stockfishchess.org/tests/view/5daf2f3c0ebc5902c06da6c7

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

Bench: 5115841

Avoid crashing on Log File opening

Stockfish crashes immediately if users enter a wrong file name (or even an existing
folder name) for debug log file. It may be hard for users to find out since it prints
nothing. If they enter the string via a chess GUI, the chess GUI may remember and
auto-send to Stockfish next time, makes Stockfish crashes all the time. Bug report by
Nguyen Hong Pham in this issue: https://github.com/official-stockfish/Stockfish/issues/2365

This patch avoids the crash and instead prefers to exit gracefully with a error
message on std:cerr, like we do with the fenFile for instance.

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

No functional change.

Remove uithread

With the current questions and issues around threading, I had a look at
https://github.com/official-stockfish/Stockfish/issues/2299.

It seems there was a problem with data races when requesting eval via UCI while
a search was already running. To fix this an extra thread uithread was created,
presumably to avoid an overlap with Threads.main() that was causing problems.
Making this eval request seems to be outside the scope of UCI, and @vondele also
reports that the data race is not even fixed reliably by this change. I suggest
we simplify the threading here by removing this uithread and adding a comment
signaling that user should not request eval when a search is already running.

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

No functional change.

Current capture for Counter-Move history

Use current capture to index the CMH table instead of prior capture.

STC:
LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 61908 W: 13626 L: 13220 D: 35062
http://tests.stockfishchess.org/tests/view/5da8aa670ebc597ba8eda558

LTC:
LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 49057 W: 8071 L: 7765 D: 33221
http://tests.stockfishchess.org/tests/view/5da8e99d0ebc597ba8eda9ca

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

Bench: 4423737

Add four positions to bench

The current bench is missing a position with high 50 moves rule counter,
making most 'shuffle' tests based on 50mr > N seem non-functional.
This patch adds one FEN with high 50mr counter to address this issue
(taken from a recent tcec game).

Four new FENs:
- position with high 50mr counter
- tactical position with many captures, checks, extensions, fails high/low
- two losses by Stockfish in the S16 bonus games against Houdini

See the pull request for nice comments by @Alayan-stk-2 about each position
in bench: https://github.com/official-stockfish/Stockfish/pull/2338

Bench: 4590210

Introduce separate counter-move tables for inCheck

Enhance counter-move history table by adding a inCheck dimension. This doubles
the size of the table but provides more accurate move ordering.

STC: (yellow)
LLR: -2.94 (-2.94,2.94) [0.50,4.50]
Total: 36217 W: 7790 L: 7777 D: 20650
http://tests.stockfishchess.org/tests/view/5d9b9a290ebc5902b6d04fe0

LTC:
LLR: 2.95 (-2.94,2.94) [0.00,3.50]
Total: 36665 W: 6063 L: 5788 D: 24814
http://tests.stockfishchess.org/tests/view/5d9b9fcc0ebc5902b6d05985

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

Bench: 4053577

No reachable outpost bonus for bishops

Previously, we used various control statements and ternary operators to divide
Outpost into four bonuses, based on whether the outpost was for a knight or
bishop, and whether it was currently an Outpost or merely a potential ("reachable")
one in the future. Bishop outposts, however, have traditionally been worth far
less Elo in testing. An attempt to remove them altogether passed STC, but failed LTC.

Here we include a narrower simplification, removing the reachable Outpost bonus
for bishops. This bonus was always suspect, given that its current implementation
conflicts directly with BishopPawns. BishopPawns penalizes our bishops based on the
number of friendly pawns on the same color of square, but by definition, Outposts
must be pawn-protected! This PR helps to alleviate this conceptual contradiction
without loss of Elo and with slightly simpler code.

On a code level, this allows us to simplify a ternary operator into the previous
"if" block and distribute a multiplication into an existing constant Score. On a
conceptual level, we retire one of the four traditional Outpost bonuses.

STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 22277 W: 4882 L: 4762 D: 12633
http://tests.stockfishchess.org/tests/view/5d9aeed60ebc5902b6cf9751

LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 51206 W: 8353 L: 8280 D: 34573
http://tests.stockfishchess.org/tests/view/5d9af1940ebc5902b6cf9cd5

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

Bench: 3941591

Adjust aspiration window with eval

This patch changes the base aspiration window size depending on the absolute
value of the previous iteration score, increasing it away from zero. This
stems from the observation that the further away from zero, the more likely
the  evaluation is to change significantly with more depth. Conversely, a
tighter aspiration window is more efficient when close to zero.

A beneficial side-effect is that analysis of won positions without a quick
mate is less prone to waste nodes in repeated fail-high that change the eval
by tiny steps.

STC:
LLR: 2.96 (-2.94,2.94) [0.50,4.50]
Total: 60102 W: 13327 L: 12868 D: 33907
http://tests.stockfishchess.org/tests/view/5d9a70d40ebc5902b6cf39ba

LTC:
LLR: 2.95 (-2.94,2.94) [0.00,3.50]
Total: 155553 W: 25745 L: 25141 D: 104667
http://tests.stockfishchess.org/tests/view/5d9a7ca30ebc5902b6cf4028

Future work : the values used in this patch were only a reasonable guess.
Further testing should unveil more optimal values. However, the aspiration
window is rather tight with a minimum of 21 internal units, so discrete
integers put a practical limitation to such tweaking.

More exotic experiments around the aspiration window parameters could also
be tried, but efficient conditions to adjust the base aspiration window size
or allow it to not be centered on the current evaluation are not obvious.

The aspiration window increases after a fail-high or a fail-low is another
avenue to explore for potential enhancements.

Bench: 4043748

Tweak kingFlankAttacks factor in kingDanger

Increase kingFlankAttacks factor in kingDanger from 5/16 to 6/16.

Failed STC:
LLR: -2.96 (-2.94,2.94) [0.00,4.00]
Total: 77947 W: 16989 L: 16848 D: 44110
http://tests.stockfishchess.org/tests/view/5d9ac0280ebc5902b6cf63cd

Passed LTC 1:
LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 13443 W: 2231 L: 2037 D: 9175
http://tests.stockfishchess.org/tests/view/5d9ac88d0ebc5902b6cf6ffb

Passed LTC 2:
LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 23340 W: 3842 L: 3617 D: 15881
http://tests.stockfishchess.org/tests/view/5d9acf7f0ebc5902b6cf7c27

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

Bench: 4042155

Adjust pawn span

Run as a simplification

a) insures that pawn attacks are always included in the pawn span
  (this "fixes" the case where some outpost or reachable outpost
  bonus were awarded on squares controlled by enemy pawns).

b) compute the full span only if not "backward" or not "blocked".

By looking at "blocked" instead of "opposed", we get a nice simpli-
fication and the "new" outpost detection is almost identical, except
a few borderline cases on rank 4.

passed STC
http://tests.stockfishchess.org/tests/view/5d9950730ebc5902b6cefb90
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 79113 W: 17168 L: 17159 D: 44786

passed LTC
http://tests.stockfishchess.org/tests/view/5d99d14e0ebc5902b6cf0692
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 41286 W: 6819 L: 6731 D: 27736

See https://github.com/official-stockfish/Stockfish/pull/2348

bench: 3812891

Make priorCapture a bool

It is always used as a bool, so let's make it a bool straight away.
We can always redefine it as a Piece in a later patch if we want
to use the piece type or the piece color.

No functional change.

Introduce separate counter-move tables for captures

Enhance counter-move history table by adding a capture/no-capture dimension,
depending wether the previous move was a quiet move or a capture. This doubles
the size of the table but provides more accurate move ordering.

STC:
LLR: 2.95 (-2.94,2.94) [0.50,4.50]
Total: 79702 W: 17720 L: 17164 D: 44818
http://tests.stockfishchess.org/tests/view/5d97945e0ebc590c21aa724b

LTC:
LLR: 2.96 (-2.94,2.94) [0.00,3.50]
Total: 29147 W: 4907 L: 4651 D: 19589
http://tests.stockfishchess.org/tests/view/5d97ccb90ebc590c21aa7bc0

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

Bench: 4131643

Eliminate ONE_PLY

Simplification that eliminates ONE_PLY, based on a suggestion in the forum that
support for fractional plies has never been used, and @mcostalba's openness to
the idea of eliminating it. We lose a little bit of type safety by making Depth
an integer, but in return we simplify the code in search.cpp quite significantly.

No functional change

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

The argument favoring eliminating ONE_PLY:

* The term “ONE_PLY” comes up in a lot of forum posts (474 to date)
https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:relevance

* There is occasionally a commit that breaks invariance of the code
with respect to ONE_PLY
https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ONE_PLY%7Csort:date/fishcooking/ZIPdYj6k0fk/KdNGcPWeBgAJ

* To prevent such commits, there is a Travis CI hack that doubles ONE_PLY
and rechecks bench

* Sustaining ONE_PLY has, alas, not resulted in any improvements to the
  engine, despite many individuals testing many experiments over 5 years.

The strongest argument in favor of preserving ONE_PLY comes from @locutus:
“If we use par example ONE_PLY=256 the parameter space is increases by the
factor 256. So it seems very unlikely that the optimal setting is in the
subspace of ONE_PLY=1.”

There is a strong theoretical impediment to fractional depth systems: the
transposition table uses depth to determine when a stored result is good
enough to supply an answer for a current search. If you have fractional
depths, then different pathways to the position can be at fractionally
different depths.

In the end, there are three separate times when a proposal to remove ONE_PLY
was defeated by the suggestion to “give it a few more months.” So… it seems
like time to remove this distraction from the community.

See the pull request here:
https://github.com/official-stockfish/Stockfish/pull/2289

Fix compare function in previous patch

Bench: 4012371

Remove temporary shelter array

Remove temporary array of shelters and avoid iterating over it each time to find
if the shelter values after castling are better than the current value.
Work done on top of https://github.com/official-stockfish/Stockfish/pull/2277

Speed benchmark did not measure any difference.

No functional change

More accurate pawn attack span definition

Tweak the pawn attack span for backward pawns and the zone behind
opponent opposing pawns. This is important in positional play and
one of weaknesses of the engine in recent high level games.

STC
LLR: -2.95 (-2.94,2.94) [0.50,4.50]
Total: 66843 W: 14884 L: 14717 D: 37242
http://tests.stockfishchess.org/tests/view/5d8dcb1b0ebc590f3beb2956

LTC
LLR: 2.96 (-2.94,2.94) [0.00,3.50]
Total: 77699 W: 12993 L: 12602 D: 52104
http://tests.stockfishchess.org/tests/view/5d8de9bc0ebc590f3beb3d00

See discussion in https://github.com/official-stockfish/Stockfish/pull/2332

Bench: 4012371

Adjust reductions based on the number of threads

In lazySMP it makes sense to prune a little more, as multiple threads
search wider. We thus increase the prefactor of the reductions slowly
as a function of the threads. The prefactor of the log(threads) term
is a parameter, this pull request uses 1/2 after testing.

passed STC @ 8threads:
LLR: 2.96 (-2.94,2.94) [0.50,4.50]
Total: 118125 W: 23151 L: 22462 D: 72512
http://tests.stockfishchess.org/tests/view/5d8bbf4d0ebc59509180f217

passed LTC @ 8threads:
LLR: 2.95 (-2.94,2.94) [0.00,3.50]
Total: 67546 W: 10630 L: 10279 D: 46637
http://tests.stockfishchess.org/tests/view/5d8c463b0ebc5950918167e8

passed ~LTC @ 14threads:
LLR: 2.95 (-2.94,2.94) [0.00,3.50]
Total: 74271 W: 12421 L: 12040 D: 49810
http://tests.stockfishchess.org/tests/view/5d8db1f50ebc590f3beb24ef

Note:
A larger prefactor (1) passed similar tests at STC and LTC (8 threads),
while a very large one (2) passed STC quickly but failed LTC (8 threads).

For the single-threaded case there is no functional change.

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

Bench: 4088701

Fixup: remove redundant code.

Remove ThreatByRank

This is a functional simplification that removes ThreatByRank.

STC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 48009 W: 10630 L: 10560 D: 26819
http://tests.stockfishchess.org/tests/view/5d92095c0ebc594fb88eb61e

LTC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 18682 W: 3177 L: 3053 D: 12452
http://tests.stockfishchess.org/tests/view/5d9231120ebc594fb88ebacd

Moving forward, it's possible that ThreatByMinor and ThreatByRook
could be combined, but I haven't really contemplated that yet.

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

bench 4088701

Remove depth dependence in value_draw().

The condition "depth >= 4 * ONE_PLY" does not seem needed at this point.

passed STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 32751 W: 7178 L: 7078 D: 18495
http://tests.stockfishchess.org/tests/view/5d8e46660ebc590f3bebad5e

passed LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 31693 W: 5299 L: 5196 D: 21198
http://tests.stockfishchess.org/tests/view/5d8e4b4f0ebc590f3bebb165

Bench: 4062526

Extend castling independently of singular extension

A curious feature of Stockfish's current extension code is its repeated
use of "else if." In most cases, this makes no functional difference,
because no more than one extension is applied; once one extension has
been applied, the remaining ones can be safely ignored.

However, if most singular extension search conditions are true, except
"value < singularBeta", no non-singular extensions (e.g., castling) can
be performed!

Three tests were submitted, for three of Stockfish's four non-singular
extensions. I excluded the shuffle extension, because historically there
have been concerns about the fragility of its conditions, and I did not
want to risk causing any serious search problems.

- Modifying the passed pawn extension appeared roughly neutral at STC. At
best, it appeared to be an improvement of less than 1 Elo.
- Modifying check extension performed very poorly at STC
- Modifying castling extension (this patch) produced a long "yellow" run
 at STC (insufficient to pass, but positive score) and a strong LTC.

In simple terms, prior to this patch castling extension was occasionally
not applied during search--on castling moves. The effect of this patch is
to perform castling extension on more castling moves. It does so without
adding any code complexity, simply by replacing an "else if" with "if" and
reordering some existing code.

STC:
LLR: -2.96 (-2.94,2.94) [0.00,4.00]
Total: 108114 W: 23877 L: 23615 D: 60622
http://tests.stockfishchess.org/tests/view/5d8d86bd0ebc590f3beb0c88

LTC:
LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 20862 W: 3517 L: 3298 D: 14047
http://tests.stockfishchess.org/tests/view/5d8d99cd0ebc590f3beb1899

Bench: 3728191

--------

Where do we go from here?

- It seems strange to me that check extension performed so poorly -- clearly
some of the singular extension conditions are also very important for check
extension. I am not an expert in search, and I do not have any intuition
about which of the eight conditions is/are the culprit. I will try a
succession of eight STC tests to identify the relevant conditions, then try
to replicate this PR for check extension.

- Recent tests interacting with the castle extension may deserve retesting.
I will shortly resubmit a few of my recent castling extension tweaks, rebased
on this PR/commit.

My deepest thanks to @noobpwnftw for the extraordinary CPU donation, and to
all our other fishtest volunteers, who made it possible for a speculative LTC
to pass in 70 minutes!

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

Simplify RookOnPawn

Remove the RookOnPawn logic (for rook on rank 5 and above aligning with pawns
on same row or file) which was overlapping with a few other parameters.

Inspired by @31m059 interesting result hinting that a direct attack on pawns
instead of PseudoAttacks might work.
http://tests.stockfishchess.org/tests/view/5d89a7c70ebc595091801b8d

After a few attempts by me and @31m059, and some long STC greens but red LTC,
as a proof of concept I first tried a local SPSA at VSTC trying to tune related
rook psqt rows, and mainly some rook related stuff in evaluate.cpp.
Result was STC green, but still red LTC,

Finally a 100M fishtest SPSA at LTC proved successful both at STC and LTC.

All this was possible with the awesome fishtest contributors.
At some point, I had 850 workers on the last test !

Run as a simplification

STC
http://tests.stockfishchess.org/tests/view/5d8d68f40ebc590f3beaf171
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 7399 W: 1693 L: 1543 D: 4163

LTC
http://tests.stockfishchess.org/tests/view/5d8d70270ebc590f3beaf63c
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 41617 W: 6981 L: 6894 D: 27742

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

bench: 4037914

Remove custom mutex implementation

As part of the investigation of the hang caused by an incorrect implementation
of condition_variable in libwinpthread, it was realized that our custom Mutex
implementation is no longer needed. Prior to lazySMP this custom implementation
resulted in a 30% speedup, but now no speed difference can be measured as no
mutex is used on the hot path in lazySMP.

https://github.com/official-stockfish/Stockfish/issues/2291
https://github.com/official-stockfish/Stockfish/issues/2309#issuecomment-533733393  https://github.com/official-stockfish/Stockfish/issues/2309#issuecomment-533737515

The interest of this patch is that it removes platform-specific code, which is
always less tested.

No functional change.

Restore development version (revert previous commit)

Revert the previous patch now that the binary for the super-final
of TCEC season 16 has been sent.

Maybe the feature of showing the name of compiler will be added to the
master branch in the future. But we may use a cleaner way to code it, see
some ideas using the Makefile approach at the end of pull request #2327 :
https://github.com/official-stockfish/Stockfish/pull/2327

Bench: 3618154

Temporary patch to show the compiler for TCEC submission

This patch shows a description of the compiler used to compile Stockfish,
when starting from the console.

Usage:

```
./stockfish
compiler
```

Example of output:

```
Stockfish 240919 64 POPCNT by T. Romstad, M. Costalba, J. Kiiski, G. Linscott

Compiled by clang++ 9.0.0 on Apple
 __VERSION__ macro expands to: 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.38)
```

No functional change

Increase weight for supported pawns

This patch changes the weight for counting supports of pawns
from 17 to 21. Hopefully Stockfish will accept to play a bit
more of closed or semi-closed positions.

STC:
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 13822 W: 3158 L: 2939 D: 7725
http://tests.stockfishchess.org/tests/view/5d89c3a10ebc595091802379

LTC:
LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 63066 W: 10590 L: 10236 D: 42240
http://tests.stockfishchess.org/tests/view/5d89ca7f0ebc595091802680

Future work: try to tweak the evaluation to better understand
the French structures.

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

Bench: 3618154

Clarify the mapping of files to queenside

This patch replaces the obscure expressions mapping files ABCDEFGH to ABCDDCBA
by explicite calls to an auxiliary function:

  old:   f = min(f, ~f)
  new:   f = map_to_queenside(f)

We used the Golbolt web site (https://godbolt.org) to check that the current
code for the auxiliary function is optimal.

STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 30292 W: 6756 L: 6651 D: 16885
http://tests.stockfishchess.org/tests/view/5d8676720ebc5971531d6aa1

Achieved with a bit of help from Sopel97, snicolet and vondele, thanks everyone!
Closes https://github.com/official-stockfish/Stockfish/pull/2325

No functional change

Encourage rook lift to third rank

This change to the Rook psqt encourages rook lifts to the third rank
on the two center files.

STC 10+0.1 th 1 :
LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 40654 W: 9028 L: 8704 D: 22922
http://tests.stockfishchess.org/tests/view/5d885da60ebc5906dd3e9fcd

LTC 60+0.6 th 1 :
LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 56963 W: 9530 L: 9196 D: 38237
http://tests.stockfishchess.org/tests/view/5d88618c0ebc5906dd3ea45f

Thanks to @snicolet for mentioning that Komodo does this a lot and
Stockfish doesn't, which gave me the idea for this patch, and to
@noobpwnftw for providing cores to fishtest which allowed very quick
testing.

Future work: perhaps this can be refined somehow to encourage this
on other files, my attempts have failed.

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

Bench: 3950249

Revert "Clarify the mapping of files to queenside"

This reverts commit 7756344d5d2b93970e7cd423f8cbf6fb1da11b74.

Clarify the mapping of files to queenside

Author: @nickpelling

We replace in the code the obscure expressions mapping files ABCDEFGH to ABCDDCBA
by an explicite call to an auxiliary function :

  old:   f = min(f, ~f)
  new:   f = map_to_queenside(f)

We used the Golbolt web site (https://godbolt.org) to find the optimal code
for the auxiliary function.

STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 30292 W: 6756 L: 6651 D: 16885
http://tests.stockfishchess.org/tests/view/5d8676720ebc5971531d6aa1

No functional change

More random draw evaluations

Use the randomized draw function value_draw() also for draw evalutions.

This extends the earlier commit
https://github.com/official-stockfish/Stockfish/commit/97d2cc9a9c1c4b6ff1b470676fa18c7fc6509886
which did this only for 3folds.

As in that case, this test was yellow at STC and LTC, but green at VLTC,
indicative of the fact that the higher the drawrate, the more likely this
idea is beneficial.

STC:
LLR: -2.96 (-2.94,2.94) [0.50,4.50]
Total: 83573 W: 18584 L: 18335 D: 46654
http://tests.stockfishchess.org/tests/view/5d84e44d0ebc5971531d4f94

LTC:
LLR: -2.96 (-2.94,2.94) [0.00,3.50]
Total: 92252 W: 15240 L: 15160 D: 61852
http://tests.stockfishchess.org/tests/view/5d865dd90ebc5971531d68e1

VLTC: 120+1.2 @ 2th
LLR: 2.96 (-2.94,2.94) [0.00,3.50]
Total: 51902 W: 7323 L: 7028 D: 37551
http://tests.stockfishchess.org/tests/view/5d8763620ebc595f57c22b15

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

Bench: 3441237

Simplify connected pawn scoring

When scoring the connected pawns, replace the intricate ternary expressions
choosing the coefficient by a simpler addition of boolean conditions:

` value = Connected * (2 + phalanx - opposed) `

This is the map showing the old coefficients and the new ones:

```
phalanx and unopposed:     3x   -> 3x
phalanx and opposed:       1.5x -> 2x
not phalanx and unopposed: 2x   -> 2x
not phalanx and opposed:   1x   -> 1x
```

STC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 11354 W: 2579 L: 2437 D: 6338
http://tests.stockfishchess.org/tests/view/5d8151f00ebc5971531d244f

LTC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 41221 W: 7001 L: 6913 D: 27307
http://tests.stockfishchess.org/tests/view/5d818f930ebc5971531d26d6

Bench: 3959889

blah

Acknowledge fishtest authors

Explicitly acknowledge fishtest authors.
Their efforts are almost invisible, but essential for the project.

Many thanks to https://github.com/glinscott/fishtest/blob/master/AUTHORS !

No functional change.

Raise stack size to 8MB for pthreads

It seems there is no other way to specify stack size on std::thread than linker
flags and the effective flags are named differently in many toolchains. On
toolchains where pthread is always available, this patch changes the stack
size change in our C++ code via pthread to ensure a minimum stack size of 8MB,
instead of relying on linker defaults which may be platform-specific.

Also raises default stack size on OSX to current Linux default (8MB) just to
be safe.

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

No functional change

Scale down endgame factor when shuffling

This patch decreases the endgame scale factor using the 50 moves counter.
Looking at some games with this patch, it seems to have two effects on
the playing style:

1) when no progress can be made in late endgames (for instance in fortresses
   or opposite bishops endgames) the evaluation will be largely tamed down
   towards a draw value.

2) more interestingly, there is also a small effect in the midgame play because
   Stockfish will panic a little bit if there are more than four consecutive
   shuffling moves with an advantage: the engine will try to move a pawn or to
   exchange a piece to keep the advantage, so the follow-ups of the position
   will be discovered earlier by the alpha-beta search.

passed STC:
LLR: 2.95 (-2.94,2.94) [0.50,4.50]
Total: 23017 W: 5080 L: 4805 D: 13132
http://tests.stockfishchess.org/tests/view/5d7e4aef0ebc59069c36fc74

passed LTC:
LLR: 2.95 (-2.94,2.94) [0.00,3.50]
Total: 30746 W: 5171 L: 4911 D: 20664
http://tests.stockfishchess.org/tests/view/5d7e513d0ebc59069c36ff26

Pull request: https://github.com/official-stockfish/Stockfish/pull/2304

Bench: 4272173

Introduce midgame initiative

This patch finally introduces something that was tried for years: midgame score
dependance on complexity of position. More precisely, if the position is very
simplified and the complexity measure calculated in the initiative() function
is inferior to -50 by an amount d, then we add this value d to the midgame score.

One example of play of this patch will be (again!) 4 vs 3 etc same flank endgames
where sides have a lot of non-pawn material: 4 vs 3 draw mostly remains the same
draw even if we add a lot of equal material to both sides.

STC run was stopped after 200k games (and not converging):
LLR: -1.75 (-2.94,2.94) [0.50,4.50]
Total: 200319 W: 44197 L: 43310 D: 112812
http://tests.stockfishchess.org/tests/view/5d7cfdb10ebc5902d386572c

passed LTC:
LLR: 2.95 (-2.94,2.94) [0.00,3.50]
Total: 41051 W: 6858 L: 6570 D: 27623
http://tests.stockfishchess.org/tests/view/5d7d14680ebc5902d3866196

This is the first and not really precise version, a lot of other stuff can be
tried on top of it (separate complexity for middlegame, some more terms, even
simple retuning of values).

Bench: 4248476

Assorted trivial cleanups

No functional change

Use queens of either color in RookOnQueenFile

The recently-added RookOnQueenFile evaluation term (36e4a86) provided a bonus
for placing our rook on the same file as an enemy queen.

Here, we relax a condition in this bonus, broadening its effect to any queen.
It is also strategically desirable to place the rook on the same file as a friendly
queen, so the restriction on the queen's color is removed.

STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 66856 W: 14847 L: 14815 D: 37194
http://tests.stockfishchess.org/tests/view/5d7b3c6a0ebc5902d385bcf5

LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 86786 W: 14264 L: 14248 D: 58274
http://tests.stockfishchess.org/tests/view/5d7b4e9b0ebc5902d385c178

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

Bench: 3703909

Update Makefile documentation

Follow-up to previous commit. Update the documentation for the user when using `make`,
to show the preferred bmi2 compile in the advanced examples section.

Note: I made a mistake in the previous commit comment, the documentation is shown when
using `make` or `make help`, not `make --help`.

No functional change

Add sse4 if bmi2 is enabled

The only change done to the Makefile to get a somewhat faster binary as
discussed in #2291 is to add -msse4 to the compile options of the bmi2 build.
Since all processors supporting bmi2 also support sse4 this can be done easily.
It is a useful step to avoid sending around custom and poorly tested builds.

The speedup isn't enough to pass [0,4] but it is roughly 1.15Elo and a LOS of 90%:
LLR: -2.95 (-2.94,2.94) [0.00,4.00]
Total: 93009 W: 20519 L: 20316 D: 52174

Also rewrite the documentation for the user when using `make --help`, so that
the order of architectures for x86-64 has the more performant build one on top.

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

No functional change

Scale down complexity for almost unwinnable endgames

This patch greatly scales down complexity of endgames when the
following conditions are all true together:

- pawns are all on one flank
- stronger side king is not outflanking weaker side
- no passed pawns are present

This should improve stockfish evaluation of obvious draws 4 vs 3, 3 vs 2
and 2 vs 1 pawns in rook/queen/knight/bishop single flank endgames where
strong side can not make progress.

passed STC
LLR: 2.94 (-2.94,2.94) [0.50,4.50]
Total: 15843 W: 3601 L: 3359 D: 8883

passed LTC
LLR: 2.96 (-2.94,2.94) [0.00,3.50]
Total: 121275 W: 20107 L: 19597 D: 81571

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

Bench: 3954190

==========================

How to continue from there?

a) This could be a powerful idea for refining some parts of the evaluation
   function, a bit like when we try quadratics or other equations to emphasize
   certain situations (xoto10).

b) Some other combinaison values for this bonus can be done further, or
   overall retuning of weight and offset while keeping the formula simple.

Bonus for rook on same file as their queen

This patch creates a simple bonus for a rook that is on the same file as the
opponent's queen.

STC 10+0.1 th 1 :
LLR: 2.95 (-2.94,2.94) [0.50,4.50]
Total: 45609 W: 10120 L: 9733 D: 25756
http://tests.stockfishchess.org/tests/view/5d79895a0ebc5902d385484a

LTC 60+0.6 th 1 :
LLR: 2.96 (-2.94,2.94) [0.00,3.50]
Total: 51651 W: 8606 L: 8288 D: 34757
http://tests.stockfishchess.org/tests/view/5d79a0850ebc5902d3854d27

Many thanks to @noobpwnftw for providing the extra cpu resources for fishtest,
which led to me doing these tests.

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

Bench: 4024461

Simplify Weak Lever

This is a simplification that integrated WeakLever into doubled pawns.
Since we already check for !support for Doubled pawns, it is trivial
to check for weak lever by just checking more_than_one(lever).

We also introduce the Score * bool operation overload to remove some
casts in the code.

STC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 26757 W: 5842 L: 5731 D: 15184
http://tests.stockfishchess.org/tests/view/5d77ee220ebc5902d384e5a4

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

No functional change

Update reverse move stats

For a good quiet non-pawn move consider the reverse move as bad
and update the main history with a negative stat bonus.

STC:
LLR: 2.95 (-2.94,2.94) [0.50,4.50]
Total: 19292 W: 4401 L: 4141 D: 10750
http://tests.stockfishchess.org/tests/view/5d7751d50ebc594e7864973c

LTC:
LLR: 2.95 (-2.94,2.94) [0.00,3.50]
Total: 111952 W: 18762 L: 18275 D: 74915
http://tests.stockfishchess.org/tests/view/5d7771cf0ebc594e786498fa

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

Bench: 3914238

Tweak Late Move Reduction at root

Maintain best move counter at the root and allow there only moves which has a counter
of zero for Late Move Reduction. For compensation only the first three moves are excluded
from Late Move Reduction per default instead the first four moves.

What we can further do:

- here we use a simple counting scheme but perhaps some aging to fade out early iterations
  could be helpful
- use the best move counter also at inner nodes for LMR and/or pruning

STC:
LLR: 2.95 (-2.94,2.94) [0.50,4.50]
Total: 17414 W: 3984 L: 3733 D: 9697
http://tests.stockfishchess.org/tests/view/5d6234bb0ebc5939d09f2aa2

LTC:
LLR: 2.96 (-2.94,2.94) [0.00,3.50]
Total: 38058 W: 6448 L: 6166 D: 25444
http://tests.stockfishchess.org/tests/view/5d62681a0ebc5939d09f2f27

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

Bench: 3568210

NMP Tweaks

Tweak again the null move pruning preconditions.

STC:
LLR: 2.96 (-2.94,2.94) [0.50,4.50]
Total: 19675 W: 4430 L: 4169 D: 11076
http://tests.stockfishchess.org/tests/view/5d52bc0e0ebc5925cf108300

LTC:
LLR: 2.95 (-2.94,2.94) [0.00,3.50]
Total: 73895 W: 12496 L: 12114 D: 49285
http://tests.stockfishchess.org/tests/view/5d52dcbc0ebc5925cf108552

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

Bench: 3690065

Improve signature of evaluate_shelter()

Remove one parameter in function evaluate_shelter(), making all
comparisons for castled/uncastled shelter locally in do_king_safety().
Also introduce BlockedStorm penalty.

Passed non-regression test at STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 65864 W: 14630 L: 14596 D: 36638
http://tests.stockfishchess.org/tests/view/5d5fc80c0ebc5939d09f0acc

No functional change

Consolidate CastlingSide and CastlingRights

This is a non-functional simplification that removes CastlingSide and
implements the functionality in CastlingRights (thanks to Jörg Oster
for a comment on the first version of this patch).

STC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 53854 W: 12077 L: 12019 D: 29758
http://tests.stockfishchess.org/tests/view/5d517b940ebc5925cf107474

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

No functional change

Simplify futility equation

This is a functional simplification. The 178 constant for the futility equation
in master can be removed.

STC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 42626 W: 9508 L: 9428 D: 23690
http://tests.stockfishchess.org/tests/view/5d5d4e320ebc5925cf11254e

LTC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 26182 W: 4432 L: 4320 D: 17430
http://tests.stockfishchess.org/tests/view/5d5df70d0ebc5925cf112fee

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

Bench: 3985701

Late move reduction, captures and CUT nodes

Expand of Stefan Geschwentner's original idea: we always do LMR for captures at cutnodes.

Passed STC
http://tests.stockfishchess.org/tests/view/5d5b2f8e0ebc5925cf1111b8
LLR: 2.96 (-2.94,2.94) [0.50,4.50]
Total: 36026 W: 8122 L: 7779 D: 20125

Passed LTC
http://tests.stockfishchess.org/tests/view/5d5b40c80ebc5925cf111353
LLR: 3.22 (-2.94,2.94) [0.00,3.50]
Total: 133502 W: 22508 L: 21943 D: 89051

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

Bench: 3494372

Tuned Futility Equation

@Vizvezdenec array suggested that alternate values may be better than current
master (see pull request #2270 ). I tuned some linear equations to more closely
represent his values and it passed. These futility values seem quite sensitive,
so perhaps additional Elo improvements can be found here.

STC
LLR: 2.95 (-2.94,2.94) [0.50,4.50]
Total: 12257 W: 2820 L: 2595 D: 6842
http://tests.stockfishchess.org/tests/view/5d5b2f360ebc5925cf1111ac

LTC
LLR: 2.96 (-2.94,2.94) [0.00,3.50]
Total: 20273 W: 3497 L: 3264 D: 13512
http://tests.stockfishchess.org/tests/view/5d5c0d250ebc5925cf111ac3

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

------------------------------------------
How to continue from there ?

a) we can try a simpler version for the futility margin, this would
   be a simplification :
    margin = 188 * (depth - improving)

b) on the other direction, we can try a complexification by trying
   again to gain Elo with an complete array of futility values.

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

Bench: 4330402

Slight speep up fetching the endgame table

Replace calls to count(key) + operator[key] with a single call to find(key).
Replace the std::map with std::unordered_map which provide O(1) access,
although the map has a really small number of objects.

Test with [0..4] failed yellow:

TC 10+0.1
SPRT elo0: 0.00  alpha: 0.05  elo1: 4.00  beta: 0.05
LLR -2.96 [-2.94,2.94] (rejected)
Elo 1.01 [-0.87,3.08] (95%)
LOS 85.3%
Games 71860 [w:22.3%, l:22.2%, d:55.5%]
http://tests.stockfishchess.org/tests/view/5d5432210ebc5925cf109d61

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

No functional change

Assorted trivial cleanups (July 2019)

No functional change

Tweak unsafe checks

Remove mobility area for unsafe checks. Also separate the evaluation terms
for unsafe checks and blockers for king with adjusted weights.

STC:
LLR: 2.95 (-2.94,2.94) [0.50,4.50]
Total: 124526 W: 28292 L: 27504 D: 68730
http://tests.stockfishchess.org/tests/view/5d5138290ebc5925cf1070c3

LTC:
LLR: 2.96 (-2.94,2.94) [0.00,3.50]
Total: 84968 W: 14499 L: 14083 D: 56386
http://tests.stockfishchess.org/tests/view/5d527cfa0ebc5925cf107f93

Bench: 4139590

Revert "Revert "Revert "Shuffle detection #2064"""

This reverts commit ca6ce6398b1bd21ff2ac29b2dc27d7c25abbb509.

Merge remote-tracking branch 'upstream/master'

Revert "Improve multiPV mode"

This reverts commit a8de07cc26999e2fef7298a63bfe349aaa4650fa.

Tune search constants

This is the result of a 200k tuning run at LTC:
http://tests.stockfishchess.org/tests/view/5d3576b70ebc5925cf0e9e1e

which passed quickly at LTC:
LLR: 2.95 (-2.94,2.94) [0.50,4.50]
Total: 12954 W: 2280 L: 2074 D: 8600
http://tests.stockfishchess.org/tests/view/5d3ff3f70ebc5925cf0f87a2

STC failed, but second LTC at [0,4] passed easily:
LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 8004 W: 1432 L: 1252 D: 5320
http://tests.stockfishchess.org/tests/view/5d407cff0ebc5925cf0f9119

Further work?
No doubt some of these changes produce most of the gain and some are neutral
or even bad, so further testing on individual/groups of parameters changed
here might show more gains. It does look like these tests might need to be
at LTC though, so maybe not too practical to do. See the thread in the pull
request for an interesting discussion:
https://github.com/official-stockfish/Stockfish/pull/2260

Bench: 4024328

Simplify weak lever

STC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 14844 W: 3347 L: 3212 D: 8285
http://tests.stockfishchess.org/tests/view/5d3a2d7b0ebc5925cf0f1632

LTC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 55261 W: 9374 L: 9309 D: 36578
http://tests.stockfishchess.org/tests/view/5d3a3d9e0ebc5925cf0f1786

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

bench: 3484124

Bug fix: always choose shortest mate in multithread mode

In current master, with the voting scheme the best thread selection may
pick a non mate or not the shortest mate thread. This patch fixes this bug.
Formatting suggestion by Jörg Oster.

Related past pull requests:
https://github.com/official-stockfish/Stockfish/pull/1074
https://github.com/official-stockfish/Stockfish/pull/1215

Passed a [-4..0] verification test with 3 threads:
LLR: 2.95 (-2.94,2.94) [-4.00,0.00]
Total: 57158 W: 11374 L: 11424 D: 34360
http://tests.stockfishchess.org/tests/view/5d22deb30ebc5925cf0caefd

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

No functional change (in single threaded mode)

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

Comment by Jörg Oster

Just one sample output to demonstrate the effect of this patch.
5 Threads, 1 GB Hash

 +---+---+---+---+---+---+---+---+
 | r |   | b |   |   | r | k |   |
 +---+---+---+---+---+---+---+---+
 |   |   |   | n |   | p | b |   |
 +---+---+---+---+---+---+---+---+
 |   |   | p |   | p |   | p |   |
 +---+---+---+---+---+---+---+---+
 | p |   |   |   |   |   | P |   |
 +---+---+---+---+---+---+---+---+
 | P | p |   |   | B |   | N | Q |
 +---+---+---+---+---+---+---+---+
 |   | q |   |   |   |   | P |   |
 +---+---+---+---+---+---+---+---+
 |   |   | R |   |   | P |   |   |
 +---+---+---+---+---+---+---+---+
 |   |   |   | R |   |   | K |   |
 +---+---+---+---+---+---+---+---+

Fen: r1b2rk1/3n1pb1/2p1p1p1/p5P1/Pp2B1NQ/1q4P1/2R2P2/3R2K1 w - - 8 34
Key: 38B4CA1067D4F477
Checkers:
ucinewgame
isready
readyok
go mate 17 searchmoves d1d7
info depth 65 seldepth 36 multipv 1 score mate 18 nodes 785875935 nps 8650448 hashfull 1000 tbhits 0 time 90848 pv d1d7 c8d7 g4f6 g7f6 g5f6 b3a3 g1g2 a3a1 h4g5 a1f6 g5f6 e6e5 c2c1 d7h3 g2h3 a8a6 h3g2 c6c5 f6a6 g8g7 c1c5 f7f6 a6e6 f8f7 c5c8 f6f5 e4d5 g7h6 e6f7 f5f4 f7e7 f4f3 d5f3 b4b3 c8h8
info depth 63 seldepth 36 multipv 1 score mate 17 nodes 785875935 nps 8650448 hashfull 1000 tbhits 0 time 90848 pv d1d7 c8d7 g4f6 g7f6 g5f6 b3a3 g1g2 a3a1 h4g5 a1f6 g5f6 e6e5 c2c1 d7h3 g2h3 a8a6 c1d1 b4b3 h3g2 c6c5 f6a6 g8g7 d1d7 g7g8 a6f6 b3b2 e4g6 b2b1q g6f7 f8f7 f6f7 g8h8 f7g7
bestmove d1d7 ponder c8d7

Remove operators for color

This is a non-functional and untested simplification. The increment operator
for color isn't really necessary and seems a bit unnatural to me.

Passed STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 47027 W: 10589 L: 10518 D: 25920
http://tests.stockfishchess.org/tests/view/5d3472d10ebc5925cf0e8d3e

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

No functional change

Tweak of SEE pruning condition

passed STC
http://tests.stockfishchess.org/tests/view/5d386bda0ebc5925cf0ef49a
LLR: 2.95 (-2.94,2.94) [0.50,4.50]
Total: 56874 W: 12820 L: 12373 D: 31681

passed LTC
http://tests.stockfishchess.org/tests/view/5d38873a0ebc5925cf0ef86e
LLR: 2.95 (-2.94,2.94) [0.00,3.50]
Total: 43512 W: 7547 L: 7247 D: 28718

Additional thanks to @locutus2 , @miguel-l and @xoto10 for fruitful discussion.
There may be some more elo there since this tweak was the first one and numbers
are more or less arbitrary.

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

Bench 3935523

Pawn clean up

Non functional simplification when we find the passed pawns in pawn.cpp
and some code clean up. It also better follows the pattern "flag the pawn"
and "score the pawn".

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

The idea behind the third condition for candidate passed pawn is a little
bit difficult to visualize. Just for the record, the idea is the following:

Consider White e5 d4 against black e6. d4 can (in some endgames) push
to d5 and lever e6. Thanks to this sacrifice, or after d5xe6, we consider
e5 as "passed".

However:
- if White e5/d4 against black e6/c6: d4 cannot safely push to d5 since d5 is double attacked;
- if White e5/d4 against black e6/d5: d4 cannot safely push to d5 since it is occupied.

This is exactly what the following expression does:

```
   && (shift<Up>(support) & ~(theirPawns | dblAttackThem)))
```

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

http://tests.stockfishchess.org/tests/view/5d3325bb0ebc5925cf0e6e91
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 124666 W: 27586 L: 27669 D: 69411

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

No functional change

LMR Tweak

Reset statScore to zero if negative and most stats shows >= 0

STC:
LLR: 2.95 (-2.94,2.94) [0.50,4.50]
Total: 23097 W: 5242 L: 4963 D: 12892
http://tests.stockfishchess.org/tests/view/5d31dd650ebc5925cf0e598f

LTC:
LLR: 2.95 (-2.94,2.94) [0.00,3.50]
Total: 227597 W: 39013 L: 38191 D: 150393
http://tests.stockfishchess.org/tests/view/5d31fcdf0ebc5925cf0e5c13

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

Bench: 3242229

Passed file cleanup

Protonspring had a successful functional simplification that removes the
PassedFile array using a simple linear equation.

Merge the additive term S(5, 10) of protonspring passed file simplification
(pull request https://github.com/official-stockfish/Stockfish/pull/2250)
into the PassedRank array. This harmless change has a different bench because
the candidate passer evaluation will always get less compared to #2250,
as we apply bonus = bonus /2.

Tested as a non-regression against #2250

Passed STC
http://tests.stockfishchess.org/tests/view/5d33427e0ebc5925cf0e6fa2
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 81459 W: 18174 L: 18171 D: 45114

Passed LTC
http://tests.stockfishchess.org/tests/view/5d335c8d0ebc5925cf0e731e
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 18525 W: 3176 L: 3052 D: 12297

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

Bench: 3859856

No influence on unsafeSquares of passers by pieces

Remove their pieces from influencing 'unsafeSquares' in passer
evaluation.

STC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 36421 W: 8170 L: 8078 D: 20173
http://tests.stockfishchess.org/tests/view/5d22fc8e0ebc5925cf0cb26e

LTC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 18927 W: 3253 L: 3129 D: 12545
http://tests.stockfishchess.org/tests/view/5d26e2b20ebc5925cf0d3218

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

Bench: 3285659

Tweak LMR and killers

Give extra stat bonus/malus in case of LMR for killers.

passed STC
http://tests.stockfishchess.org/tests/view/5d2c8e760ebc5925cf0dcf23
LLR: 2.95 (-2.94,2.94) [0.50,4.50]
Total: 67188 W: 15030 L: 14534 D: 37624

passed LTC
http://tests.stockfishchess.org/tests/view/5d2d0ce40ebc5925cf0de115
LLR: 2.96 (-2.94,2.94) [0.00,3.50]
Total: 144355 W: 24739 L: 24153 D: 95463

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

bench 3723147

Space Invaders

Try a more ambitius simplification of the space bonus

STC http://tests.stockfishchess.org/tests/view/5d2b62c90ebc5925cf0da2a4
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 51299 W: 11320 L: 11257 D: 28722

LTC http://tests.stockfishchess.org/tests/view/5d2bac270ebc5925cf0db215
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 49761 W: 8409 L: 8335 D: 33017

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

bench: 3395999

Fix bench

Bench: 3357457

UCI_Elo implementation (#2225)

This exploits the recent fractional Skill Level, and is a result from some discussion in #2221 and the older #758.

Basically, if UCI_LimitStrength is set, it will internally convert UCI_Elo to a matching fractional Skill Level.
The Elo estimate is based on games at  TC 60+0.6, Hash 64Mb, 8moves_v3.pgn, rated with Ordo, anchored to goldfish1.13 (CCRL 40/4 ~2000).
Note that this is mostly about internal consistency, the anchoring to CCRL is a bit weak, e.g. within this tournament,
goldfish and sungorus only have a 200Elo difference, their rating difference on CCRL is 300Elo.

I propose that we continue to expose 'Skill Level' as an UCI option, for backwards compatibility.

The result of a tournament under those conditions are given by the following table, where the player name reflects the UCI_Elo.

   # PLAYER          :  RATING  ERROR  POINTS  PLAYED   (%)  CFS(%)
   1 Elo2837         :  2792.2   50.8   536.5     711    75     100
   2 Elo2745         :  2739.0   49.0   487.5     711    69     100
   3 Elo2654         :  2666.4   49.2   418.0     711    59     100
   4 Elo2562         :  2604.5   38.5   894.5    1383    65     100
   5 Elo2471         :  2515.2   38.1   651.5     924    71     100
   6 Elo2380         :  2365.9   35.4   478.5     924    52     100
   7 Elo2289         :  2290.0   28.0   864.0    1596    54     100
   8 sungorus1.4     :  2204.9   27.8   680.5    1596    43      60
   9 Elo2197         :  2201.1   30.1   523.5     924    57     100
  10 Elo2106         :  2103.8   24.5   730.5    1428    51     100
  11 Elo2014         :  2030.5   30.3   377.5     756    50      98
  12 goldfish1.13    :  2000.0   ----   511.0    1428    36     100
  13 Elo1923         :  1928.5   30.9   641.5    1260    51     100
  14 Elo1831         :  1829.0   42.1   370.5     756    49     100
  15 Elo1740         :  1738.3   42.9   277.5     756    37     100
  16 Elo1649         :  1625.0   42.1   525.5    1260    42     100
  17 Elo1558         :  1521.5   49.9   298.0     756    39     100
  18 Elo1467         :  1471.3   51.3   246.5     756    33     100
  19 Elo1375         :  1407.1   51.9   183.0     756    24     ---

It can be observed that all set Elos correspond within the error bars with the observed Ordo rating.

No functional change

Remove std::pow from reduction. (#2234)

This is a functional simplification that removes the std::pow from reduction. The resulting reduction values are within 1% of master.

This is a simplification because i believe an fp addition and multiplication is much faster than a call to std::pow() which is historically slow and performance varies widely on different architectures.

STC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 23471 W: 5245 L: 5127 D: 13099
http://tests.stockfishchess.org/tests/view/5d27ac1b0ebc5925cf0d476b

LTC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 51533 W: 8736 L: 8665 D: 34132
http://tests.stockfishchess.org/tests/view/5d27b74e0ebc5925cf0d493c

Bench 3765158

Just blockSq, not forward file. Bench: 3377831 (#2240)

This is another functional simplification to Stockfish passed pawn evaluation.

Stockfish evaluates some pawns which are not yet passed as "candidate" passed pawns, which are given half the bonus of fully passed ones. Prior to this commit, Stockfish considered a passed pawn to be a "candidate" if (a) it would not be a passed pawn if moved one square forward (the blocking square), or (b) there were other pawns (of either color) in front of it on the file. This latter condition used a fairly complicated method, forward_file_bb; here, rather than inspect the entire forward file, we simply re-use the blocking square. As a result, some pawns previously considered "candidates", but which are able to push forward, no longer have their bonus halved.

Simplification tests passed quickly at both STC and LTC. The results from both tests imply that this simplification is, most likely, additionally a small Elo gain, with a LTC likelihood of superiority of 87 percent.

STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 12908 W: 2909 L: 2770 D: 7229
http://tests.stockfishchess.org/tests/view/5d2a1c880ebc5925cf0d9006

LTC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 20723 W: 3591 L: 3470 D: 13662
http://tests.stockfishchess.org/tests/view/5d2a21fd0ebc5925cf0d9118

Bench: 3377831

tviigg. (#2238)

Current master code made sence when we had 2 types of bonuses for protected path to queen. But it was simplified so we have only one bonus now and code was never cleaned.
This non-functional simplification removes useless defendedsquares bitboard and removes one bitboard assignment (defendedSquares &= attackedBy[Us][ALL_PIECES] + defendedSquares & blockSq becomes just attackedBy[Us][ALL_PIECES] & blockSq also we never assign defendedSquares = squaresToQueen because we don't need it).
So should be small non-functional speedup.
Passed simplification SPRT.
http://tests.stockfishchess.org/tests/view/5d2966ef0ebc5925cf0d7659
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 23319 W: 5152 L: 5034 D: 13133

bench 3361902

Linear formula for w. Bench: 3328507 (#2239)

In Stockfish, both the middlegame and endgame bonus for a passed pawn are calculated as a product of two factors. The first is k, chosen based on the presence of defended and unsafe squares. The second is w, a quadratic function of the pawn's rank. Both are only applied if the pawn's relative rank is at least RANK_4.

It does not appear that the complexity of a quadratic function is necessary for w. Here, we replace it with a simpler linear one, which performs equally at both STC and LTC.

STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 46814 W: 10386 L: 10314 D: 26114
http://tests.stockfishchess.org/tests/view/5d29686e0ebc5925cf0d76a1

LTC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 82372 W: 13845 L: 13823 D: 54704
http://tests.stockfishchess.org/tests/view/5d2980650ebc5925cf0d7bfd

Bench: 3328507

Full bonus for LMR stats update

Simplify previous commit by using the full bonus for LMR-triggered stats update.

STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 23684 W: 5255 L: 5137 D: 13292
http://tests.stockfishchess.org/tests/view/5d2826660ebc5925cf0d5180

LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 16245 W: 2832 L: 2704 D: 10709
http://tests.stockfishchess.org/tests/view/5d282e9c0ebc5925cf0d529b

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

Bench: 3361902

Late Move reduction and continuation history

Update continuation history after LMR-triggered full depth research.
Directly after a LMR-triggered full depth research, we update the
continuation history for quiet moves (but with only half stat bonus).

STC:
LLR: 2.96 (-2.94,2.94) [0.50,4.50]
Total: 39657 W: 8966 L: 8604 D: 22087
http://tests.stockfishchess.org/tests/view/5d279fa40ebc5925cf0d4566

LTC:
LLR: 2.96 (-2.94,2.94) [0.50,3.50]
Total: 32582 W: 5740 L: 5427 D: 21415
http://tests.stockfishchess.org/tests/view/5d27dbf90ebc5925cf0d4b7e

Bench: 3239357

Exclude passed pawns from Attacked2Unsupported

We recently added a bonus for double pawn attacks on unsupported enemy pawns,
on June 27. However, it is possible that the unsupported pawn may become a passer
by simply pushing forward out of the double attack. By rewarding double attacks,
we may inadvertently reward the creation of enemy passers, by encouraging both of
our would-be stoppers to attack the enemy pawn even if there is no opposing
friendly pawn on the same file.

Here, we revise this term to exclude passed pawns. In order to simplify the code
with this change included, we non-functionally rewrite Attacked2Unsupported to
be a penalty for enemy attacks on friendly pawns, rather than a bonus for our
attacks on enemy pawns. This allows us to exclude passed pawns with a simple
& ~e->passedPawns[Us], while passedPawns[Them] is not yet defined in this part
of the code.

This dramatically reduces the proportion of positions in which Attacked2Unsupported
is applied, to about a third of the original. To compensate, maintaining the same
average effect across our bench positions, we nearly triple Attacked2Unsupported
from S(0, 20) to S(0, 56). Although this pawn formation is rare, it is worth more
than half a pawn in the endgame!

STC: (stopped automatically by fishtest after 250,000 games)
LLR: -0.87 (-2.94,2.94) [0.50,4.50]
Total: 250000 W: 56585 L: 55383 D: 138032
http://tests.stockfishchess.org/tests/view/5d25795e0ebc5925cf0cfb51

LTC:
LLR: 2.96 (-2.94,2.94) [0.00,3.50]
Total: 81038 W: 13965 L: 13558 D: 53515
http://tests.stockfishchess.org/tests/view/5d25f3920ebc5925cf0d10dd

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

Bench: 3765158

Assorted trivial cleanups June 2019

No functional change.

Tweak capture scoring formula

STC:
LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 20556 W: 4685 L: 4438 D: 11433
http://tests.stockfishchess.org/tests/view/5d25d26e0ebc5925cf0d0b4a

LTC:
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 14856 W: 2649 L: 2446 D: 9761
http://tests.stockfishchess.org/tests/view/5d25d8b20ebc5925cf0d0c6d

bench: 3206912

Combo of statscore divisor and pawn psqt changes

Passed STC 10+0.1 th 1:
LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 13282 W: 3100 L: 2881 D: 7301
http://tests.stockfishchess.org/tests/view/5d21132e0ebc5925cf0c81f4

Passed LTC 60+0.6 th 1:
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 44243 W: 7768 L: 7468 D: 29007
http://tests.stockfishchess.org/tests/view/5d2119050ebc5925cf0c832b

Bench 3705891

Use score instead of array to evaluate shelter

This is a non-functional simplification. Instead of an array of values, just use a Score.

STC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 16309 W: 3673 L: 3541 D: 9095
http://tests.stockfishchess.org/tests/view/5d24f3b80ebc5925cf0ceb5b

No functional change

Enable popcount and prefetch for ppc-64

PowerPC has had popcount instructions for a long time, at least as far
back as POWER5 (released 2004). Enable them via a gcc builtin.

Using a gcc builtin has the added bonus that if compiled for a processor
that lacks a hardware instruction, gcc will include a software popcount
implementation that does not use the instruction. It might be slower
than the table lookups (or it might be faster) but it will certainly work.
So this isn't going to break anything.

On my POWER8 VM, this leads to a ~4.27% speedup.

Fir prefetch, the gcc builtin generates a 'dcbt' instruction, which is
supported at least as far back as the G5 (2002) and POWER4 (2001).

This leads to a ~5% speedup on my POWER8 VM.

No functional change

Smoothly change playing strength with skill level. (#2142)

The current skill levels (1-20) allow for adjusting playing strengths, but
do so in big steps (e.g. level 10 vs level 11 is a ~143 Elo jump at STC).
Since the 'Skill Level' input can already be a floating point number, this
patch uses the fractional part of the input to provide the user with
fine control, allowing for varying the playing strength essentially
continuously.

The implementation internally still uses integer skill levels (needed since they pick Depths),
but non-deterministically rounds up or down the used skill level such that the average integer
skill corresponds to the input floating point one. As expected, intermediate
(fractional) skill levels yield intermediate playing strenghts.

Tested at STC, playing level 10 against levels between 10 and 11 for 10000 games

level 10.25 ELO:  24.26 +-6.2
level 10.5  ELO:  67.51 +-6.3
level 10.75 ELO:  98.52 +-6.4
level 11    ELO: 143.65 +-6.7

http://tests.stockfishchess.org/tests/view/5cd9c6b40ebc5925cf056791
http://tests.stockfishchess.org/tests/view/5cd9d22b0ebc5925cf056989
http://tests.stockfishchess.org/tests/view/5cd9cf610ebc5925cf056906
http://tests.stockfishchess.org/tests/view/5cd9d2490ebc5925cf05698e

No functional change.

Introduce coordination between searching threads (#2204)

this patch improves threading performance by introducing some coordination between threads.

The observation is that threading is an area where a lot of Elo can potentially be gained:
https://github.com/glinscott/fishtest/wiki/UsefulData#elo-from-threading
At STC, 8 threads gain roughly 320 Elo, vs sequential at the same time,
however, loses 66 Elo against a single thread with 8x more time.
This 66 Elo should be partially recoverable with improved threading.

To improve threading, this patch introduces some LMR at nodes that are already being searched by other threads.
This requires some coordination between threads, avoiding however synchronisation.
To do so, threads leave a trail of breadcrumbs to mark the nodes they are searching.
These breadcrumbs are stored in a small hash table, which is only probed at low plies (currently ply < 8).

A couple of variants of this patch passed both STC and LTC threaded tests.
I picked the simpler, more robust version.
I expect that further tests can find further improvements.

STC (5+0.05 @ 8 threads):
LLR: 2.95 (-2.94,2.94) [0.50,4.50]
Total: 26209 W: 5359 L: 5079 D: 15771
http://tests.stockfishchess.org/tests/view/5d0a9b030ebc5925cf0a8e6f

LTC (20+0.2 @ 8 threads):
LLR: 2.96 (-2.94,2.94) [0.00,3.50]
Total: 34832 W: 5650 L: 5382 D: 23800
http://tests.stockfishchess.org/tests/view/5d0c67a20ebc5925cf0aafa7

other passed/tested variants:
http://tests.stockfishchess.org/tests/view/5d0a9b030ebc5925cf0a8e6f
http://tests.stockfishchess.org/tests/view/5d0c67ca0ebc5925cf0aafa9
http://tests.stockfishchess.org/tests/view/5d0c67810ebc5925cf0aafa3
http://tests.stockfishchess.org/tests/view/5d0958ca0ebc5925cf0a74c6

For the sequential code there is no change in bench, and an earlier version of this patch passed a non-regression test.
STC (10+0.1 @ 1 thread)
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 10471 W: 2364 L: 2220 D: 5887
http://tests.stockfishchess.org/tests/view/5d087ee20ebc5925cf0a6381

passed the additional non-regression tests at 2 and 4 threads 20+0.2 TC. The code was rebased on master prior to testing.

2 threads:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 218863 W: 40927 L: 41153 D: 136783
http://tests.stockfishchess.org/tests/view/5d18c6c30ebc5925cf0b9566

4threads:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 16839 W: 3017 L: 2889 D: 10933
http://tests.stockfishchess.org/tests/view/5d18c6ea0ebc5925cf0b9568

No functional change.

Move storm special condition to UnblockedStorm array (#2210)

This is a functional simplification.

Looks like we can accommodate the special initialization of Value in evaluate_shelter in the UnblockedStorm array.

STC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 32483 W: 7422 L: 7322 D: 17739
http://tests.stockfishchess.org/tests/view/5d14c5f80ebc5925cf0b48da

LTC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 35361 W: 6139 L: 6042 D: 23180
http://tests.stockfishchess.org/tests/view/5d14d69c0ebc5925cf0b4bd0

Bench 3596270

Try to get a more precise bench time (#2211)

Initialization of larger hash sizes can take some time.
Don't include this time in the bench by resetting the timer after Search::clear().
Also move 'ucinewgame' command down in the list, so that it is processed
after the configuration of Threads and Hash size.

No functional change.

Bonus for double attacks on unsupported pawns

This is a functional change that rewards double attacks on an unsupported pawns.

STC (non-functional difference)
LLR: 2.96 (-2.94,2.94) [0.50,4.50]
Total: 83276 W: 18981 L: 18398 D: 45897
http://tests.stockfishchess.org/tests/view/5d0970500ebc5925cf0a77d4

LTC (incomplete looping version)
LLR: 0.50 (-2.94,2.94) [0.00,3.50]
Total: 82999 W: 14244 L: 13978 D: 54777
http://tests.stockfishchess.org/tests/view/5d0a8d480ebc5925cf0a8d58

LTC (completed non-looping version).
LLR: 2.96 (-2.94,2.94) [0.00,3.50]
Total: 223381 W: 38323 L: 37512 D: 147546
http://tests.stockfishchess.org/tests/view/5d0e80510ebc5925cf0ad320

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

Bench 3633546

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

Comments by Alain SAVARD:

interesting result ! I would have expected that search would resolve such positions
correctly on the very next move. This is not a very common pattern, and when it happens,
it will quickly disappear. So I'm quite surprised that it passed LTC.
I would be even more surprised if this would resist a simplification.

Anyway, let's try to imagine a few cases.

a) If you have White d5 f5 against Black e6, and White to move
last move by Black was probably a capture on e6 and White is about to recapture on e6

b) If you have White d5 f5 against e6, and Black to move
last move by White was possibly a capture on d5 or f5
or the pawn on e6 was pinned or could not move for some reason.
and white wants to blast open the position and just pushed d4-d5 or f4-f5

Some possible follow-ups
a) Motif is so rare that the popcount() can be safely replaced with a bool()
But this would not pass a SPRT[0,4],
So try a simplification with bool() and also without the & ~theirAttacks

b) If it works, we probably can simply have this in the loop
if (lever) score += S(0, 20);

c) remove all this and tweak something in search for pawn captures (priority, SEE, extension,..)

Introduce attacks on space area

This patch introduces a small malus for every square in our space mask
that is attacked by enemy. The value of the malus is completely arbitrary
and is something we can tweak, also maybe we can gain some elo with tweaking
space threshold after this addition.

Passed STC
http://tests.stockfishchess.org/tests/view/5d10ce590ebc5925cf0af30b
LLR: 2.96 (-2.94,2.94) [0.50,4.50]
Total: 7082 W: 1648 L: 1449 D: 3985

Passed LTC
http://tests.stockfishchess.org/tests/view/5d10d2d80ebc5925cf0af3fd
LLR: 2.96 (-2.94,2.94) [0.00,3.50]
Total: 79494 W: 13727 L: 13324 D: 52443

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

bench 3516460

Do not define increment operators on Value, Depth and Direction

These operators are never used and do not make sense for these types.

No functional change.

Improve multiPV mode

Skip all moves during the Non-PV (zero-window) search which will be
searched as PV moves later anyways. We also wake sure the moves will
be reported to the GUI despite they're not being searched — some GUIs
may get confused otherwise, and it would unnecessarily complicate the
code.

Tested with MultiPV=4
STC
http://tests.stockfishchess.org/tests/view/5ce7137c0ebc5925cf070d69
LLR: 2.95 (-2.94,2.94) [0.50,4.50]
Total: 8233 W: 3708 L: 3424 D: 1101

LTC
http://tests.stockfishchess.org/tests/view/5ce798d60ebc5925cf071d17
LLR: 2.95 (-2.94,2.94) [0.00,3.50]
Total: 7369 W: 3197 L: 2911 D: 1261

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

No functional change. (in single PV mode)

Make the debug counters thread safe.

needed to use them in a threaded run.

No functional change.

Rewrite "More bonus for free passed pawn"

-removes wideUnsafeSquares bitboard
-removes a couple of bitboard operations
-removes one if operator
-updates comments so they actually represent what this part of code is doing now.

passed non-regression STC
http://tests.stockfishchess.org/tests/view/5d0c1ae50ebc5925cf0aa8db
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 16892 W: 3865 L: 3733 D: 9294

No functional change

More bonus for free passed pawn

Give even more bonus to passed pawn if adjacent squares to its path
are not attacked.

passed STC
http://tests.stockfishchess.org/tests/view/5d08c9b10ebc5925cf0a6630
LLR: 2.95 (-2.94,2.94) [0.50,4.50]
Total: 175197 W: 39859 L: 38816 D: 96522

passed LTC
http://tests.stockfishchess.org/tests/view/5d0ab8240ebc5925cf0a8fe4
LLR: 2.95 (-2.94,2.94) [0.00,3.50]
Total: 92928 W: 16124 L: 15682 D: 61122

Bench: 3398333

Change multi-cut pruning condition

Use comparison of eval with beta to predict potential cutNodes. This
allows multi-cut pruning to also prune possibly mislabeled Pv and NonPv
nodes.

STC:
LLR: 2.95 (-2.94,2.94) [0.50,4.50]
Total: 54305 W: 12302 L: 11867 D: 30136
http://tests.stockfishchess.org/tests/view/5d048ba50ebc5925cf0a15e8

LTC:
LLR: 2.95 (-2.94,2.94) [0.00,3.50]
Total: 189512 W: 32620 L: 31904 D: 124988
http://tests.stockfishchess.org/tests/view/5d04bf740ebc5925cf0a17f0

Normally I would think such changes are risky, specially for PvNodes,
but after trying a few other versions, it seems this version is more
sound than I initially thought.

Aside from this, a small funtional change is made to return
singularBeta instead of beta to be more consistent with the fail-soft
logic used in other parts of search.

=============================

How to continue from there ?

We could try to audit other parts of the search where the "cutNode"
variable is used, and try to use dynamic info based on heuristic
eval rather than on this variable, to check if the idea behind this
patch could also be applied successfuly.

Bench: 3503788

QuietPick Speed-up

Non-functional speedup: no need to generate, score, or sort quiet moves
if SkipQuiet is true. Thanks to @mstembera for his suggestion.

STC:
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 27910 W: 6406 L: 6129 D: 15375
http://tests.stockfishchess.org/tests/view/5d07e0920ebc5925cf0a58a8

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

No functional change

Fix progress issue with shuffling extensions

Fixes issues #2126 and #2189 where no progress in rootDepth is made for particular fens:

8/8/3P3k/8/1p6/8/1P6/1K3n2 b - - 0 1
8/1r1rp1k1/1b1pPp2/2pP1Pp1/1pP3Pp/pP5P/P5K1/8 w - - 79 46

the cause are the shuffle extensions. Upon closer analysis, it appears that in these cases a shuffle extension is made for every node searched, and progess can not be made. This patch implements a fix, namely to limit the number of extensions relative to the number of nodes searched. The ratio employed is 1/4, which fixes the issues seen so far, but it is a heuristic, and I expect that certain positions might require an even smaller fraction.

The patch was tested as a bug fix and passed:

STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 56601 W: 12633 L: 12581 D: 31387
http://tests.stockfishchess.org/tests/view/5d02b37a0ebc5925cf09f6da

LTC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 52042 W: 8907 L: 8837 D: 34298
http://tests.stockfishchess.org/tests/view/5d0319420ebc5925cf09fe57

Furthermore, to confirm that the shuffle extension in this form indeed still brings Elo, one more test at VLTC was performed:
VLTC:
LLR: 2.96 (-2.94,2.94) [0.00,3.50]
Total: 142022 W: 20963 L: 20435 D: 100624
http://tests.stockfishchess.org/tests/view/5d03630d0ebc5925cf0a011a

Bench: 3961247

Partial revert of "Assorted trivial cleanups 5/2019".

Since root_probe() and root_probe_wdl() do not reset all tbRank values if they fail,
it is necessary to do this in rank_root_move(). This fixes issue #2196.
Alternatively, the loop could be moved into both root_probe() and root_probe_wdl().

No functional change

Simplify SEE Pruning (#2191)

Simplify SEE Pruning
Note this should also be a speedup...
If givesCheck is extended we know (except for DC) that it will have a positive SEE. So this new logic will be triggered before doing another expensive SEE function.

STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 24429 W: 5484 L: 5368 D: 13577
http://tests.stockfishchess.org/tests/view/5cffbccd0ebc5925cf09a154

LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 28428 W: 4873 L: 4765 D: 18790
http://tests.stockfishchess.org/tests/view/5d0015f60ebc5925cf09acb1

Bench: 3897263