Remove Condition For Passed Pawns

Currently, we do not consider pawns passed if there is another pawn of
the same color in front of them. It appears that this condition is not
necessary. The idea is that the doubled pawns are likely to be weak and
one of them will be likely captured anyway. On the other hand, if we do
somehow manage to promote a pawn, then the pawn behind it becomes passed
as well. In any case, the end result is we end up with an extra
potentially passed pawn. The current evaluation for passed pawns already
handles this case by also scaling down this effect.

STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 28291 W: 6287 L: 6178 D: 15826
http://tests.stockfishchess.org/tests/view/5b6c4b960ebc5902bdb9f256

LTC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 30717 W: 5256 L: 5151 D: 20310
http://tests.stockfishchess.org/tests/view/5b6c82980ebc5902bdb9f863

Bench: 4938285

LMR simplification

Unify the "quiet" and "non-quiet" reduction rules for use at any kind of moves.
The idea behind it was that both rules reduce at similiar cases in master:
one directly for late previous moves and the other indirectly by using a
bad stat score which is used for most move sorting and so approximates the
late move condition.

For captures/promotions the old rule was triggered in 25% but the new
rule only for 3% of all cases (so now more reductions are done, whereas
for quiet moves reductions keep the same level).

STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 162327 W: 35976 L: 36134 D: 90217
http://tests.stockfishchess.org/tests/view/5b6a9a430ebc5902bdb9d5c1

LTC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 29570 W: 5083 L: 4976 D: 19511
http://tests.stockfishchess.org/tests/view/5b6bc5d00ebc5902bdb9e9d6

Bench: 4526980

First check threshold in space evaluation

Currently, we first calculate some bitboards at the top of Evaluation::space()
and then check whether we actually need them. Invert the ordering. Of course this
does not make a difference in current master because the constexpr bitboard
calculations are in fact done at compile time by any decent compiler, but I find
my version a bit healthier since it will always meet or exceed current implementation
even if we eventually change the spaceMask to something not contsexpr.

No functional change.

King Psqt Tuning

After a session of tuning for King Psqt I got some new values, which was later
tweaked manually by me Fauzi, to result in an Elo-gain patch which seems to scale
pretty well:

STC: LLR: -2.96 (-2.94,2.94) [0.00,4.00]
Total: 100653 W: 22550 L: 22314 D: 55789 [Yellow patch]

LTC: LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 147079 W: 25584 L: 24947 D: 96548 [Green Patch]

Bench: 4669050

Introduce voting system for best move selection

Introduce voting system for best move selction in multi-threads mode.
Joint work with Stefan Geschwentner, based on ideas introduced by
Michael Stembera.

Moves are upvoted by every thread using the margin to the minimum score
across threads and the completed depth.

First thread voting for the winner move is selected as best thread.

Passed STC, LTC. A further LTC test with only 4 threads failed with positive
score. A LTC with 31 threads was stopped with LLR 0.77 after 25k games to
avoid use of excessive resources (equivalent to 1.5M STC games).

Similar ideas were proposed by Michael Stembera 2 years ago #507, #508.
This implementation seems simpler and more understandable, the results
slightly more promising.

Further possible work:

1) Tweak of the formula using for assigning votes.
2) Use a different baseline for the score dependent part: maximum score
or winning probability could make more sense.
3) Assign votes in `Thread::Search` as iterations are completed and use
voting results to stop search.
4) Select best thread as the threads voting for best move with the highest
completed depth or, alternatively, vote on PV moves.

Link to SPRT tests

