Use (strict) greater-than-operator for 'improving'

Currently on a normal bench run in ~0,7% of cases 'improving' is set to
true although the static eval isn't improving at all, just keeping
equal. It looks like the strict gt-operator is more appropriate here,
since it returns to 'improving' its literal meaning without sideffects.

STC {-1.00,3.00} failed yellow:
https://tests.stockfishchess.org/tests/view/5e1ec38c8fd5f550e4ae1c28
LLR: -2.93 (-2.94,2.94) {-1.00,3.00}
Total: 53155 W: 10170 L: 10109 D: 32876
Ptnml(0-2): 863, 6282, 12251, 6283, 892

non-regression LTC passed:
https://tests.stockfishchess.org/tests/view/5e1f1c0d8fd5f550e4ae1c41
LLR: 2.98 (-2.94,2.94) {-1.50,0.50}
Total: 23961 W: 3114 L: 3018 D: 17829
Ptnml(0-2): 163, 2220, 7114, 2298, 170

CLoses https://github.com/official-stockfish/Stockfish/pull/2496

bench: 4561386

Minor fixes for misc.cpp

Fixes conflict with tune.h STRINGIFY macro.

No functional change

Use a std::bitset for KPKBitbase

This is a non-functional simplification. Looks like std::bitset works good
for the KPKBitbase. Thanks for Jorg Oster for helping get the speed up
(the [] accessor is faster than test()).

Speed testing: 10k calls to probe:
  master 9.8 sec
  patch 9.8 sec.

STC
LLR: 2.94 (-2.94,2.94) {-1.50,0.50}
Total: 100154 W: 19025 L: 18992 D: 62137
Ptnml(0-2): 1397, 11376, 24572, 11254, 1473
http://tests.stockfishchess.org/tests/view/5e21e601346e35ac603b7d2b

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

No functional change

Determine opposite colors mathematically

This is a non-functional speed-up: master has to access SquareBB twice while this patch
determines opposite_colors just using the values of the squares. It doesn't seem to change
the overall speed of bench, but calling opposite_colors(...) 10 Million times:

master: 39.4 seconds
patch: 11.4 seconds.

The only data point I have (other than my own tests), is a quite old failed STC test:
LLR: -2.93 (-2.94,2.94) [-1.50,4.50]
Total: 24308 W: 5331 L: 5330 D: 13647
Ptnml(0-2): 315, 2577, 6326, 2623, 289
http://tests.stockfishchess.org/tests/view/5e010256c13ac2425c4a9a67

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

No functional change

Simplify KPK classify

This is a non-functional simplification. If we use the "side to move" of the entry
instead of the template, one of the classify methods goes away. Furthermore, I've
resolved  the colors in some of the statements (we're already assuming direction
using NORTH), and used stm (side to move) instead of "us," since this is much clearer
to me.

This is not tested because it is non-functional, only applies building the bitbase
and there are no changes to the binary (on my machine).

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

No functional change

Simplify signature of remove_piece()

This is a non-functional simplification. Instead of passing the piece type
for remove_piece, we can rely on the board. The only exception is en-passant
which must be explicitly set because the destination square for the capture
is not the same as the piece to remove.

Verified also in the Chess960 castling case by running a couple of perft, see
the pull request discussion: https://github.com/official-stockfish/Stockfish/pull/2460

STC
LLR: 2.94 (-2.94,2.94) [-3.00,1.00]
Total: 18624 W: 4147 L: 4070 D: 10407
Ptnml(0-2): 223, 1933, 4945, 1938, 260
http://tests.stockfishchess.org/tests/view/5dfeaa93e70446e17e451163

No functional change

Restore development version

No functional change

Stockfish 11

Official release version of Stockfish 11.

Bench: 5156767

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

It is our pleasure to release Stockfish 11 to our fans and supporters.

Downloads are freely available at http://stockfishchess.org/download/

This version 11 of Stockfish is 50 Elo stronger than the last version, and
150 Elo stronger than the version which famously lost a match to AlphaZero
two years ago. This makes Stockfish the strongest chess engine running on
your smartphone or normal desktop PC, and we estimate that on a modern four
cores CPU, Stockfish 11 could give 1:1000 time odds to the human chess champion
having classical time control, and be on par with him. More specific data,
including nice cumulative curves for the progression of Stockfish strength
over the last seven years, can be found on [our progression page][1], at
[Stefan Pohl site][2] or at [NextChessMove][3].

In October 2019 Stockfish has regained its crown in the TCEC competition,
beating in the superfinal of season 16 an evolution of the neural-network
engine Leela that had won the previous season. This clash of style between an
alpha-beta and an neural-network engine produced spectacular chess as always,
with Stockfish [emerging victorious this time][0].

Compared to Stockfish 10, we have made hundreds of improvements to the
[codebase][4], from the evaluation function (improvements in king attacks,
middlegame/endgame transitions, and many more) to the search algorithm (some
innovative coordination methods for the searching threads, better pruning of
unsound tactical lines, etc), and fixed a couple of bugs en passant.

Our testing framework [Fishtest][5] has also seen its share of improvements
to continue propelling Stockfish forward. Along with a lot of small enhancements,
Fishtest has switched to new SPRT bounds to increase the chance of catching Elo
gainers, along with a new testing book and the use of pentanomial statistics to
be more resource-efficient.

Overall the Stockfish project is an example of open-source at its best, as
its buzzing community of programmers sharing ideas and daily reviewing their
colleagues' patches proves to be an ideal form to develop innovative ideas for
chess programming, while the mathematical accuracy of the testing framework
allows us an unparalleled level of quality control for each patch we put in
the engine. If you wish, you too can help our ongoing efforts to keep improving
it, just [get involved][6] :-)

Stockfish is also special in that every chess fan, even if not a programmer,
[can easily help][7] the team to improve the engine by connecting their PC to
Fishtest and let it play some games in the background to test new patches.
Individual contributions vary from 1 to 32 cores, but this year Bojun Guo
made it a little bit special by plugging a whole data center during the whole
year: it was a vertiginous experience to see Fishtest spikes with 17466 cores
connected playing [25600 games/minute][8]. Thanks Guo!

The Stockfish team

[0]: <http://mytcecexperience.blogspot.com/2019/10/season-16-superfinal-games-91-100.html>
[1]: <https://github.com/glinscott/fishtest/wiki/Regression-Tests>
[2]: <https://www.sp-cc.de/index.htm>
[3]: <https://nextchessmove.com/dev-builds>
[4]: <https://github.com/official-stockfish/Stockfish>
[5]: <https://tests.stockfishchess.org/tests>
[6]: <https://stockfishchess.org/get-involved/>
[7]: <https://github.com/glinscott/fishtest/wiki>
[8]: <https://groups.google.com/forum/?fromgroups=#!topic/fishcooking/lebEmG5vgng%5B1-25%5D>

Update Readme.md for the compiler command

No functional change

Tweak late move reductions at root

More LMR at root, unless a fail low might happen.

passed STC:
 LLR: 2.94 (-2.94,2.94) {-1.00,3.00}
Total: 25428 W: 4960 L: 4789 D: 15679
Ptnml(0-2): 424, 2948, 5832, 3045, 460
http://tests.stockfishchess.org/tests/view/5e1c9afed12216a2857e6401

passed LTC:
 LLR: 2.94 (-2.94,2.94) {0.00,2.00}
Total: 187423 W: 24253 L: 23599 D: 139571
Ptnml(0-2): 1284, 17437, 55536, 18085, 1292
http://tests.stockfishchess.org/tests/view/5e1ceb9975be933c8fe635a3

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

Bench: 5156767

Tweak reductions for captures/promotions

From the third move reduce captures and promotions more if remaining depth is low.