[stopped LTC, 31 threads 20+0.02](http://tests.stockfishchess.org/tests/view/5b61dc090ebc5902bdb95192)
LLR: 0.77 (-2.94,2.94) [0.00,5.00]
Total: 25602 W: 3977 L: 3850 D: 17775
Elo: 1.70 [-0.68,4.07] (95%)

[passed LTC, 8 threads 20+0.02](http://tests.stockfishchess.org/tests/view/5b5df5180ebc5902bdb9162d)
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 44478 W: 7602 L: 7300 D: 29576
Elo: 1.92 [-0.29,3.94] (95%)

[failed LTC, 4 threads 20+0.02](http://tests.stockfishchess.org/tests/view/5b5f39ef0ebc5902bdb92792)
LLR: -2.94 (-2.94,2.94) [0.00,5.00]
Total: 29922 W: 5286 L: 5285 D: 19351
Elo: 0.48 [-1.98,3.10] (95%)

[passed STC, 4 threads 5+0.05](http://tests.stockfishchess.org/tests/view/5b5dbf0f0ebc5902bdb9131c)
LLR: 2.97 (-2.94,2.94) [0.00,5.00]
Total: 9108 W: 2033 L: 1858 D: 5217
Elo: 6.11 [1.26,10.89] (95%)

No functional change (in simple threat mode)

Improve Stats definition

Use operator const T&() instead of operator T() to avoid possible
costly hidden copies of non-scalar nested types.

Currently StatsEntry has a single member T, so assuming
sizeof(StatsEntry) == sizeof(T) it happens to work, but it's
better to use the size of the proper entry type in std::fill.
Note that current code works because std::array items are ensured
to be allocated in contiguous memory and there is no padding among
nested arrays. The latter condition does not seem to be strictly
enforced by the standard, so be careful here.

Finally use address-of operator instead of get() to fully hide the
wrapper class StatsEntry at calling sites. For completness add
the arrow operator too and simplify the C++ code a bit more.

Same binary code as previous master under the Clang compiler.

No functional change.

Small tweaks to recent code changes

As a note, current 2 LMR conditions on stat score
could be simplified in a single line:

r -= ((ss->statScore >= 0) - ((ss-1)->statScore >= 0)) * ONE_PLY;

We keep them splitted in 2 "if" statements because are easier
to (immediately) read.

No functional change.

7-pieces Syzygy tablebase support

This is the first patch teaching Stockfish how to use the 7-pieces
Syzygy tablebase currently calculated by Bujun Guo (@noobpwnftw) and
Ronald de Man (@syzygy1). The 7-pieces database are so big that they
required a change in the internal format of the files (technically,
some DTZ values are 16 bits long, so this had to be stored as wide
integers in the Huffman tree).

Here are the estimated file size for the 7-pieces Syzygy files,
compared to the 151G of the 6-pieces Syzygy:

```
7.1T    ./7men_testing/4v3_pawnful (ongoing, 120 of 325 sets remaining)
2.4T    ./7men_testing/4v3_pawnless
2.3T    ./7men_testing/5v2_pawnful
660G    ./7men_testing/5v2_pawnless
117G    ./7men_testing/6v1_pawnful
87G     ./7men_testing/6v1_pawnless
```
Some pointers to download or recalculate the tables:

Location of original files, by Bujun Guo:
ftp://ftp.chessdb.cn/pub/syzygy/

Mirrors:
http://tablebase.sesse.net/ (partial)
http://tablebase.lichess.ovh/tables/standard/7/

Generator code:
https://github.com/syzygy1/tb/

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

Bench: 5591925 (No functional change if SyzygyTB is not used)

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

Comment by Leonardo Ljubičić (@DragonMist)

This is an amazing achievement, generating and being able to use 7 men syzygy
on the fly. Thank you for your efforts @noobpwnftw !! Looking forward how this
will work in real life, and expecting some trade off between gaining perfect
play and slow disc Access, but once the disc speed and space is not a problem,
I expect 7 men to yield something like 30 elo at least.

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

Comment by Michael Byrne (@MichaelB7)

This definitely has a bright future. I turned off the 50 move rule (ala ICCF
new rules) for the following position:  `[d]8/8/1b6/8/4N2r/1k6/7B/R1K5 w - - 0 1`
This position is a 451 ply win for white (sans the 50 move rule, this position
was identified by the generator as the longest cursed win for white in KRBN v KRB).

Now Stockfish finds it instantly (as it should), nice work 👊👍 .
```
dep score     nodes     time
  7 +132.79  4339     0:00.00 Rb1+ Kc4 Nd6+ Kc5 Bg1+ Kxd6 Rxb6+ Kc7 Be3 Rh2 Bd4
  6 +132.79  1652     0:00.00 Rb1+ Kc4 Nd2+ Kd5 Rxb6 Rxh2 Nf3 Rf2
  5 +132.79  589       0:00.00 Rb1+ Kc4 Rxb6 Rxh2 Nf6 Rh1+ Kb2
  4 +132.79  308       0:00.00 Rb1+ Kc4 Nd6+ Kc3 Rxb6 Rxh2
  3 +132.79  88         0:00.00 Rb1+ Ka4 Nc3+ Ka5 Ra1+ Kb4 Ra4+ Kxc3 Rxh4
  2 +132.79  54         0:00.00 Rb1+ Ka4 Nc3+ Ka5 Ra1+ Kb4
  1 +132.7
```

Introduce tropism measure in king danger

This patch adds the tropism measure as a new term in the king danger variable.
Since we then trasform this variable as a Score via a quadratic formula, the
main effect of the patch is the positive correlation of the tropism measure
with some checks and pins information already present in the king danger code.

STC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 6805 W: 1597 L: 1431 D: 3777
http://tests.stockfishchess.org/tests/view/5b5df8d10ebc5902bdb91699

LTC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 32872 W: 5782 L: 5523 D: 21567
http://tests.stockfishchess.org/tests/view/5b5e08d80ebc5902bdb917ee

How to continue from there?

• it may be possible to use CloseEnemies=S(7,0)
• we may want to try incorporating other strategic features in the quadratic
  king danger.

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

Bench: 5591925

Increase the mg->eg gradient for the PawnlessFlank malus

Just a change of value to S(19, 84). Also somewhat of a follow up
to the recent tweak in definition of KingFlank.

I tried a lot of other values before this, increasing and decreasing
but with little success, and before giving up I wanted to try tweaking
the middlegame and endgame values in the opposite directions. I guess
this is somewhat lucky.

STC:
LLR: 2.94 (-2.94,2.94) [0.00,4.00]
Total: 67685 W: 15399 L: 14963 D: 37323
http://tests.stockfishchess.org/tests/view/5b5b5ae80ebc5902bdb8e4f8

LTC: (Also thanks to Stephane Nicolet)
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 54635 W: 9505 L: 9172 D: 35958
http://tests.stockfishchess.org/tests/view/5b5b78f20ebc5902bdb8ece5

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

Bench: 4883742

Simplify cmh pruning

Simplify cmh pruning by removing PvNode exception

STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 9935 W: 2330 L: 2184 D: 5421
http://tests.stockfishchess.org/tests/view/5b587dc00ebc5902bdb88424

LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 20635 W: 3585 L: 3464 D: 13586
http://tests.stockfishchess.org/tests/view/5b58910a0ebc5902bdb885b9

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

Bench: 4905530

Fix a compilation error for MSVC

The previous commit wouldn't compile on the Microsoft Virtual Studio C++ compiler. So use a more compatible style for the same idea (which we already use in numerous places of evaluate.cpp, for instance in line 563).

Under the Clang compiler, both versions generate exactly the same machine code (same md5 signatures for the two binaries).

No functional change.

Remove a popcount for HinderPassedPawn

Remove a popcount for HinderPassedPawn, and compensate by doubling
 the bonus from S(4,0) to to S(8,0).

Maybe it was pure luck, but we got the idea of this Elo gaining patch by
seing the simplification attempt by Mike Whiteley in pull request #1703.
This suggests that whenever we have a passed evaluation simplification,
we should consider the possibility that the master bonus has become
slightly out of tune with time, and we should try a few Elo gaining [0..4]
tests by hand-tuning the master bonus.

STC:
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 19136 W: 4388 L: 4147 D: 10601
http://tests.stockfishchess.org/tests/view/5b59be6f0ebc5902bdb8ac06

LTC:
LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 99382 W: 17324 L: 16843 D: 65215
http://tests.stockfishchess.org/tests/view/5b59d2410ebc5902bdb8afa8

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

Bench: 4688817

Tweak KingFlank when king is on edge files

This tweak excludes files D and E from the KingFlank bitboard when our
king is on the A or H files respectively. As far as I can tell, this
affects two things: the calculation for CloseEnemies and PawnlessFlank.
Aside from filtering out slightly less relevant attacks in the flank,
I suspect this helps with king prophylaxis, avoiding attacks and moving
towards the center when the pawns start to come off.

STC
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 56755 W: 12881 L: 12489 D: 31385
http://tests.stockfishchess.org/tests/view/5b58a94c0ebc5902bdb88c72

LTC
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 130205 W: 22536 L: 21957 D: 85712
http://tests.stockfishchess.org/tests/view/5b58b7580ebc5902bdb89029

How to continue: Tweaking the two bonuses mentioned might give some
gain, although as far as I can tell, CloseEnemies is very sensitive to
even small changes.

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

Bench: 5026009

Small reformat in evaluate threats (non functional)

When evaluating threat by safe pawn and pawn push the same expression is used.

STC
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 19444 W: 4540 L: 4309 D: 10595
http://tests.stockfishchess.org/tests/view/5b5a6e150ebc5902bdb8c5c0

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

No functional change.

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

Comments by Stéphane Nicolet:

I don't measure any speed-up on my system, with two parallel benches at depth 22:

Total time (ms) : 74989
Nodes searched : 144830258
Nodes/second : 1931353
master

Total time (ms) : 75341
Nodes searched : 144830258
Nodes/second : 1922329
testedpatch

And anyway, like Stefan Geschwentner, I don't think that a 0.3% speed-up would
be enough to pass a [0..5] LTC test -- as a first approximation, we have this
rule of thumb that 1% speed-up gives about 1 Elo point.

However, considering the facts that the reformatting by itself is interesting,
that this is your first green test and that you played by the rules by running
the SPRT[0..5] test before opening the pull request, I will commit the change.
I will only take the liberty to change the occurrences of safe in lines 590 and
591 to b, to make the code more similar to lines 584 and 585.

So approved, and congrats :-)

Fix condition for error message of signature script

Use obtained bench instead of reference bench when checking for crash.

No functional change.

Remove condition for pawn threats

It appears as though removing squares that are already attacked
by our pawns can be removed.

STC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 51242 W: 11503 L: 11440 D: 28299
http://tests.stockfishchess.org/tests/view/5b58b5a40ebc5902bdb88f52

LTC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 35246 W: 6063 L: 5966 D: 23217
http://tests.stockfishchess.org/tests/view/5b58f8e20ebc5902bdb8959b

How to continue after this patch: there is now a slight semantic
overlap between the ThreatByPawnPush and the ThreatBySafePawn bonuses,
so hand-tuning either of these, or both at the same time, is natural.

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

Bench 4734881

Rank threats on pinned pawns

Add for pinned pawns half of the standard rank based threat bonus.

STC:
LLR: 2.97 (-2.94,2.94) [0.00,5.00]
Total: 44010 W: 9987 L: 9635 D: 24388
http://tests.stockfishchess.org/tests/view/5b58aa780ebc5902bdb88c7a

LTC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 29475 W: 5089 L: 4847 D: 19539
http://tests.stockfishchess.org/tests/view/5b58b56c0ebc5902bdb88f37

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

Bench: 4503866

Code clean-up

This patch implements some idea by Alain Savard and Mike Whiteley taken from the perpertual renaming/reformatting thread.

This is a pure code cleaning patch (so no change in functionality), but I use it as a pretext to correct the bogus bench number that I introduced in the previous commit.

Bench: 4413383

Tweak stat bonus

Increase stat bonus by 1/32 and adjust the divisor of main and capture
history tables to 10692.

STC:
LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 28437 W: 6444 L: 6166 D: 15827
http://tests.stockfishchess.org/tests/view/5b579b4d0ebc5902bdb87139

LTC:
LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 111204 W: 19160 L: 18644 D: 73400
http://tests.stockfishchess.org/tests/view/5b57a7c60ebc5902bdb872d3

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

Bench: 4778882

CounterMove History Pruning Tweak

STC: (Yellow)
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 40124 W: 8817 L: 8751 D: 22556
http://tests.stockfishchess.org/tests/view/5b5690180ebc5902bdb85c8a

LTC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 21599 W: 3811 L: 3599 D: 14189
http://tests.stockfishchess.org/tests/view/5b5757010ebc5902bdb86b1f

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

Bench:  4794161

Revert "Tweak reductions formula: 0.88 * depth + 0.12"

This patch reverts the recent commit called "Tweak reductions formula, etc."
The decisions for the revert decision were as follows:

1) The original commit called "Tweak reductions formula: 0.88 * depth + 0.12"
showed bad scaling at in a Very Long Time Control (VLTC) test:

VLTC (180+1.8):
LLR: -1.59 (-2.94,2.94) [0.00,5.00]
Total: 14968 W: 2247 L: 2257 D: 10464
http://tests.stockfishchess.org/tests/view/5b559ffa0ebc5902bdb84f36

2) So there was a suspicion that the original fast passing LTC test which lead
us to accept the patch may have been a statistical accident, so we organized
a match against the previous master at LTC to get an Elo estimate for the
patch:

LTC match:
ELO: -1.83 +-2.1 (95%) LOS: 4.3%
Total: 36018 W: 6018 L: 6208 D: 23792
http://tests.stockfishchess.org/tests/view/5b55f8110ebc5902bdb8526f

3) Based on these results, we ran a simplification test with [-3..1] bounds
for the revert at LTC:

LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 41501 W: 7107 L: 7020 D: 27374
http://tests.stockfishchess.org/tests/view/5b5738670ebc5902bdb86932

4) So we revert.

Bench: 4491691

Slight decrease of overload value

Set overload value to S(13,6)

STC:
LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 27606 W: 6371 L: 6094 D: 15141
http://tests.stockfishchess.org/tests/view/5b5455840ebc5902bdb82425

LTC:
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 112435 W: 19442 L: 18921 D: 74072
http://tests.stockfishchess.org/tests/view/5b546d4a0ebc5902bdb82741

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

Bench: 4937000

Tweak reductions formula: 0.88 * depth + 0.12

Replace the depth part in the reduction formula for higher depths
with a slower growing linear function. So for depth > 3 less reductions
are used.

What we can try next:
- move the break point to even higher depths
- tweak the slope for lower and higher depth
- even possibly use a further higher depth threshold for a another
  slower growing function

STC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 25317 W: 5763 L: 5505 D: 14049
http://tests.stockfishchess.org/tests/view/5b54f9f70ebc5902bdb840ed

LTC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 7451 W: 1320 L: 1167 D: 4964
http://tests.stockfishchess.org/tests/view/5b54feeb0ebc5902bdb84244

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

Bench: 4617359

Simplify condition for ThreatByRook

Remove stronglyProtected Queen for ThreatByRook. Idea is that in the
current master the  SliderOnQueen bonus and the see_ge() function do
something similar as ThreatByRook for Queen, so this patch removes
some redundancy, in that sense.

STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 21878 W: 4939 L: 4818 D: 12121
http://tests.stockfishchess.org/tests/view/5b53a83b0ebc5902bdb815d1

LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 35307 W: 5979 L: 5882 D: 23446
http://tests.stockfishchess.org/tests/view/5b53b60b0ebc5902bdb8174c

Close https://github.com/official-stockfish/Stockfish/pull/1690

Bench: 4834554

simplified forward ranks.

This is a non-functional simplification. We change replaces an 'OR'
and a lookup (rank_bb(ksq)) with a bitwise ~.  This is fewer operations
and is probably faster.

STC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 25441 W: 5689 L: 5575 D: 14177
http://tests.stockfishchess.org/tests/view/5b52d05a0ebc5902bdb8010e

LTC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 26904 W: 4664 L: 4553 D: 17687
http://tests.stockfishchess.org/tests/view/5b543df70ebc5902bdb8212d

No functional change.

Slight tidy up in endgame machinery

No functional change.

Non functional LMR rewrite.

Simplify the "overload" condition

This is a follow-up of the previous pull request (#1686) by Miguel.
We simplify the "Overload" bonus condition by re-using the "weak"
variable, which captures well the essence of the overload condition.
This may also be a small speed optimization because the weak variable
is in a register at this point of the code.

http://tests.stockfishchess.org/tests/view/5b527b440ebc5902bdb7f7db
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 10925 W: 2517 L: 2374 D: 6034

http://tests.stockfishchess.org/tests/view/5b527f930ebc5902bdb7f883
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 15569 W: 2697 L: 2568 D: 10304

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

Bench: 5010472

Remove connectivity.

There seems to be some strange interaction between Overload and Connectivity.
Overload encourages us to not have too many defended and attacked pieces,
as this may expose us to various tactics. This feels somewhat like it is in
conflict with Connectivity, where pieces are defended preemptively.

Here I take the "pick one or the other" approach and just remove connectivity,
while strengthening the effect of Overload to compensate. The reasoning is that
if we defend our pieces preemptively, then it does get attacked, we want to do
something about it so we don't get penalized by Overload. On the other
hand, if it doesn't get attacked, then there's no need to defend it.

STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 27734 W: 6174 L: 6064 D: 15496
http://tests.stockfishchess.org/tests/view/5b5073bd0ebc5902bdb7ba5c

LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 51606 W: 8897 L: 8827 D: 33882
http://tests.stockfishchess.org/tests/view/5b50aa900ebc5902bdb7bf29

Bench: 4658006

Better check evasion move sorting

Use in addition the counter move history table for sorting quiet
check evasion moves in main and quiecence search. Also rename
"contHistory" to "continuationHistory" while there.

STC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 73284 W: 16433 L: 15938 D: 40913
http://tests.stockfishchess.org/tests/view/5b4f526e0ebc5902bdb7a401

LTC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 12135 W: 2171 L: 1997 D: 7967
http://tests.stockfishchess.org/tests/view/5b4fc0ef0ebc5902bdb7ae0e

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

Bench 4817583

Use single value for KingProtector.

After some recent big tuning session, the values for King Protector were
simplified to only be used on minor pieces. This patch tries to further
simplify by just using a single value, since current S(6,5) and S(5,6)
are close to each other. The value S(6,6) ended up passing, although
S(5,5) was also tried and failed STC.

STC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 14261 W: 3288 L: 3151 D: 7822
http://tests.stockfishchess.org/tests/view/5b4ccdf50ebc5902bdb77f65

LTC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 19606 W: 3396 L: 3273 D: 12937
http://tests.stockfishchess.org/tests/view/5b4ce4280ebc5902bdb7803b

Bench: 5448998

 Simplify Overload condition

Extend the bonus for Overload to cases where our side
 has more than one attacker to a non pawn piece.
Based on an idea by Bryan in the forum. For instance,
 now black gets the overload bonus in this position:
 8/5R1k/6pb/p6p/P1N4P/1Pp5/2K3P1/2N4r b - - 6 46
 because two black pieces are attacking the knight on c1
 that is defended only by the king.

STC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 57446 W: 12762 L: 12711 D: 31973
http://tests.stockfishchess.org/tests/view/5b4ca9970ebc5902bdb77a88

LTC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 42113 W: 7295 L: 7209 D: 27609
http://tests.stockfishchess.org/tests/view/5b4ccea00ebc5902bdb77f69

Bench: 4667263

Minor code style tweaks

No functional change.

Minor whitespace formatting changes

No functional change.

Allow Position::init() to be called multiple times.

For the rationale to allow this, see commit
a66c73deef420104e74b6645ee60e20b37fd8549

This was broken when cuckoo hashing was added, and
subtly broke (for example) lichess' Android application,
thus illustrating the original judgement was sound.

No functional change.

Remove rank limitation for MinorBehindPawn

This is a functional simplification.  It seems like the rank restriction
for MinorBehindPawn can be removed.

STC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 61195 W: 13404 L: 13360 D: 34431
http://tests.stockfishchess.org/tests/view/5b47e6f00ebc5978f4be3fc0

LTC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 31701 W: 5367 L: 5264 D: 21070
http://tests.stockfishchess.org/tests/view/5b48a2cb0ebc5978f4be4769

Bench: 4938702

Tuned Values after 2 million spsa games

Various king and pawn eval values tuned after 2 million games. Rounding
slightly adjusted.

LTC: http://tests.stockfishchess.org/tests/view/5b477a260ebc5978f4be3ed4
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 32783 W: 5852 L: 5588 D: 21343

STC: http://tests.stockfishchess.org/tests/view/5b472d420ebc5978f4be3e4d
LLR: 3.23 (-2.94,2.94) [0.00,4.00]
Total: 44380 W: 10201 L: 9841 D: 24338

I think I reached the limit of the fishtest framework. It frequently
crashed at 2 million games already. The small values also moved a lot
throughout the entire tuning session though with smaller margin. The
passed danger and close enemies values seems the most sensitive (changing
close enemies alone to 6 failed before but now it passes), whether or not
they are close to optimal I don't know, but it seems some parameters are
also correlated to others.

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

bench: 5103722

Remove offset in thread redistribution scheme.

doesn't have a benefit.

passed STC (8 threads):
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 19574 W: 4028 L: 3904 D: 11642
http://tests.stockfishchess.org/tests/view/5b3e48950ebc5902b9fff080

passed LTC (8 threads):
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 21293 W: 3626 L: 3506 D: 14161
http://tests.stockfishchess.org/tests/view/5b3eefd60ebc5902b9fffa81

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

No functional change single threaded.

Simplify ThreatByKing to be a single Score.

In the current master, ThreatByKing is an array of two Scores, one for
when we have a single attack and one for when we have many. The latter
case is very rarely called during bench and was recently given a strange
negative value during a tuning run, as pointed out by @candirufish on
commit efd4ca2.  Here, we simplify away this second case entirely, and
increase the remaining ThreatByKing to compensate.

Although I derived the parameter tweak independently, with the goal of
preserving the same average bonus, I later noticed that a very similar
Score had already been derived by an ongoing SPSA tuning session.
I therefore recognize @candirufish for first discovering these values.

I would also like to thank @Rocky640 for valuable feedback that pointed
me in the direction of ThreatByKing.

STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 7677 W: 1772 L: 1623 D: 4282
http://tests.stockfishchess.org/tests/view/5b3db0320ebc5902b9ffe97a

LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 108031 W: 18329 L: 18350 D: 71352
http://tests.stockfishchess.org/tests/view/5b3dbf4b0ebc5902b9ffe9db

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

Bench: 4678861

Capture Stat Tweak

Penalize capture moves that fail to create a cutoff even at quiet move cutoff.

STC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 19004 W: 4284 L: 4059 D: 10661
http://tests.stockfishchess.org/tests/view/5b3a7d4d0ebc5902b9ffb6ea

LTC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 23100 W: 3981 L: 3765 D: 15354
http://tests.stockfishchess.org/tests/view/5b3aa4550ebc5902b9ffb8cf

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

Bench: 5232010

Simplify saving a TT entry.

Avoid passing TT.generation() to TTEntry::save() at every call,
moving the implementation of TTEntry::save from tt.h to tt.cpp.

tested for no regression:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 53787 W: 11948 L: 11890 D: 29949
http://tests.stockfishchess.org/tests/view/5b2ff37f0ebc5902b2e582fe

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

No functional change.

Reduce scope of variables

Small cleanup TranspositionTable:clear().

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

No functional change.

Move PSQ score to Position

This patch simplifies Position::do_move() by moving the PSQ score from
StateInfo to Position and updating it inside the put/remove/move_piece
functions.

The downside is that there is now slightly more computation done in
Position::undo_move(), but the fishtest results are Elo neutral.

Passed STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 78820 W: 15775 L: 15760 D: 47285
http://tests.stockfishchess.org/tests/view/5b1cd1d00ebc5902ab9c64ab

Passed LTC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 32966 W: 5716 L: 5615 D: 21635
http://tests.stockfishchess.org/tests/view/5b31e1230ebc5902b2e5a833

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

No functional change.

Remove make_bitboard()

In current master, the function make_bitboard() does nothing apart from
helping initialize the SquareBB[] array. This seems like an unnecessary
abstraction layer.

The advantage of make_bitboard() is we can define a bitboard, in a simple
and general way, not only from a single square but also from a list of
squares. It is more elegant, faster and  readable than combining multiple
SquareBB explicitly, but the last complex use case in evaluation was
simplified away a few months ago.

If make_bitboard() becomes useful again to define complicated bitboards,
it will be easy enough to reintroduce it using this pull request as
an implementation reference.

No functional change.

Simplify KingProtector penalty.

Recent tuning results implied this penalty is more important for knights
and bishops, and almost negligible for rooks and queen.

Passed as simplification both
STC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 20873 W: 4592 L: 4469 D: 11812
http://tests.stockfishchess.org/tests/view/5b2fb4d00ebc5902b2e57e84

and LTC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 46069 W: 7949 L: 7870 D: 30250
http://tests.stockfishchess.org/tests/view/5b2fcc4b0ebc5902b2e580c5

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

Bench: 5487679

Simplify HinderPassedPawn bonus

Make sure each piece is not scored more than once as a passed pawn "hinderer",
by scoring only the blockers along the passed pawn path. Inspired by TCEC Game 29.

Passed STC as a simplification
http://tests.stockfishchess.org/tests/view/5b3016d00ebc5902b2e58552
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 75388 W: 16656 L: 16641 D: 42091

Passed LTC as a simplification
http://tests.stockfishchess.org/tests/view/5b302ed90ebc5902b2e587fc
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 49157 W: 8460 L: 8386 D: 32311

Current master was also counting the number of attacks along a passed pawn path,
which might be misleading:

a) a defender might be counted many times for the same pawn path. For example a
   White rook on a1 attacking a black pawn on a7 would score the bonus * 6 but
   would be probably better placed on a8