STC:
LLR: 2.94 (-2.94,2.94) {-1.00,3.00}
Total: 25218 W: 5008 L: 4837 D: 15373
Ptnml(0-2): 439, 2950, 5717, 3001, 499
http://tests.stockfishchess.org/tests/view/5e1b33abd12216a2857e6359

LTC:
LLR: 2.95 (-2.94,2.94) {0.00,2.00}
Total: 35491 W: 4760 L: 4524 D: 26207
Ptnml(0-2): 264, 3288, 10413, 3460, 294
http://tests.stockfishchess.org/tests/view/5e1b88d5d12216a2857e6385

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

Bench: 4979757

Tweak futility pruning constants

Based on recent improvement of futility pruning by @locutus2 : we lower
the futility margin to apply it for more nodes but as a compensation
we also lower the history threshold to apply it to less nodes. Further
work in tweaking constants can always be done - numbers are guessed
"by hand" and are not results of some tuning, maybe there is some more
Elo to squeeze from this part of code.

Passed STC
LLR: 2.98 (-2.94,2.94) {-1.00,3.00}
Total: 15300 W: 3081 L: 2936 D: 9283
Ptnml(0-2): 260, 1816, 3382, 1900, 290
http://tests.stockfishchess.org/tests/view/5e18da3b27dab692fcf9a158

Passed LTC
LLR: 2.94 (-2.94,2.94) {0.00,2.00}
Total: 108670 W: 14509 L: 14070 D: 80091
Ptnml(0-2): 813, 10259, 31736, 10665, 831
http://tests.stockfishchess.org/tests/view/5e18fc9627dab692fcf9a180

Bench: 4643972

Fix previous patch in case of ponder

No functional change

Smarter time management near stop limit

This patch makes Stockfish search same depth again if > 60% of optimum time is
already used, instead of trying the next iteration. The idea is that the next
iteration will generally take about the same amount of time as has already been
used in total. When we are likely to begin the last iteration, as judged by total
time taken so far > 0.6 * optimum time, searching the last depth again instead of
increasing the depth still helps the other threads in lazy SMP and prepares better
move ordering for the next moves.

STC :
LLR: 2.95 (-2.94,2.94) {-1.00,3.00}
Total: 13436 W: 2695 L: 2558 D: 8183
Ptnml(0-2): 222, 1538, 3087, 1611, 253
https://tests.stockfishchess.org/tests/view/5e1618a761fe5f83a67dd964

LTC :
LLR: 2.94 (-2.94,2.94) {0.00,2.00}
Total: 32160 W: 4261 L: 4047 D: 23852
Ptnml(0-2): 211, 2988, 9448, 3135, 247
https://tests.stockfishchess.org/tests/view/5e162ca061fe5f83a67dd96d

The code was revised as suggested by @vondele for multithreading:

STC (8 threads):
LLR: 2.95 (-2.94,2.94) {0.00,2.00}
Total: 16640 W: 2049 L: 1885 D: 12706
Ptnml(0-2): 119, 1369, 5158, 1557, 108
https://tests.stockfishchess.org/tests/view/5e19826a2cc590e03c3c2f52

LTC (8 threads):
LLR: 2.95 (-2.94,2.94) {-1.00,3.00}
Total: 16536 W: 2758 L: 2629 D: 11149
Ptnml(0-2): 182, 1758, 4296, 1802, 224
https://tests.stockfishchess.org/tests/view/5e18b91a27dab692fcf9a140

Thanks to those discussing Stockfish lazy SMP on fishcooking which made me
try this, and to @vondele for suggestions and doing related tests.

See full discussion in the pull request thread:
https://github.com/official-stockfish/Stockfish/pull/2482

Bench: 4586187

Show compiler info at startup

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

Usage:

```
./stockfish
compiler
```

Example of output:

```
Stockfish 120120 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

Update Elo estimates for terms in search

This updates estimates from 1.5 year ago, and adds missing terms. All estimates
from tests run on fishtest at 10+0.1 (STC), 20000 games, error bars +- 3 Elo,
see the original message in the pull request for the full list of tests.
Noteworthy changes are step 7 (futility pruning) going from ~30 to ~50 Elo
and step 13 (pruning at shallow depth) going from ~170 to ~200 Elo.

Full list of tests: https://github.com/official-stockfish/Stockfish/pull/2401

@Rocky640 made the suggestion to look at time control dependence of these terms.
I picked two large terms (early futility pruning and singular extension), so with
small relative error. It turns out it is actually quite interesting (see figure 1).
Contrary to my expectation, the Elo gain for early futility pruning is pretty time
control sensitive, while singular extension gain is not.

Figure 1: TC dependence of two search terms

Going back to the old measurement of futility pruning (30 Elo vs today 50 Elo),
the code is actually identical but the margins have changed. It seems like a nice
example of how connected terms in search really are, i.e. the value of early futility
pruning increased significantly due to changes elsewhere in search.

No functional change.

Rewrite initialization of PseudoMoves

This is a non-functional code style change. I believe master is a bit convoluted
here and propose this version for clarity.

No functional change

Assorted trivial cleanups January 2020

Assorted trivial cleanups.

No functional change

50-moves rule improvement for transposition table

User "adentong" reported recently of a game where Stockfish blundered a game
in a tournament because during a search there was an hash-table issue for
positions inside the tree very close to the 50-moves draw rule. This is part
of a problem which is commonly referred to as the Graph History Interaction (GHI),
and is difficult to solve in computer chess because storing the 50-moves counter
in the hash-table loses Elo in general.

Links:
Issue 2451    : https://github.com/official-stockfish/Stockfish/issues/2451
About the GHI : https://www.chessprogramming.org/Graph_History_Interaction

This patch tries to address the issue in this particular game and similar
reported games: it prevents that values from the transposition table are
getting used when the 50-move counter is close to reaching 100 (). The idea
is that in such cases values from previous searches, with a much lower 50-move
count, become less and less reliable.

More precisely, the heuristic we use in this patch is that we don't take the
transposition table cutoff  when we have reached a 45-moves limit, but let the
search continue doing its job. There is a possible slowdown involved, but it will
also help to find either a draw when it thought to be losing, or a way to avoid
the draw by 50-move rule. This heuristics probably will not fix all possible cases,
but seems to be working reasonably well in practice while not losing too much Elo.

Passed non-regression tests:
STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 274452 W: 59700 L: 60075 D: 154677
http://tests.stockfishchess.org/tests/view/5df546116932658fe9b451bf

LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 95235 W: 15297 L: 15292 D: 64646
http://tests.stockfishchess.org/tests/view/5df69c926932658fe9b4520e

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

Bench: 4586187

Update lists of authors and contributors

Preparing for version 11 of Stockfish: update lists of authors,
contributors giving CPU time to the fishtest framework, etc.

No functional change

Tuned nullmove search

Tuning was done with Bayesian optimisation and sequential use of gaussian process
regressor and gaussian process classifier. The latter is used in lieu of ordinal
categorical modelling. Details will be given in Fishcooking forum topic: https://groups.google.com/forum/?fromgroups=#!topic/fishcooking/b3uhBBJcJG4

STC:
LLR: 2.96 (-2.94,2.94) {-1.00,3.00}
Total: 10248 W: 2361 L: 2233 D: 5654
Ptnml(0-2): 191, 1153, 2303, 1276, 194
http://tests.stockfishchess.org/tests/view/5e0ba4159d3fbe26f672d4e6

LTC:
LLR: 2.94 (-2.94,2.94) {0.00,2.00}
Total: 16003 W: 2648 L: 2458 D: 10897
Ptnml(0-2): 121, 1595, 4394, 1718, 153
http://tests.stockfishchess.org/tests/view/5e0bb8519d3fbe26f672d4fd

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

Bench 4747984

Introduce king infiltration bonus

Add king infiltration bonus to initiative calculation. Idea is somewhat similar
to outflanking - endgames are hard to win if each king is on it side of the board.
So this adds extra bonus for one of kings crossing the middle line.

STC
LLR: 2.94 (-2.94,2.94) {-1.00,3.00}
Total: 10533 W: 2372 L: 2242 D: 5919
Ptnml(0-2): 196, 1198, 2352, 1316, 202
http://tests.stockfishchess.org/tests/view/5e0e6fd1e97ea42ea89da9b3

LTC
LLR: 2.96 (-2.94,2.94) {0.00,2.00}
Total: 15074 W: 2563 L: 2381 D: 10130
Ptnml(0-2): 118, 1500, 4111, 1663, 129
http://tests.stockfishchess.org/tests/view/5e0e857ae97ea42ea89da9cc

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

Bench: 5146339

Tweak futility pruning

Exclude moves with a good history total from futility pruning. This adds
a condition for quiet futility pruning: history total has to be low.

STC:
LLR: 2.94 (-2.94,2.94) {-1.00,3.00}
Total: 20095 W: 4503 L: 4342 D: 11250
Ptnml(0-2): 362, 2380, 4422, 2486, 388
http://tests.stockfishchess.org/tests/view/5e0d7c5387585b1706b68370

LTC:
LLR: 2.94 (-2.94,2.94) {0.00,2.00}
Total: 53016 W: 8587 L: 8302 D: 36127
Ptnml(0-2): 353, 5397, 14751, 5545, 423
http://tests.stockfishchess.org/tests/view/5e0e30d062fb773bb7047e95

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

Bench: 5215200

Use a faster implementation of Static Exchange Evaluation

SEE (Static Exchange Evaluation) is a critical component, so we might
indulge some tricks to make it faster. Another pull request #2469 showed
some speedup by removing templates, this version uses Ronald de Man
(@syzygy1) SEE implementation which also unrolls the for loop by
suppressing the min_attacker() helper function and exits as soon as
the last swap is conclusive.

See Ronald de Man version there:
https://github.com/syzygy1/Cfish/blob/master/src/position.c

Patch testes against pull request #2469:
LLR: 2.95 (-2.94,2.94) {-1.00,3.00}
Total: 19365 W: 3771 L: 3634 D: 11960
Ptnml(0-2): 241, 1984, 5099, 2092, 255
http://tests.stockfishchess.org/tests/view/5e10eb135e5436dd91b27ba3

And since we are using new SPRT statistics, and that both pull requests
finished with less than 20000 games I also tested against master as
a speed-up:

LLR: 2.99 (-2.94,2.94) {-1.00,3.00}
Total: 18878 W: 3674 L: 3539 D: 11665
Ptnml(0-2): 193, 1999, 4966, 2019, 250
http://tests.stockfishchess.org/tests/view/5e10febf12ef906c8b388745

Non functional change

Update Readme.md

Update fishtest server URL, fix a broken wiki link, fix a typo.

Tune search constants

STC failed red :
LLR: -2.95 (-2.94,2.94) [0.00,3.50]
Total: 41667 W: 9094 L: 9138 D: 23435
https://tests.stockfishchess.org/tests/view/5df7bb566932658fe9b45253

LTC failed yellow :
LLR: -2.96 (-2.94,2.94) [0.00,3.50]
Total: 113667 W: 18330 L: 18196 D: 77141
https://tests.stockfishchess.org/tests/view/5df562386932658fe9b451c7

VLTC turned green :
LLR: 2.95 (-2.94,2.94) [0.00,3.50]
Total: 128630 W: 17747 L: 17273 D: 93610
https://tests.stockfishchess.org/tests/view/5df9054dcde01bf360ab78db

Bench 5180012

Refine improving-logic

Don't rely on the assumption that we are improving after surviving a
check. Instead, compare with the static eval of 2 moves before.

STC
https://tests.stockfishchess.org/tests/view/5dedfd7f3cff9a249bb9e44d
LLR: 2.95 (-2.94,2.94) [-1.50,4.50]
Total: 38859 W: 8621 L: 8397 D: 21841

LTC
https://tests.stockfishchess.org/tests/view/5dee1b5a3cff9a249bb9e465
LLR: 2.95 (-2.94,2.94) [0.00,3.50]
Total: 51130 W: 8308 L: 7996 D: 34826

Bench: 5371271

Tuned razor and futility margins

Tuning was done with Bayesian optimisation with the following parameters:
Acquisition function: Expected Improvement
alpha: 0.05
xi: 1e-4
TC: 60+0.6
Number of iterations: 100
Initial points: 5
Batch size: 20 games

STC
http://tests.stockfishchess.org/tests/view/5dee291e3cff9a249bb9e470
LLR: 2.97 (-2.94,2.94) [-1.50,4.50]
Total: 19586 W: 4382 L: 4214 D: 10990

LTC
http://tests.stockfishchess.org/tests/view/5dee4e273cff9a249bb9e473
LLR: 2.95 (-2.94,2.94) [0.00,3.50]
Total: 38840 W: 6315 L: 6036 D: 26489

Bench: 5033242

TrappedRook value and King positional tables

Small tweak to increase the TrappedRook penalty. Nice idea by Alain Savard!

STC
LLR: 2.96 (-2.94,2.94) [-1.50,4.50]
Total: 36977 W: 8212 L: 7993 D: 20772
https://tests.stockfishchess.org/tests/view/5dee1c1e3cff9a249bb9e46d

LTC
LLR: 2.95 (-2.94,2.94) [0.00,3.50]
Total: 36395 W: 6070 L: 5795 D: 24530
https://tests.stockfishchess.org/tests/view/5dee90153cff9a249bb9e479

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

Bench: 5176990

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

Comments by Alain Savard:

For the record, the idea was to run an experimental tuning with disabled
castling in the hope to get more hits on the TrappedRook and the king in
the c1- f1-f2-c2 area
http://tests.stockfishchess.org/tests/view/5dec57be51219d7befdc76e1

A first interpretation of that tuning was green STC (0, 4) and yellow LTC (0, 4):
http://tests.stockfishchess.org/tests/view/5ded04bc51219d7befdc773a
http://tests.stockfishchess.org/tests/view/5ded1e7a51219d7befdc7760

Thank you @xoto for trying this. Indeed, because the tuned Kc2 and Kf2 values
were quite different, it was a good idea to try something more neutral.

Exclude blockers for king from mobility area

This patch excludes blockers for king from mobility area. It was tried a couple
of times by now but now it passed. Performance is not enormously good but this
patch makes a lot of sence - blockers for king can't really move until king moves
(in most cases) so logic behind it is the same as behind excluding king square
from mobility area.

STC
http://tests.stockfishchess.org/tests/view/5dec388651219d7befdc76be
LLR: 2.95 (-2.94,2.94) [-1.50,4.50]
Total: 6155 W: 1428 L: 1300 D: 3427

LTC
http://tests.stockfishchess.org/tests/view/5dec4a3151219d7befdc76d3
LLR: 2.95 (-2.94,2.94) [0.00,3.50]
Total: 120800 W: 19636 L: 19134 D: 82030

Bench: 5173081

Do last capture extensions for every single node

This patch simplifies latest @MJZ1977 elo gainer. Seems like PvNode check in
condition of last capture extension is not needed. Note - even if this is a
simplification it actually causes this extension to be applied more often, thus
strengthening effect of @MJZ1977's patch.

passed STC
http://tests.stockfishchess.org/tests/view/5deb9a3eb7bdefd50db28d0e
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 80244 W: 17421 L: 17414 D: 45409

passed LTC
http://tests.stockfishchess.org/tests/view/5deba860b7bdefd50db28d11
LLR: 2.94 (-2.94,2.94) [-3.00,1.00]
Total: 21506 W: 3565 L: 3446 D: 14495

Bench: 5097036

Simplify pruning moves with negative SEE

This patch simplifies pruning moves with negative SEE values.

STC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 18847 W: 4211 L: 4084 D: 10552
http://tests.stockfishchess.org/tests/view/5de983f2caa7c610e4d1866e

LTC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 25556 W: 4200 L: 4087 D: 17269
http://tests.stockfishchess.org/tests/view/5de99e21caa7c610e4d18676

Bench 5390930

Fix output of PV lines with invalid scores #2439

As reported on the forum it is possible, on very rare occasions, that we are
trying to print a PV line with an invalid previousScore, although this line
has a valid actual score. This patch fixes output of PV lines with invalid
scores in a MultiPV search. This is a follow-up patch to 8b15961 and makes
the fix finally complete.

The reason is the i <= pvIdx condition which probably is a leftover from the
times there was a special root search function. This check is no longer needed
today and prevents PV lines past the current one (current pvIdx) to be flagged
as updated even though they do have a valid score.

https://github.com/official-stockfish/Stockfish/commit/8b15961349e18a9ba113973c53f53913d0cd0fad
https://groups.google.com/forum/?fromgroups=#!topic/fishcooking/PrnoDLvMvro

No functional change.

Tweak time management (failing eval)

Adjust fallingEval with score change in last 5 iterations. FallingEval adjusts
the time used on a move depending on whether the position score is better or
worse than on the previous move. This change adds a dependency on the score
change in the last 5 iterations of the current search.

Tests with original code:
STC :
LLR: 2.97 (-2.94,2.94) [-1.50,4.50]
Total: 18728 W: 4170 L: 4005 D: 10553
https://tests.stockfishchess.org/tests/view/5de68a5bb407ee7bfda68a94

LTC :
LLR: 2.95 (-2.94,2.94) [0.00,3.50]
Total: 180217 W: 29214 L: 28551 D: 122452
https://tests.stockfishchess.org/tests/view/5de690a4b407ee7bfda68a9a

Revised code using a simple array instead of a deque and different values
gave a slightly quicker pass at LTC. The merged patch now uses this:

STC :
LLR: 2.96 (-2.94,2.94) [-1.50,4.50]
Total: 18616 W: 4114 L: 3950 D: 10552
https://tests.stockfishchess.org/tests/view/5debb790b7bdefd50db28d14

LTC :
LLR: 2.96 (-2.94,2.94) [0.00,3.50]
Total: 134151 W: 21729 L: 21191 D: 91231
https://tests.stockfishchess.org/tests/view/5debc13fb7bdefd50db28d19

No functional change

Remove unneeded & incorrect check.

the removed line is not needed, since with the conditions on SE, eval
equals ttValue (except inCheck), which must be larger than beta if the second condition
is true.

The removed line is also incorrect as eval might be VALUE_NONE at this
location if inCheck. This removal addresses part of https://github.com/official-stockfish/Stockfish/pull/2406#issuecomment-552642608

No functional change.

The sudo tag is deprecated in Travis CI

Reported by Christian Clauss. Thanks!

No functional change

UnblockedStorm tuned

STC
http://tests.stockfishchess.org/tests/view/5de155980294ec4750cba9bd
LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 60206 W: 13295 L: 12895 D: 34016

LTC
http://tests.stockfishchess.org/tests/view/5de22f6f0294ec4750cba9e7
LLR: 2.95 (-2.94,2.94) [0.00,3.50]
Total: 182005 W: 29571 L: 28902 D: 123532

VLTC
http://tests.stockfishchess.org/tests/view/5de4adca5e868d334be516c1
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 42101 W: 6068 L: 5978 D: 30055

Bench: 5122362

King proximity tweak for passed pawns

Decrease slightly the penalty for opponent king distance to passed pawn.
Instead of 5:2 ratio (or 20:8) we now have 19:8

STC
http://tests.stockfishchess.org/tests/view/5de281b2727dc1d26718a673
LLR: 2.95 (-2.94,2.94) [-1.50,4.50]
Total: 28638 W: 6297 L: 6104 D: 16237

LTC
http://tests.stockfishchess.org/tests/view/5de2a2ff727dc1d26718a67b
LLR: 2.95 (-2.94,2.94) [0.00,3.50]
Total: 59586 W: 9766 L: 9429 D: 40391

Where to go from here:
Further tests will try a similar tweak on the friendly king proximity penalty,
because recent experiments indicate that this penalty is quite sensitive,
but I wanted to try first on the larger term.

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

bench: 5258928

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

Increasing the penalty ratio to 21:8 was neutral.
http://tests.stockfishchess.org/tests/view/5de2814d727dc1d26718a671

Decreasing the penalty ratio a bit more to 9:4 seems less promising
http://tests.stockfishchess.org/tests/view/5de2f4c2727dc1d26718a691
http://tests.stockfishchess.org/tests/view/5de32ecc727dc1d26718a6b0

Extend bench to static evaluations

this patch extends bench to print static evaluations.

./stockfish bench 16 1 1 filename eval

will now print the evaluations for all fens in the file.

This complements the various 'go' flavors for bench and might be useful for debugging and/or tuning.

No functional change.

Simplify king danger

This patch is a cleanup/simplification of king flank defenders patch,
removing king flanks attacks linear dependance in kingdanger. Result
of experiments with quadratic kingflank defenders scaling. Rebased on
the latest master.

passed STC
http://tests.stockfishchess.org/tests/view/5ddc2b99e0b4af579302bacf
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 19660 W: 4309 L: 4184 D: 11167

passed LTC
http://tests.stockfishchess.org/tests/view/5ddc3168e0b4af579302bade
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 24362 W: 3974 L: 3859 D: 16529

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

bench 5742013

Extend last non-pawn captures

Extend last non-pawn captures at principal variation nodes because
they are in general decisive moves with clear endgame result.

STC
http://tests.stockfishchess.org/tests/view/5ddafc86e75c0005326d2140
LLR: 2.96 (-2.94,2.94) [-1.50,4.50]
Total: 9892 W: 2238 L: 2099 D: 5555

LTC
http://tests.stockfishchess.org/tests/view/5ddb0401e75c0005326d2150
LLR: 2.95 (-2.94,2.94) [0.00,3.50]
Total: 30369 W: 5013 L: 4756 D: 20600

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

Bench: 5059526

King danger: retire attacked-by-bishop defense

In a recent commit, "Introduce king flank defenders," a term was introduced
by Michael Chaly (@Vizvezdenec) to reduce king danger based on king defenders,
i.e., friendly attacks on our King Flank and Camp. This is a powerful idea
and broadly applicable to all of our pieces.

An earlier, but narrower, version of a similar idea was already coded into
king danger, with a term reducing king danger simply if we had a bishop and
king attacking the same square -- there is also a similar term for knights,
but roughly three times larger. I had attempted to tweak this term's coefficient
fairly recently, in a series of tests in early September which increased this
coefficient.  All failed STC with significantly negative scores.

Now that the king flank defenders term has been introduced, it appears that
the bishop-defense term can be simplified away without compensation or
significant Elo loss.

Where do we go from here? This PR is a natural follow-up to "Introduce king
flank defenders," which proposed simplification with existing and overlapping
terms, such as this one.  That PR also mentioned that the coefficient it
introduced appeared arbitrary, so perhaps this PR can facilitate a tweak to
increase king flank defenders' coefficient.

Additionally, this pull request is extremely similar to https://github.com/official-stockfish/Stockfish/pull/1821,
which was (coincidentally) merged a year ago, to the day (November 23, 2018).
That patch also simplified away a linear king danger tropism term, which was
soon after replaced with a quadratic term by @Vizvezdenec (which would not have
passed without the simplification).  @Vizvezdenec, again by coincidence, has
recently been trying to implement a quadratic term, this time for defenders
rather than attackers.  This history of this evaluation code suggests that
this simplification might be enough to help a patch for quadratic king-flank
defenders pass.

Bench: 4959670

STC:
LLR: 2.94 (-2.94,2.94) [-3.00,1.00]
Total: 22209 W: 4920 L: 4800 D: 12489
https://tests.stockfishchess.org/tests/view/5dd444d914339111b9b6bed7

LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 152107 W: 24658 L: 24743 D: 102706
https://tests.stockfishchess.org/tests/view/5dd4be31f531e81cf278ea9d

Interesting discussion on Github about this pull request:
https://github.com/official-stockfish/Stockfish/pull/2424

---

This pull request was opened less than one week before the holiday of
Thanksgiving here in the United States.  In keeping with the holiday
tradition of expressing gratitude, I would like to thank our generous
CPU donors, talented forum contributors, innovative developers, speedy
fishtest approvers, and especially our hardworking server maintainers
(@ppigazzini and @tomtor). Thank you all for a year of great Stockfish
progress!

Simplify endgame factor for opposite colored bishops

Stockfish is continually improving. Patches that gain elo in the past may
no longer be needed as stockfish improved elsewhere. This patch removes
passed pawns count dependence in opposite colored bishops scale factor.
We used the mean of passed count pawns (~1.4) to compensate, and changed
the base value from 16 to 22.

Passed STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 57879 W: 12657 L: 12607 D: 32615
http://tests.stockfishchess.org/tests/view/5dd1644f42928ff08153dc1e

Passed LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 121648 W: 19622 L: 19659 D: 82367
http://tests.stockfishchess.org/tests/view/5dd24572ccb823d41d4b47bb

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

Bench: 5067864

Do lmr for more captures

Based on machinery introduced by vondele. Logic behind patch if relatively simple -
if we reduce less with high hit rate of transposition table somewhat logical is to
reduce more with low hit rate. For example enable all captures for LMR.

Threshold 0.375 is arbitrary and can be tweaked :)

STC
http://tests.stockfishchess.org/tests/view/5dd4d51df531e81cf278eaac
LLR: 2.97 (-2.94,2.94) [-1.50,4.50]
Total: 16495 W: 3591 L: 3434 D: 9470

LTC
http://tests.stockfishchess.org/tests/view/5dd52265f531e81cf278eace
LLR: 2.96 (-2.94,2.94) [0.00,3.50]
Total: 23598 W: 3956 L: 3716 D: 15926

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

Bench: 5067870

Outpost Endgame values

Remove the recent rank based Outpost array by using a weighted average value
computed using a frequency analysis by rank from a large set of middle game
positions.

The higher eg values introduced by the new Outpost array (which were about
twice the previous masters) are thus preserved.

STC
http://tests.stockfishchess.org/tests/view/5dd05c870ebc5902579e1f7f
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 42466 W: 9232 L: 9151 D: 24083

LTC
http://tests.stockfishchess.org/tests/view/5dd146e342928ff08153dab1
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 66968 W: 10921 L: 10873 D: 45174

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

Bench: 5103360

Simplify advanced pawn push pruning

This patch simplifies away all conditions related to advanced pawn pushes
in shallow depth pruning. Idea is based on fact that in master we have
advanced pawn pushes not being pruned what we are only in PV node and
when non-pawn material of opponent is > Bishop, so pretty rarely. With
this patch we will have all pruning heuristics working for this moves as
for every other move.

STC
LLR: 2.94 (-2.94,2.94) [-3.00,1.00]
Total: 159143 W: 34271 L: 34418 D: 90454
http://tests.stockfishchess.org/tests/view/5dcdb3110ebc5902563249d7

LTC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 63900 W: 10375 L: 10322 D: 43203
http://tests.stockfishchess.org/tests/view/5dd05e820ebc5902579e1fb8

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

bench 4897149

Use exploration rate for reductions

This patch measures how frequently search is exploring new configurations.
This is done be computing a running average of ttHit. The ttHitAverage rate
is somewhat low (e.g. 30% for startpos) in the normal case, while it can be
very high if no progress is made (e.g. 90% for the fortress I used for testing).

This information can be used to influence search. In this patch, by adjusting
reductions if the rate > 50%. A first version (using a low ttHitAverageResolution
and this 50% threshold) passed  testing:

STC
LLR: 2.96 (-2.94,2.94) [-1.50,4.50]
Total: 26425 W: 5837 L: 5650 D: 14938
http://tests.stockfishchess.org/tests/view/5dcede8b0ebc5902563258fa

LTC
LLR: 2.96 (-2.94,2.94) [0.00,3.50]
Total: 32313 W: 5392 L: 5128 D: 21793
http://tests.stockfishchess.org/tests/view/5dcefb1f0ebc590256325c0e

However, as discussed in pull request 2414, using a larger ttHitAverageResolution
gives a better approximation of the underlying distributions. This needs a slight
adjustment for the threshold as the new distributions are shifted a bit compared
to the older ones, and this threshold seemingly is sensitive (we used 0.53125 here).
https://github.com/official-stockfish/Stockfish/pull/2414

This final version also passed testing, and is used for the patch:

STC
LLR: 2.95 (-2.94,2.94) [-1.50,4.50]
Total: 16025 W: 3555 L: 3399 D: 9071
http://tests.stockfishchess.org/tests/view/5dd070b90ebc5902579e20c2

LTC
LLR: 2.96 (-2.94,2.94) [0.00,3.50]
Total: 37576 W: 6277 L: 5998 D: 25301
http://tests.stockfishchess.org/tests/view/5dd0f58e6f544e798086f224

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

Bench: 4989584

Introduce king flank defenders

This patch implements what we have been trying for quite some time -
dependance of kingdanger on balance of attackers and defenders of king
flank, to avoid overestimate attacking power if the opponent has enough
defenders of king position. We already have some form of it in bishop
and knight defenders - this is further work in this direction.

What to do based on this?

1) constant 4 is arbitrary, maybe it is not optimal
2) maybe we can use quadratic formula as in kingflankattack
3) simplification into alrealy existing terms is always a possibility :)
4) overall kingdanger tuning always can be done.

passed STC:
http://tests.stockfishchess.org/tests/view/5dcf40560ebc590256325f30
LLR: 2.96 (-2.94,2.94) [-1.50,4.50]
Total: 26298 W: 5819 L: 5632 D: 14847

passed LTC:
http://tests.stockfishchess.org/tests/view/5dcfa5760ebc590256326464
LLR: 2.96 (-2.94,2.94) [0.00,3.50]
Total: 30600 W: 5042 L: 4784 D: 20774

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

Bench: 4496847

Prune before extension

Switch execution order in search: do move pruning before extension detection.

STC:
LLR: 2.96 (-2.94,2.94) [-1.50,4.50]
Total: 5762 W: 1307 L: 1181 D: 3274
http://tests.stockfishchess.org/tests/view/5dcc56e90ebc59025bcbb833

LTC:
LLR: 2.96 (-2.94,2.94) [0.00,3.50]
Total: 72956 W: 11959 L: 11585 D: 49412
http://tests.stockfishchess.org/tests/view/5dcc62840ebc59025bcbb96f

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

Bench: 4532366

Rank-based outposts

Introduce OutpostRank[RANK_NB] which contains a bonus according to
the rank of the outpost. We use it for the primary Outpost bonus.
The values are based on the trends of the SPSA tuning run with some
manual tweaks.

Passed STC:
LLR: 2.96 (-2.94,2.94) [-1.50,4.50]
Total: 27454 W: 6059 L: 5869 D: 15526
http://tests.stockfishchess.org/tests/view/5dcadba20ebc590256922f09

Passed LTC:
LLR: 2.94 (-2.94,2.94) [0.00,3.50]
Total: 57950 W: 9443 L: 9112 D: 39395
http://tests.stockfishchess.org/tests/view/5dcaea880ebc5902569230bc

Bench: 4778405

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

The inspiration for this patch came from Stefan Geschwentner's attempt
of modifying BishopPawns into a rank-based penalty. Michael Stembera
suggested that maybe the S(0, 0) ranks (3rd, 7th and also maybe 8th)
can still be tuned. This would expand our definition of Outpost and
OutpostRanks would be removed altogether. Special thanks to Mark Tenzer
for all the help and excellent suggestions.

Shallow depth pruning on NonPV advanced pawn push

Usually advanced pawn pushes are not considered in shallow depth pruning
because it is risky to do so with possible promotions near the horizon.
However, this heuristic is not also beneficial on NonPV nodes since we
can afford to take slightly more risk on less important nodes.

STC:
LLR: 2.95 (-2.94,2.94) [-1.50,4.50]
Total: 54530 W: 11955 L: 11686 D: 30889
http://tests.stockfishchess.org/tests/view/5dc7dda30ebc5902ea57efd0

LTC:
LLR: 2.95 (-2.94,2.94) [0.00,3.50]
Total: 77336 W: 12786 L: 12399 D: 52151
http://tests.stockfishchess.org/tests/view/5dc8050d0ebc5902ea57f491

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

Bench: 4422068

Remove explicit moveCount pruning

The removed lines approximately duplicate equivalent logic in the movePicker.
Adjust the futility_move_count to componsate for some difference
(the movePicker prunes one iteration of the move loop later).

Passed STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 8114 W: 1810 L: 1663 D: 4641
http://tests.stockfishchess.org/tests/view/5dc6afe60ebc5902562bd318

Passed LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 89956 W: 14473 L: 14460 D: 61023
http://tests.stockfishchess.org/tests/view/5dc6bdcf0ebc5902562bd3c0

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

Bench: 4256440

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

How to continue from there?

It would be interesting to see if we can extract some Elo gain
from the new futility_move_count formula, for instance by somehow
incorporating the final -1 in the 5 constant, or adding a linear
term to the quadratics...

```
   futility_move_count = (5 + depth * depth) * (1 + improving) / 2 - 1