b) a defender might be counted on different pawn paths and might be overloaded. For
   example a Ke4 or Qe4 against pawns on d6  and f6 would score the bonus * 6.

Counting each blocker or attacker only once is more complicated, and does not help
either: http://tests.stockfishchess.org/tests/view/5b2ff1cb0ebc5902b2e582b2

After this small simplification, there might be ways to increase the HinderPassedPawn
penalty.

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

Bench: 4520519

Another set of tuned values after one million games

Another set of tuned values, obtained by a long session of one million games.

STC:
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 15810 W: 3687 L: 3458 D: 8665
http://tests.stockfishchess.org/tests/view/5b2d32f60ebc5902b2e55d9e

LTC:
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 102118 W: 18146 L: 17651 D: 66321
http://tests.stockfishchess.org/tests/view/5b2d372c0ebc5902b2e55e0a

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

Bench: 4557946

Increase outflanking weight to 12

Give more incentive to king activity in the endgame by increasing the weight
of the "outflanking" variable from 8 to 12 in the function evaluate_initiative().

Finished yellow after 133102 games at STC:

LLR: -3.07 (-2.94,2.94) [0.00,4.00]
Total: 133102 W: 29535 L: 29179 D: 74388
http://tests.stockfishchess.org/tests/view/5b2b63fe0ebc5902b2e54475

Passed LTC:

LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 28027 W: 4918 L: 4672 D: 18437
http://tests.stockfishchess.org/tests/view/5b2ba39e0ebc5902b2e54a64

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

Bench: 4721753

Tuned values after 505k games

Various king and pawn tuned eval values after 505k 60 sec 600 nodes time
SPSA games. Adjusted passed rank and file values to be symmetrical.

Passed LTC (after passed rank/file adjustment):
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 37906 W: 6953 L: 6668 D: 24285
http://tests.stockfishchess.org/tests/view/5b2790960ebc5902b8d17ba1

A previous, very similar version with raw tuned values passed STC and LTC:

STC:
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 39515 W: 9227 L: 8900 D: 21388
http://tests.stockfishchess.org/tests/view/5b277e3e0ebc5902b8d17ac9

LTC:
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 14618 W: 2743 L: 2537 D: 9338
http://tests.stockfishchess.org/tests/view/5b2785020ebc5902b8d17b98

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

bench: 4777396

Fix GCC 8 cast warnings

Silences the following warnings when compiling with GCC 8.
The fix is to use an intermediate pointer to anonymous function:

```
misc.cpp: In function 'int WinProcGroup::get_group(size_t)':
misc.cpp:241:77: warning: cast between incompatible function types from 'FARPROC' {aka 'long long int (*)()'} to 'fun1_t' {aka 'bool (*)(_LOGICAL_PROCESSOR_RELATIONSHIP, _SYSTEM_LOGICAL_PROCESSOR_INFORMATION_EX*, long unsigned int*)'} [-Wcast-function-type]
   auto fun1 = (fun1_t)GetProcAddress(k32, "GetLogicalProcessorInformationEx");
                                                                             ^
misc.cpp: In function 'void WinProcGroup::bindThisThread(size_t)':
misc.cpp:309:71: warning: cast between incompatible function types from 'FARPROC' {aka 'long long int (*)()'} to 'fun2_t' {aka 'bool (*)(short unsigned int, _GROUP_AFFINITY*)'} [-Wcast-function-type]
   auto fun2 = (fun2_t)GetProcAddress(k32, "GetNumaNodeProcessorMaskEx");
                                                                       ^
misc.cpp:310:67: warning: cast between incompatible function types from 'FARPROC' {aka 'long long int (*)()'} to 'fun3_t' {aka 'bool (*)(void*, const _GROUP_AFFINITY*, _GROUP_AFFINITY*)'} [-Wcast-function-type]
   auto fun3 = (fun3_t)GetProcAddress(k32, "SetThreadGroupAffinity");
                                                                   ^
```

No functional change.

Fix MSVC error

Compiling the current master with MSVC gives the following error:

```
search.cpp(956): error C2660: 'operator *': function does not take 1 arguments
types.h(303): note: see declaration of 'operator *'
```

This was introduced in commit:
https://github.com/official-stockfish/Stockfish/commit/88de112b84a5285c2afb3e075a05c2ab8ad3fd33

We use a suggestion by @vondele to fix the error, thanks!

No functional change.

Slight simplification in scale factor computation