```

Sequencing tweak in tbprobe()

Followup of "issue" #2372, which was in fact a small speed-up
proposal by user @d3vv for the probing code of tablebases.

See comments on this issue where it was proven by Alin Savard that the
proposed change is more efficient on average than master on all type of
sequences it will usually be called.

Note that on gcc 4.3, this will produce a bogus warning which was solved
with ulterior gcc versions: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43949

Closes https://github.com/official-stockfish/Stockfish/issues/2372
Closes https://github.com/official-stockfish/Stockfish/pull/2379

Non functional change

Fix incorrect mate score.

Current master 648c7ec25db2040c0af34dd846dfa3f57af5ad0a will generate an
incorrect mate score for:

```
setoption name Hash value 8
setoption name Threads value 1
position fen 8/1p2KP2/1p4q1/1Pp5/2P5/N1Pp1k2/3P4/1N6 b - - 76 40
go depth 49
```
even though the position is a draw. Generally, SF tries to display only
proven mate scores, so this is a bug.

This was posted http://www.talkchess.com/forum3/viewtopic.php?f=2&t=72166
by Uri Blass, with the correct analysis that this must be related to the
50 moves draw rule being ignored somewhere.

Indeed, this is possible as positions and there eval are stored in the TT,
without reference to the 50mr counter. Depending on the search path followed
a position can thus be mate or draw in the TT (GHI or Graph history interaction).
Therefore, to prove mate lines, the TT content has to be used with care. Rather
than ignoring TT content in general or for mate scores (which impact search or
mate finding), it is possible to be more selective. In particular, @WOnder93
suggested to only ignore the TT if the 50mr draw ply is closer than the mate
ply. This patch implements this idea, by clamping the eval in the TT to
+-VALUE_MATED_IN_MAX_PLY. This retains the TTmove, but causes a research of
these lines (with the current 50mr counter) as needed.

This patch hardly ever affects search (as indicated by the unchanged
bench), but fixes the testcase. As the conditions are very specific,
also mate finding will almost never be less efficient (testing welcome).

It was also shown to pass STC and LTC non-regression testing, in a form
using if/then/else instead of ternary operators:

STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 93605 W: 15346 L: 15340 D: 62919
http://tests.stockfishchess.org/tests/view/5db45bb00ebc5908127538d4

LTC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 33873 W: 7359 L: 7261 D: 19253
http://tests.stockfishchess.org/tests/view/5db4c8940ebc5902d6b146fc

closes https://github.com/official-stockfish/Stockfish/issues/2370

Bench: 4362323

Revert "Rook PSQT Tuned"

This reverts the previous commit. The PSQT changes in this previous
commit originated from tests against quite an old version of master
which did not include the other PSQT changes of 474d133 for the other
pieces, and there might be some unknown interactions between the PSQT
tables. So we made a non-regression test of the last commit against the
last-but-one commit. This test failed, leading to the revert decision.

Failed non-regression test:
LLR: -2.96 (-2.94,2.94) [-3.00,1.00]
Total: 95536 W: 15047 L: 15347 D: 65142
http://tests.stockfishchess.org/tests/view/5dc0ba1d0ebc5904493b0112

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

Bench: 4362323

Rook PSQT Tuned

This patch uses about half the changes of the SPSA tuning run:
http://tests.stockfishchess.org/tests/view/5dba93d30ebc5925b64ed3bf

About a month ago, xoto10's patch raised the mg value of the third rank
center files from -1 to 7 to encourage rook lifts to the third rank. About
three days later, Rocky's patch lowered this value from 7 to 3. This patch
raises that again from 3 to 12 and ends up greater than the original rook
lift patch.

Passed STC:
LLR: 2.95 (-2.94,2.94) [-1.50,4.50]
Total: 104094 W: 22573 L: 22161 D: 59360
http://tests.stockfishchess.org/tests/view/5dbc77f20ebc5925b64ef1d0

Passed LTC:
LLR: 2.96 (-2.94,2.94) [0.00,3.50]
Total: 168291 W: 27410 L: 26777 D: 114104
http://tests.stockfishchess.org/tests/view/5dbd9f1e0ebc5925b64f0647

Bench: 4707799

Remove shuffle extension

It was noted in an earlier patch that all of the positions below needed the
Shuffle Detection idea to be solved:

3r4/p3r1pk/PpBb1pRp/1KpPpP1P/2P1P1R1/8/8/8 b - - 32 86
8/8/8/1k6/2p5/p1K5/N2B2r1/8 b - - 59 109
1r4k1/1r1bq3/4p1p1/3pPpPp/pNpN1P1P/P1PnQ3/1PK5/1R3R2 b - - 13 82
5k2/3b4/5p2/p1p1pPp1/PpPpP1Pp/1P1P3P/8/3R1K2 w - - 20 1

But Stockfish has envolved a bit since the Shuffle Detection patch introduction,
and this patch proves Stockfish is able to solves these drawn positions without it,
even on single core without EGTB.

Passed STC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 14231 W: 3114 L: 2978 D: 8139
http://tests.stockfishchess.org/tests/view/5dbe1a610ebc5925b64f09d9

Passed LTC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 42781 W: 6917 L: 6831 D: 29033
http://tests.stockfishchess.org/tests/view/5dbe24c20ebc5925b64f0a7a

Passed VLTC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 32556 W: 4573 L: 4469 D: 23514
http://tests.stockfishchess.org/tests/view/5dbec3830ebc5925b64f11aa

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

Bench: 4362323

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

Example of search by Michael Byrne for the FEN position:
q1B5/1P1q4/8/8/8/6R1/8/1K1k4 w - - 0 1

This position is win for white and the only moves that wins is Rg1 - all other moves
either draw or lose. With single core and 1024M hash, it is solved without shuffle
detection in 38 seconds on my machine (with no EGTB). This was the position that was
locked in a loop in the initial shuffle detection patch!

```
dep score nodes time (not shown:  tbhits knps seldep)
 50 +1.71  298.9M 2:43.63 Rg1+ Kd2 Rg2+ Kc3 Rc2+ Kb3 Rb2+ Kc3 Bxd7 Qf8 Ba4 Qb8 Bd1 Kd4 Rb5 Kc4 Be2+ Kc3 Rb6 Kd4 Bf3 Ke5 Kb2 Kf4 Bd1 Qe5+ Kb1 Qe4+ Ka2 Qd5+ Rb3 Qd2+ Ka3 Qc1+ Kb4 Qc7 Ka4 Qb8 Rb6 Ke5 Kb3 Qg8+ Kb4 Qf8+ Ka5 Qb8 Bb3 Kd4 Kb4 Qf8+ Ka4 Qb8 Ka5 K