[STC](http://tests.stockfishchess.org/tests/view/5b2614000ebc5902b8d17193)
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 17733 W: 3996 L: 3866 D: 9871

[LTC](http://tests.stockfishchess.org/tests/view/5b264d0f0ebc5902b8d17206)
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 55524 W: 9535 L: 9471 D: 36518

Use pawn count scaling also for opposite bishops endings with additional material, with a slope of 2 instead of 7. This simplifies slightly the code.

This PR is a functionally equivalent refactoring of the version which was submitted.

Four versions tried, 2 passed both STC and LTC. I picked the one which seemed more promising at LTC.

Slope 4 passed STC (-0.54 Elo), LTC not attempted
Slope 3 passed STC (+2.51 Elo), LTC (-0.44 Elo)
Slope 2 passed STC (+2.09 Elo), LTC (+0.04 Elo)
Slope 1 passed STC (+0.90 Elo), failed LTC (-3.40 Elo)

Bench: 4761613

Remove lmrDepth restriction on quiet see pruning

And tweak the threshold value. With this threshold and the current piece
values, this permits see pruning on quiets to be done up to an lmrDepth
of 9 (beyond that the threshold is below -QueenValueMg and see_ge will
pass unconditionally).

STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 110316 W: 24612 L: 24667 D: 61037
http://tests.stockfishchess.org/tests/view/5b20aa760ebc5902ab9c9c1d

LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 17352 W: 2968 L: 2842 D: 11542
http://tests.stockfishchess.org/tests/view/5b20cf1e0ebc5902ab9c9fb6

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

Bench: 5069074

Remove depth condition for pruning captures.

The SEE condition alone is sufficient.

passed STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 109863 W: 24339 L: 24392 D: 61132
http://tests.stockfishchess.org/tests/view/5b1f5b000ebc5902ab9c8668

passed LTC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 23390 W: 4020 L: 3903 D: 15467
http://tests.stockfishchess.org/tests/view/5b1f94b40ebc5902ab9c8b5e

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

Bench: 4834747

Optimize an expression in endgame.cpp

I believe using foward_file_bb() here is fewer instructions.

a) Fewer instructions and probably more clear (debatable).
b) Possible that a lookup is slower than a few local operations, but the
   forward_file_bb table is probably used often enough that it is always
   cached.

Passed
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 21004 W: 4263 L: 4141 D: 12600
http://tests.stockfishchess.org/tests/view/5b1cad830ebc5902ab9c6239

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

No functional change.

Simplify capture pruning margin formula

Using just `PawnValueEg * depth` as Capture Prune Margin. There was a bunch
of patches that passed recently regarding captures, maybe this part of the
master code redundant? The patch was tested as a simplification:

STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 20833 W: 4218 L: 4096 D: 12519
http://tests.stockfishchess.org/tests/view/5b1cf2100ebc5902ab9c6651

LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 27050 W: 3975 L: 3864 D: 19211
http://tests.stockfishchess.org/tests/view/5b1cfdc80ebc5902ab9c6776

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

Bench: 4980482

Optimize contempt value (21)

After several tests it seems best to increase contempt from 12 to 21. This does
not regress against contempt=0 and gives a gain of around 7-8 elo against SF 7
in comparison to current default contempt.

STC: Test for non-regression contempt=21 against contempt=0
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 71250 W: 13956 L: 13926 D: 43368
http://tests.stockfishchess.org/tests/view/5b19a58d0ebc5902ab9c3bfa

STC: Test contempt 21 against SF 7
ELO: 190.06 +-2.8 (95%) LOS: 100.0%
Total: 40000 W: 22608 L: 2676 D: 14716
http://tests.stockfishchess.org/tests/view/5b19a6520ebc5902ab9c3c0e

STC: Test master against SF 7 for comparison
ELO: 182.95 +-2.7 (95%) LOS: 100.0%
Total: 40000 W: 21905 L: 2595 D: 15500
http://tests.stockfishchess.org/tests/view/5b16f5bc0ebc59214346d5ca

LTC: Test for non-regression contempt=21 against contempt=0
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 47666 W: 6914 L: 6832 D: 33920
http://tests.stockfishchess.org/tests/view/5b1a170b0ebc5902ab9c3fde

LTC: Test contempt 21 against SF 7
ELO: 203.92 +-2.6 (95%) LOS: 100.0%
Total: 40000 W: 22447 L: 1340 D: 16213
http://tests.stockfishchess.org/tests/view/5b1a174b0ebc5902ab9c3fe1

LTC: Test master against SF 7 for comparison
ELO: 196.08 +-2.6 (95%) LOS: 100.0%
Total: 40000 W: 21639 L: 1191 D: 17170
http://tests.stockfishchess.org/tests/view/5b1a17e40ebc5902ab9c3fe4

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

Bench: 4786912

Remove failedLow from the mainThread struct

failedLow is in fact a local variable in Thread::search().

Also clean some spaces and tabs in code.

No functional change.

Quiet move soft fail high bonus

Extra bonus for quiet move creating a huge soft fail high (triggered
in 21% of quiet bestmoves on a normal bench run). Pb00067 original idea
using PawnValueMg.

Passed STC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 138207 W: 28060 L: 27295 D: 82852
http://tests.stockfishchess.org/tests/view/5b14471b0ebc5902a81689c1

Passe LTC:
LLR: 2.94 (-2.94,2.94) [0.00,5.00]
Total: 157289 W: 23200 L: 22518 D: 111571
http://tests.stockfishchess.org/tests/view/5b149dde0ebc5902a8b41c5a

bench: 4441320

Simplify capture bonus

Simplify capture bonus by simply adding ONE_DEPTH instead of being
dependent on BestValue.

STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 24419 W: 4939 L: 4824 D: 14656
http://tests.stockfishchess.org/tests/view/5b16b2040ebc5963ba37e2a5

LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 44560 W: 6524 L: 6438 D: 31598
http://tests.stockfishchess.org/tests/view/5b16ccc00ebc59214346d403

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

Bench: 4782637

Call cycle detection before qsearch()

This has the property of raising alpha before calling qsearch(), thus
maybe giving some more cuts during qsearch(). The patch is equivalent
to the use of cycle detection inside qsearch() at depth 0, but is in
fact implemented by re-ordering code inside search(), which explains
the [0..4] bounds in the following tests.

STC (interrupted after 124250 games, with LLR=0.87):
http://tests.stockfishchess.org/tests/view/5b1500bd0ebc5902a8b420bf
LLR: 0.87 (-2.94,2.94) [0.00,4.00]
Total: 124250 W: 24973 L: 24470 D: 74807

LTC:
http://tests.stockfishchess.org/tests/view/5b1590eb0ebc5902a84dcd09
LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 74234 W: 11098 L: 10733 D: 52403

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

Bench: 4326784

Stabilize AppVeyor CI

After a helpful suggestion from AppVeyor support staff, moving the Stockfish
execution from ps to cmd seems to work. Alternative to PR #1624 tested in PR #1637.