<snip>
 49 +1.68  288.5M 2:38.35 Rg1+ Kd2 Rg2+ Kc3 Rc2+ Kb3 Rb2+ Kc3 Bxd7 Qf8 Ba4 Qb8 Bd1 Kd4 Rb5 Kc4 Be2+ Kc3 Rb6 Kd4 Bf3 Ke5 Kb2 Kf4 Bd1 Qe5+ Kb1 Qe4+ Ka2 Qd5+ Rb3 Qd2+ Ka3 Qc1+ Kb4 Qc7 Ka4 Qb8 Rb6 Ke5 Kb3 Qg8+ Kb4 Qf8+ Ka5 Qb8 Bb3 Kd4 Kb4 Ke3 Be6 Ke4 Bc4 Ke
<snip>
 48 +1.78  228.5M 2:01.93 Rg1+ Kd2 Rg2+ Kc3 Rc2+ Kb3 Rb2+ Kc3 Bxd7 Qf8 Ba4 Qb8 Bd1 Kd4 Rb5 Kc4 Be2+ Kc3 Rb6 Kd4 Bf3 Ke5 Kb2 Kf4 Bd1 Qe5+ Kb1 Qe4+ Ka2 Qd5+ Rb3 Qd2+ Ka3 Qa5+ Kb2 Qe5+ Ka2 Qb8 Rb5 Ke3 Kb1 Ke4 Bb3 Kf4 Be6 Ke3 Rb4 Kd3 Kb2 Ke3 Bd5 Qe5+ Kc2 Qh
<snip>
 46 +1.49  198.4M 1:44.89 Rg1+ Kd2 Rg2+ Kc3 Rc2+ Kb3 Rb2+ Kc3 Bxd7 Qf8 Ba4 Qb8 Bd1 Kd4 Rb5 Kc4 Be2+ Kc3 Rb6 Kd4 Bf3 Ke5 Kb2 Kf4 Bd1 Qe5+ Kb1 Qe4+ Ka2 Qd5+ Rb3 Qd2+ Ka3 Qc1+ Kb4 Qc7 Ka4 Qb8 Rb6 Qe8+ Rb5 Qb8 Bc2 Qa7+ Kb3 Qe3+ Kc4 Qe6+ Kb4 Qd6+ Kb3 Qb8 Rb4
<snip>
 45 +1.45  154.5M 1:20.75 Rg1+ Kd2 Rg2+ Kc3 Rc2+ Kb3 Rb2+ Kc3 Bxd7 Qf8 Ba4 Qb8 Bd1 Kd4 Rb5 Kc4 Be2+ Kc3 Rb6 Kd4 Bf3 Ke3 Bg2 Kd4 Rb5 Kc4 Bf1+ Kd4 Kb2 Qh2+ Kb3 Qg3+ Ka4 Qb8 Be2 Ke3 Bc4 Kf4 Kb4 Qd6+ Kc3 Qb8 Kc2 Ke4 Be6 Qh2+ Kb3 Qg3+ Ka4 Qb8 Bb3 Kd4 Bd5 Ke3