No functional change.

Remove a superfluous subtrahend

The '- 1' subtrahend was introduced for guarding against null move
search at root, which would be nonsense. But this is actually already
guaranteed by the !PvNode condition. This followed from the discussion
in pull request 1609: https://github.com/official-stockfish/Stockfish/pull/1609

No functional change

Simplify LMR for captures

Simplify LMR for captures by removing capture's stat score logic for reduction.

STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 37068 W: 7462 L: 7370 D: 22236
http://tests.stockfishchess.org/tests/view/5b115bc30ebc591af58a6fd2

LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 80061 W: 11706 L: 11671 D: 56684
http://tests.stockfishchess.org/tests/view/5b117f590ebc59033d2d5315

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

Bench: 4470519

Bugfix of Position::has_repeated()

The function Position::has_repeated() is used by Tablebases::root_probe()
to determine whether we can rank all winning moves with the same value, or
if we need to strictly rank by dtz in case the position has already been
repeated once, and we are risking to run into the 50-move rule and thus
losing the win (especially critical in some very complicated endgames).

To check whether the current position or one of the previous positions
after the last zeroing move has already been occured once, we start looking
for a repetition of the current position, and if that is not the case, we
step one position back and repeat the check for that position, and so on.

If you now look at how this was done before the new root ranking patch was
merged two months ago, it seems quite obvious that it is a simple oversight:
https://github.com/official-stockfish/Stockfish/commit/108f0da4d7f993732aa2e854b8f3fa8ca6d3b46c

More specifically, after we stepped one position back with

```
stc = stc->previous;
```

we now have to start checking for a repetition with

```
StateInfo* stp = stc->previous->previous;
```

and not with

```
StateInfo* stp = st->previous->previous;
```

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

No functional change

Fix overload ambiguity

Fix an error when compiling current master with MSVC due to the
ambiguity of which operator* overload was intended (reported by
Jarrod Torriero).

No functional change.

Extra bonus for capture creating a huge fail high

STC:
http://tests.stockfishchess.org/tests/view/5b114f3d0ebc596e9e0881f6
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 13007 W: 2730 L: 2541 D: 7736

LTC:
http://tests.stockfishchess.org/tests/view/5b1176740ebc59033d2d52c6
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 15594 W: 2417 L: 2239 D: 10938

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

Bench: 4790240

Fix comments, rename variables

Thanks everybody for the various hints in the perpetual renaming thread:
https://github.com/official-stockfish/Stockfish/issues/1426

No functional change

Reallocate TT on threadpool resize.

Makes sure the potential benefit of first touch does not depend on
the order of the UCI commands Threads and Hash, by reallocating the
hash if a Threads is issued. The cost is zeroing the TT once more
than needed. In case the prefered order (first Threads than Hash)
is employed, this amounts to zeroing the default sized TT (16Mb),
which is essentially instantaneous.

Follow up for https://github.com/official-stockfish/Stockfish/pull/1601
where additional data and discussion is available.

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

No functional change.

Simplify depth reduction in IID.

Use a constant reduction instead of a depth dependent reduction.

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

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

Bench: 4521056

Use threads to clear the TT faster.

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

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

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

No functional change

LMR Capture Tweak

Increase capture reduction by comparing opponent's stat score

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

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

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

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

Bench: 5167159

Simplify BlockedByPawn to one dimension

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

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

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

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

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

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

Bench: 5133208

Correctly prevent recursive verification in nmp.

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

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

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

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

Bench changes at high depth.

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

Bench: 4484288

Simplify color usage in search.

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

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

No functional change.

Simply reset StatScore to zero at beta cutoff

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

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

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

Bench: 4484288

Simplify shelter: always do strength and danger

This check of pawns before subtracting danger can be removed.

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

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

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

Bench: 4746692

Simplifying away the progressKey

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

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

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

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

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

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

No functional change.

Fix MSVC errors in tbprobe.cpp

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

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

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

````

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

No functional change.

Use cycle detection to bound search value

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

Cycle detection algorithm by Marcel van Kervink:

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

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

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

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

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

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

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

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

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

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

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

How could we continue after the patch:

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

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

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

Bench: 4550412

Update search.cpp

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

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

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

Also use local variable excludedMove in NMP (marotear)

Bench:  5294316

Tweak kingAttackersCount and KingAttackWeights

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

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

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

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

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

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

Bench: 5282815

Include all blockers in king danger

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

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

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

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

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

bench: 4698290

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

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

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

Consolidate pawn storm types

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

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

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

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

Bench: 5244314

Tune null move pruning

Use a lower stat score threshold of 22500.

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

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

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

Bench: 4777674

Tuned some pawns and evaluation constants

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

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

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

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

bench: 4437531

Remove goto, limit skipping to NMP

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

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

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

Ideas for further work:

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

Bench: 4855031

Tweak null move pruning conditions

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

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

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

Ideas for further work:

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

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

Bench: 5088156

Drop the lever condition for backwards

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

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

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

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

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

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

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

How to continue from there?

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

Bench: 4773882

Remove skipEarlyPruning argument to search()

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

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

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

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

Bench: 4953556

Improve signature script

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

No functional change

Simplify the backward pawns code

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

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

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

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

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

Ideas for further work:

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

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

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

Bench: 5122789

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

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

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

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

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

Bench: 5186783

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

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

For instance, the following code:

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

generates in fact the code:

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

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

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

Bug report by Joost VandeVondele. Thanks!

Bench: 5512000

Use special rule for BlockedByKing

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

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

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

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

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

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

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

Bench: 5512000

-----------

How to continue after this patch?

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

Penalty for bad bishop with blocked central files

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

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

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

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

Bench: 5364190

Always scale using pawn contribution

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

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

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

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

How to continue from there?

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

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

Bench: 5254862

Simplifiy IID condition

do IID for all sufficiently deep searches without TT move.

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

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

Bench: 4966970

Fix 'make strip' for mingw.

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

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

No functional change.