<snip>
 44 +1.36  141.9M 1:14.40 Rg1+ Kd2 Rg2+ Kc3 Rc2+ Kb3 Rb2+ Kc3 Bxd7 Qf8 Ba4 Qb8 Bd1 Qd6 Rc2+ Kd3 Be2+ Ke3 Rb2 Qb8 Bd1 Ke4 Rb5 Kd4 Bf3 Kc4 Be2+ Kc3 Rb6 Kd2 Bc4 Kc3 Bd5 Kd4 Bg2 Ke5 Kb2 Kd4 Rb5 Kc4 Bf1+ Kd4 Be2 Ke4 Bc4 Qh2+ Kb3 Qg3+ Ka4 Qb8 Bd5+ Kd4 Be6 Ke4
<snip>
 43 +1.36  134.1M 1:10.46 Rg1+ Kd2 Rg2+ Kc3 Rc2+ Kb3 Rb2+ Kc3 Bxd7 Qf8 Ba4 Qb8 Bd1 Qd6 Rc2+ Kd3 Be2+ Ke3 Rb2 Qb8 Bd1 Ke4 Rb5 Kd4 Bf3 Kc4 Be2+ Kc3 Rb6 Kd2 Bc4 Kc3 Be6 Kd4 Rb5 Kc3 Bf7 Kd4 Kb2 Ke4 Kb3 Kf4 Kc3 Ke4 Kb2 Qh2+ Kb3 Qg3+ Ka4 Qb8 Rb4+ Ke5 Rb6 Kf4
<snip>
 42 +1.36  118.7M 1:01.60 Rg1+ Kd2 Rg2+ Kc3 Rc2+ Kb3 Rb2+ Kc3 Bxd7 Qf8 Ba4 Qb8 Bd1 Qd6 Rc2+ Kd3 Be2+ Ke3 Rb2 Qb8 Bd1 Ke4 Rb5 Kd4 Bf3 Kc4 Be2+ Kc3 Rb6 Kd2 Bc4 Kc3 Be6 Kd4 Rb5 Kc3 Bf7 Kd4 Kb2 Ke4 Bc4 Qh2+ Kb3 Qg3+ Ka4 Qb8 Bd5+ Kd4 Bb3 Qa7+ Kb4 Qb8 Bc4 Ke4
<snip>
 41 +1.38  110.3M 0:56.80 Rg1+ Kd2 Rg2+ Kc3 Rc2+ Kb3 Rb2+ Kc3 Bxd7 Qf8 Ba4 Qb8 Bd1 Qd6 Rc2+ Kd3 Be2+ Ke3 Rb2 Qb8 Bd1 Ke4 Rb5 Kd4 Bf3 Kc4 Be2+ Kc3 Rb6 Kd2 Bc4 Kc3 Be6 Kd4 Rb5 Kc3 Bd5 Kd4 Ba2 Ke4 Be6 Kd4 Kb2 Qh2+ Kb3 Qb8 Bc4 Ke3 Kc3 Qh8+ Kb4 Qb2+ Ka4 Qa1+
 <snip>
 39 +1.25  87.3M   0:44.48 Rg1+ Kd2 Rg2+ Kc3 Rc2+ Kb3 Rb2+ Kc3 Bxd7 Qf8 Ba4 Qb8 Bd1 Kd4 Rb5 Kc4 Be2+ Kc3 Rb6 Kd4 Bf3 Ke5 Kb2 Kf4 Bd1 Kg5 Kb1 Kf5 Bb3 Ke5 Kb2 Kd4 Rb5 Qh2+ Bc2 Qb8 Bd1 Kc4 Be2+ Kd4 Kc2 Ke3 Bd1 Kd4 Kb3 Qg3+ Ka4 Qb8 Bb3 Kc3 Rb6 Kd4 Kb5 Ke5 K
 38 +1.25  82.0M   0:41.90 Rg1+ Kd2 Rg2+ Kc3 Rc2+ Kb3 Rb2+ Kc3 Bxd7 Qf8 Ba4 Qb8 Bd1 Kd4 Rb5 Kc4 Be2+ Kc3 Rb6 Kd4 Bf3 Ke5 Kb2 Kf4 Bd1 Kg5 Kb1 Kf5 Bb3 Ke5 Kb2 Kd4 Rb5 Qh2+ Bc2 Qb8 Kb3 Qg3+ Ka4 Qb8 Bb3 Kc3 Rb6 Kd4 Kb5 Ke5 Kb4 Kd4 Be6 Kd3 Bd5 Kd4 Bf3 Ke5 Be
<snip>
 37 +0.13  79.3M   0:40.44 Rg1+ Kd2 Rg2+ Kc3 Rc2+ Kb3 Rb2+ Kc3 Bxd7 Qf8 Ba4 Qb8 Bd1 Kc4 Bf3 Kd4 Rb5 Kc4 Rb6 Kd4 Rb2 Ke5 Rb3 Kd6 Rb5 Ke6 Rb4 Kd6 Kc2 Kc5 Kb3 Kd6 Be4 Ke7 Kc3 Qc7+ Kd3 Qg3+ Kc2 Qf2+ Kb3 Qe3+ Ka2 Qa7+ Kb2 Qb8 Kb3 Kd6 Bf3 Qg8+ Ka3 Kc7 b8=R Qx
 37 +0.67! 78.3M   0:39.90 Rg1+!
 37 +0.47! 77.0M   0:39.18 Rg1+!
 37 +0.32! 76.8M   0:39.11 Rg1+!
 37 +0.23! 76.8M   0:39.07 Rg1+!
 36 +0.57! 76.1M   0:38.72 Rg1+!
 36 +0.37! 75.8M   0:38.59 Rg1+!
 36 +0.23! 75.7M   0:38.51 Rg1+!
 36 +0.13! 75.6M   0:38.49 Rg1+!
 35 +0.03? 58.0M   0:29.84 bxa8=Q Qb5+?
```

Make Square and Bitboard operators commutative

As Stockfish developers, we aim to make our code as legible and as close
to simple English as possible. However, one of the more notable exceptions
to this rule concerns operations between Squares and Bitboards.

Prior to this pull request, AND, OR, and XOR were only defined when the
Bitboard was the first operand, and the Square the second. For example,
for a Bitboard b and Square s, "b & s" would be valid but "s & b" would not.
This conflicts with natural reasoning about logical operators, both
mathematically and intuitively, which says that logical operators should
commute.

More dangerously, however, both Square and Bitboard are defined as integers
"under the hood." As a result, code like "s & b" would still compile and give
reasonable bench values. This trap occasionally ensnares even experienced
Stockfish developers, but it is especially dangerous for new developers not
aware of this peculiarity. Because there is no compilation or runtime error,
and a reasonable bench, only a close review by approvers can spot this error
when a test has been submitted--and many times, these bugs have slipped past
review. This is by far the most common logical error on Fishtest, and has
wasted uncountable STC games over the years.

However, it can be fixed by adding three non-functional lines of code. In this
patch, we define the operators when the operands are provided in the opposite
order, i.e., we make AND, OR, and XOR commutative for Bitboards and Squares.
Because these are inline methods and implemented identically, the executable
does not change at all.

This patch has the small side-effect of requiring Squares to be explicitly
cast to integers before AND, OR, or XOR with integers. This is only performed
twice in Stockfish's source code, and again does not change the executable at
all (since Square is an enum defined as an integer anyway).

For demonstration purposes, this pull request also inverts the order of one AND
and one OR, to show that neither the bench nor the executable change. (This
change can be removed before merging, if preferred.)

I hope that this pull request significantly lowers the barrier-of-entry for new
developer to join the Stockfish project. I also hope that this change will improve
our efficiency in using our generous CPU donors' machines, since it will remove
one of the most common causes of buggy tests.

Following helpful review and comments by Michael Stembera (@mstembera), we add
a further clean-up by implementing OR for two Squares, to anticipate additional
traps developers may encounter and handle them cleanly.

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

No functional change.

Combo of Parameter Tweaks

This patch is a combo of the following tweaks:

Complexity parameters
Knight PSQT
Bishop PSQT
King PSQT
Piece Values

Passed STC:
LLR: 2.95 (-2.94,2.94) [-1.50,4.50]
Total: 56527 W: 12326 L: 12052 D: 32149
http://tests.stockfishchess.org/tests/view/5dbbca3f0ebc5925b64ee6d6

Passed LTC:
LLR: 2.95 (-2.94,2.94) [0.00,3.50]
Total: 64010 W: 10549 L: 10199 D: 43262
http://tests.stockfishchess.org/tests/view/5dbc30dc0ebc5925b64eee0c

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

Bench: 4312945

Simplify kingRing

Simplify the king ring initialization and make it more regular, by just
moving the king square off the edges and using PseudoAttacks by king from
this new square.

There is a small functional difference from the previous master, as the
old master excludes the original ksq square while this patch always includes
the nine squares block (after moving the king from the edges). Additionally,
master does not adjust the kingRing down if we are on relative rank 8,
while this patch treats all of the edges the same.

STC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 13263 W: 2968 L: 2830 D: 7465
http://tests.stockfishchess.org/tests/view/5db872830ebc5902d1f388aa

LTC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 72996 W: 11819 L: 11780 D: 49397
http://tests.stockfishchess.org/tests/view/5db899c20ebc5902d1f38b5e

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

Bench: 4959244

Consolidate pawn_push and up

This is a non-functional simplification. Pawn_push and Up are redundant.
If we make up pawn_push, we can use it for all of the Up's and Down's.
In this version, I've also left the Up and Down constants so that there
is no worse readability.

STC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 23878 W: 5202 L: 5085 D: 13591
http://tests.stockfishchess.org/tests/view/5db5569a0ebc5902d6b14de4

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

No functional change

Tweak dynamic contempt (the birthday patch)

Make dynamic contempt weight factor dependent on static contempt so that higher
static contempt implies less dynamic contempt and vice versa. For default contempt
24 this is a non-functional change. But tests with contempt 0 shows an elo gain.
Also today is my birthday so i have already give to myself a gift with this patch :-)!

Further proceedings:

in the past we checked for default contempt that it doesn't regress against
contempt 0. Now that the later is stronger and the former is the same strength
this should be rechecked. Perhaps the default contempt have to be lowered.
It would be interesting to get some idea of the impact of this patch outside
of the 0-24 contempt range.

STC: (both with contempt=0)
LLR: 2.95 (-2.94,2.94) [-1.50,4.50]
Total: 21912 W: 3898 L: 3740 D: 14274
http://tests.stockfishchess.org/tests/view/5db74b6f0ebc5902d1f37405

LTC: (both with contempt=0)
LLR: 2.96 (-2.94,2.94) [0.00,3.50]
Total: 27172 W: 3350 L: 3126 D: 20696
http://tests.stockfishchess.org/tests/view/5db760020ebc5902d1f375d0

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

No functional change (for current default contempt 24).

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