Tweak main killer penalty

Apply refuted main killer penalty also on early TT cut-offs. This
makes penalty logic more consistent with the logic at normal search.

Failed STC:
http://tests.stockfishchess.org/tests/view/5c121e730ebc5902ba11aad8
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 72193 W: 15848 L: 15625 D: 40720 Elo +1.07

Passed LTC:
http://tests.stockfishchess.org/tests/view/5c17b1b10ebc5902ba123c24
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 35073 W: 5886 L: 5625 D: 23562 Elo +2.59

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

bench: 3393939

New voting formula for threads

We now use a quadratic formula during the vote for threads
when deciding on which thread to pick a move from.

time control 5+0.05, with 8 threads:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 20202 W: 4031 L: 3813 D: 12358
http://tests.stockfishchess.org/tests/view/5c16c8e60ebc5902ba1223e2

time control 20+0.2, with 8 threads:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 14330 W: 2290 L: 2115 D: 9925
http://tests.stockfishchess.org/tests/view/5c16efca0ebc5902ba122993

20000 games match at time control 5+0.05, with 31 threads:
ELO: 5.63 +-2.8 (95%) LOS: 100.0%
Total: 20000 W: 3539 L: 3215 D: 13246
http://tests.stockfishchess.org/tests/view/5c16f07a0ebc5902ba122a20

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

No functional change (in simple thread mode)

Use stronglyProtected

~stronglyProtected is quite similar to ~attackedBy[Them][PAWN] & ~attackedBy2[Them],
the only difference appears to be that the former includes squares attacked twice
by both sides. The resulting logic is simpler, and the change appears to be at least
Elo-neutral at both STC and LTC.

STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 35924 W: 7978 L: 7885 D: 20061
http://tests.stockfishchess.org/tests/view/5c14a5c00ebc5902ba11ed72

LTC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 37078 W: 6125 L: 6030 D: 24923
http://tests.stockfishchess.org/tests/view/5c14ae880ebc5902ba11eed8

Bench: 3646542

Refactor king ring calculation

Compute the "double protection by pawns" expression only once
in initialize(), instead of once for each piece in the piece loop.

Passed STC
http://tests.stockfishchess.org/tests/view/5c1506380ebc5902ba11f3b4
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 9494 W: 2191 L: 2045 D: 5258

Inspired by Nick Pelling's test
   http://tests.stockfishchess.org/tests/view/5c144d110ebc5902ba11e4af
and an older test of mine
   http://tests.stockfishchess.org/tests/view/5c0402810ebc5902bcee1fc8

Non functional change.

Fix a segfault.

this patch fixes a rare but reproducible segfault observed playing a
multi-threaded match, it is discussed somewhat in fishcooking.

From the core file, it could be observed that the issue was in qsearch, namely:

````
   ss->pv[0] = MOVE_NONE;
````

and the backtrace shows the it arrives there via razoring, called from the rootNode:

````
    (gdb) bt
    alpha=-19, beta=682, depth=DEPTH_ZERO) at search.cpp:1247
````

Indeed, ss->pv can indeed by a nullptr at the rootNode. However, why is the
segfault so rare ?

The reason is that the condition that guards razoring:

````
   (depth < 2 * ONE_PLY &&  eval <= alpha - RazorMargin)
````

is almost never true, since at the root alpha for depth < 5 is -VALUE_INFINITE.

Nevertheless with the new failHigh scheme, this is not guaranteed, and rootDepth > 5,
can still result in a depth < 2 search at the rootNode. If now another thread,
via the hash, writes a new low eval to the rootPos qsearch can be entered.
Rare but not unseen... I assume that some of the crashes in fishtest recently
might be due to this.

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

No functional change

Start a TT resize only after search finished.

As noticed in the forum, a crash in extract_ponder_from_tt could result
if hash size is set before the ponder move is printed. While it is arguably
a GUI issue (but it got me on the cli), it is easy to avoid this issue.

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

No functional change.

Remove Null Move Pruning material threshold

On November 30th, @xoto10 experimented with removing this threshold,
but the simplification barely failed LTC. I was inspired to try various
[0, 4] tweaks to increase its value, which would narrow the effects of
this threshold without removing it entirely. Various values repeatedly
led to Elo gains at both STC and LTC, most of which were insufficient
to pass.

After a couple of weeks, I tried again to find an Elo-gaining tweak
but noticed that I could raise the threshold higher and higher without
regression. I decided to try removing it entirely--forgetting that
@xoto10 had already attempted this. However, this now performs much
better at both STC and LTC, producing a STC Elo gain and also potentially
a smaller LTC one.

The reason appears to be a recent change in master (e8ffca3) near
this code, which interacts with this patch. This simplification
governs the conditions under which that patch's effects are applied.
Something non-obvious about that change has significantly improved
the performance of this simplification.

I recognize and thank @xoto10, who originally had this idea. Since
I ran several LTCs recently (to determine whether to open this PR,
or one for a related [0, 4]), I would also like to acknowledge the
other developers and CPU donors for their patience. Thank you all!

STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 13445 W: 3000 L: 2862 D: 7583
http://tests.stockfishchess.org/tests/view/5c11f01b0ebc5902ba11a6b8

LTC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 33868 W: 5663 L: 5563 D: 22642
http://tests.stockfishchess.org/tests/view/5c11ffe90ebc5902ba11a8a9

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

Bench: 3343286

Work around MSVC bug without breaking clang build

Do not rely on capturing of constexpr variables in lambda expression.

No functional change.

Fix MSVC error

Explicitly capture compile-time variable in lambda expression.

No function change.

Rewrite bonus for safe and unsafe checks

crazyhouse STC
LLR: 2.97 (-2.94,2.94) [0.00,10.00]
Total: 330 W: 211 L: 107 D: 12
http://35.161.250.236:6543/tests/view/5c14de9f6e23db7639060ce8

shogi
LLR: 2.95 (-2.94,2.94) [-10.00,5.00]
Total: 736 W: 387 L: 326 D: 23

minishogi
LLR: 2.97 (-2.94,2.94) [-10.00,5.00]
Total: 1658 W: 820 L: 766 D: 72

euroshogi
LLR: 3.00 (-2.94,2.94) [-10.00,5.00]
Total: 476 W: 259 L: 196 D: 21

Rewrite game phase for drop games

Define game phase based on pieces in hand,
and score king danger independent of game phase.

shogi
LLR: 2.97 (-2.94,2.94) [0.00,10.00]
Total: 624 W: 357 L: 248 D: 19

minishogi
LLR: 2.96 (-2.94,2.94) [0.00,10.00]
Total: 468 W: 261 L: 161 D: 46

judkinshogi
LLR: 2.98 (-2.94,2.94) [-10.00,5.00]
Total: 508 W: 281 L: 217 D: 10

crazyhouse STC
LLR: 2.99 (-2.94,2.94) [-10.00,5.00]
Total: 613 W: 330 L: 267 D: 16
http://35.161.250.236:6543/tests/view/5c13f9786e23db7639060ce0

A combo of parameter tweaks

Joint work by SFisGOD, xoroshiro and Chess13234.

This combo consists of the following tweaks:
Assorted bonuses and penalties by SFisGOD
Bishop and Rook PSQT by SFisGOD
Tempo Value by xoroshiro
Futility pruning by Chess13234

STC:
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 9005 W: 2082 L: 1882 D: 5041
http://tests.stockfishchess.org/tests/view/5c11628c0ebc5902ba119e90

LTC:
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 44207 W: 7451 L: 7157 D: 29599
http://tests.stockfishchess.org/tests/view/5c1172a40ebc5902ba119fa3

Bench: 3332460

Asymmetrical 8x8 Pawn PSQT

STC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 13323 W: 3015 L: 2818 D: 7490
http://tests.stockfishchess.org/tests/view/5c00a2520ebc5902bcedd41b

LTC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 52294 W: 9093 L: 8756 D:34445
http://tests.stockfishchess.org/tests/view/5c00b2c40ebc5902bcedd596

Some obvious followups to this are to further tune this PSQT, or
try 8x8 for other pieces. As of now I don't plan on trying this
for other pieces as I think the majority of the ELO it brings is
for pawns and kings.

Looking at the new values, the differences between kingside and
queenside are quite significant. I am very hopeful that this a
llows SF to understand and plan pawn structures even better than
it already does. Cheers!

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

Bench: 3569243

Changes identified in RENAME/REFORMATTING thread (#1861)

I've gone through the RENAME/REFORMATTING thread and changed everything I could find, plus a few more. With this, let's close the previous issue and open another.

No functional change.

Tweak CMH pruning

STC: (yellow)
LLR: -2.94 (-2.94,2.94) [0.00,5.00]
Total: 48919 W: 10625 L: 10517 D: 27777
http://tests.stockfishchess.org/tests/view/5c07e6a20ebc5902bcee7395

LTC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 50360 W: 8424 L: 8102 D: 33834
http://tests.stockfishchess.org/tests/view/5c0812450ebc5902bcee76f4

Bench: 3775064

remove parenthesis.

remove extra line.

add paren.

simplify opposite_colors

Revert "pseudo_legal() and MOVE_NONE"

This reverts commit 33d95482182e459eb033de47a31f142880aa9afb ,
which crashed in DEBUG mode because of the following assert in position.h

````
Assertion failed: (is_ok(m)), function capture, file ./position.h, line 369.
````

No functional change

Simplify Killer Move Penalty

STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 20816 W: 4525 L: 4402 D: 11889
http://tests.stockfishchess.org/tests/view/5c017cb90ebc5902bcede5b4

LTC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 39287 W: 6401 L: 6309 D: 26577
http://tests.stockfishchess.org/tests/view/5c01825e0ebc5902bcede686

Bench: 3773021

Simplify time manager in search()

Remove the F[] array which I find unhelpful and rename `improvingFactor` to
`fallingEval` since larger values indicate a falling eval and more time use.

I realise a test was not strictly necessary, but I ran STC [-3,1] just to
check there are no foolish errors before creating the pull request:

STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 35804 W: 7753 L: 7659 D: 20392
http://tests.stockfishchess.org/tests/view/5bef3a0c0ebc595e0ae39c19

It was then suggested to clean the constants around `fallingEval`
to make it more clear this is a factor around ~1 that adjusts time
up or downwards depending on some conditions. We then ran a double
test with this simplification suggestion:

STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 68435 W: 14936 L: 14906 D: 38593
http://tests.stockfishchess.org/tests/view/5c02c56b0ebc5902bcee0184

LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 37258 W: 6324 L: 6230 D: 24704
http://tests.stockfishchess.org/tests/view/5c030a520ebc5902bcee0a32

No functional change

pseudo_legal() and MOVE_NONE

MOVE_NONE is represented as SQ_A1 to SQ_A1 which is never pseudo_legal.

STC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 38807 W: 8363 L: 8275 D: 22169
http://tests.stockfishchess.org/tests/view/5c05f11d0ebc5902bcee4c86

No functional change

Introduce concept of double pawn protection.

Exclude doubly protected by pawns squares when calculating attackers on
king ring. Idea of this patch is not to count attackers if they attack
only squares that are protected by two pawns.

STC
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 70040 W: 15476 L: 15002 D: 39562
http://tests.stockfishchess.org/tests/view/5c0354860ebc5902bcee1106

LTC
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 16530 W: 2795 L: 2607 D: 11128
http://tests.stockfishchess.org/tests/view/5c0385080ebc5902bcee14b5

This is third king safety patch in recent times so we probably need
retuning of king safety parameters.

Bench: 3057978

Minor readme changes

Always evaluate king danger for drop variants

shogi
LLR: 2.98 (-2.94,2.94) [0.00,10.00]
Total: 848 W: 464 L: 352 D: 32

minishogi
LLR: 3.03 (-2.94,2.94) [-10.00,5.00]
Total: 990 W: 485 L: 427 D: 78

crazyhouse STC
LLR: 2.98 (-2.94,2.94) [-10.00,5.00]
Total: 1223 W: 629 L: 570 D: 24
http://35.161.250.236:6543/tests/view/5c014b236e23db7639060cc0

Add a simple evaluation for connect-n games

connect4
LLR: 2.98 (-2.94,2.94) [0.00,10.00]
Total: 144 W: 92 L: 15 D: 37

Penalize refuted killers in continuation history

Currently we apply a penalty in continuation history for refuted TT moves.
We can use the same idea to also penalize refuted killer moves in continuation
history.

STC:
http://tests.stockfishchess.org/tests/view/5c00ccbd0ebc5902bcedd768
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 54366 W: 12086 L: 11687 D: 30593

LTC:
http://tests.stockfishchess.org/tests/view/5c0107880ebc5902bceddc9c
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 25457 W: 4302 L: 4078 D: 17077

Bench: 3419069

Remove Overload bonus

Compensate by giving the Hanging bonus to weak doubly-attacked
non pawn enemies pieces.

STC: http://tests.stockfishchess.org/tests/view/5bfd53c40ebc5902bced9237
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 62107 W: 13664 L: 13622 D: 34821

LTC: http://tests.stockfishchess.org/tests/view/5bfd74700ebc5902bced9618
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 86406 W: 14381 L: 14365 D: 57660

A possible follow up would be to tune the hanging bonus and/or try to
simplify the hanging bonus condition.

Bench: 3810849

Restore development version

No functional change

Stockfish 10

Official release version of Stockfish 10.

This is also the 10th anniversary version of the Stockfish project, which
started exactly ten years ago! I wish to extend a huge thank you to
all contributors and authors in our amazing community :-)

Bench: 3939338

Update list of authors

No functional change

Use emplace_back() in TB code

The patch was tested for correctness by running bench with and
without the change against current master, and the tablebase hit
numbers were found to be identical in both cases. See the pull
request comments for details:
https://github.com/official-stockfish/Stockfish/pull/1826

No functional change.

Enhance king protector term for drop variants

shogi
LLR: 2.97 (-2.94,2.94) [0.00,10.00]
Total: 1354 W: 713 L: 594 D: 47

euroshogi
LLR: 2.97 (-2.94,2.94) [-10.00,5.00]
Total: 574 W: 307 L: 245 D: 22

minishogi
LLR: 2.95 (-2.94,2.94) [-10.00,5.00]
Total: 2006 W: 950 L: 901 D: 155

crazyhouse STC
LLR: 2.96 (-2.94,2.94) [-10.00,5.00]
Total: 855 W: 449 L: 388 D: 18
http://35.161.250.236:6543/tests/view/5bf981d86e23db7639060cab

crazyhouse LTC
LLR: 2.98 (-2.94,2.94) [-10.00,5.00]
Total: 2573 W: 1284 L: 1235 D: 54
http://35.161.250.236:6543/tests/view/5bfa5e486e23db7639060cae

Bonus for threats by shogi pawns

shogi
LLR: 2.97 (-2.94,2.94) [0.00,10.00]
Total: 1510 W: 787 L: 666 D: 57

minishogi
LLR: 2.96 (-2.94,2.94) [-10.00,5.00]
Total: 1544 W: 744 L: 691 D: 109

Handle non-capturing piece promotions as quiet moves

shogi
LLR: 2.95 (-2.94,2.94) [0.00,10.00]
Total: 2156 W: 1104 L: 974 D: 78

minishogi
LLR: 1.13 (-2.94,2.94) [0.00,10.00]
Total: 2500 W: 1181 L: 1109 D: 210

Functional change only for shogi variants.

Simplify casting extension

On November 16th, before the removal of the depth condition, I tried
revising castling extensions to only handle castling moves, rather than
moves that change castling rights generally. It appeared to be a slight
Elo gain at STC but insufficient to pass [0, 4] (+0.5 Elo), but what I
overlooked was that it made pos.can_castle(us) irrelevant and should
have been a simplification. Recent discussion with @Chess13234 and
Michael Chaly (@Vizvezdenec) inspired me to take a second look, and
the simplification continues to pass when rebased on the current master.

This replaces two conditions with one, because type_of(move) == CASTLING
implies pos.can_castle(Us), allowing us to remove the latter condition.

STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 110948 W: 24209 L: 24263 D: 62476
http://tests.stockfishchess.org/tests/view/5bf8f65c0ebc5902bced3a63

LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 88283 W: 14681 L: 14668 D: 58934
http://tests.stockfishchess.org/tests/view/5bf994a60ebc5902bced4349

Bench: 3939338

Turn on MADV_RANDOM for Syzygy mmaps (on Unix-like builds)

When running on a cloud VM (n1-highcpu-96) with several NVMe SSDs and
some non-SSDs for tablebases, I noticed that the average SSD request size was
more than 256 kB. This doesn't make a lot of sense for Syzygy tablebases,
which have a block size of 32 bytes and very low locality.

Seemingly, the tablebase access patterns during probing make the OS,
at least Linux, think that readahead is advantageous; normally, it
gives up doing readahead if there are too many misses, but it doesn't,
perhaps due to the fairly high overall hit rates. (It seems the kernel cannot
distinguish between reading a block that was paged in because the userspace
wanted it explicitly, and one that was read as part of readahead.)

Setting MADV_RANDOM effectively turns off readahead, which causes
the request size to drop to 4 kB. In the aforemented cloud VM test,
this roughly tripled the amount of I/O requests that were able to go
through, while reducing the total traffic from 2.8 GB/sec to 56 MB/sec
(moving the bottleneck to the non-SSDs; it seems the SSDs could have
sustained many more requests).

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

No functional change.

Qsearch simplification. (#1828)

Don't do an extra TT update in case of a fail-high,
but simply break off the moves loop and let the TT update
at the end of qsearch do this job.
Same workflow/logic as in our main search function now.

Tested for no regression to be on the safe side.
STC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 30237 W: 6665 L: 6560 D: 17012
http://tests.stockfishchess.org/tests/view/5bf928e80ebc5902bced3f3a

LTC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 51067 W: 8625 L: 8553 D: 33889
http://tests.stockfishchess.org/tests/view/5bf937180ebc5902bced3fdc

No functional change.

Reintroduce tropism to kingdanger

Tropism in kingdanger was simplified away in this pull request #1821.
This patch reintroduces tropism in kingdanger with using quadratic scaling.

Passed STC http://tests.stockfishchess.org/tests/view/5bf7c1b10ebc5902bced1f8f
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 52803 W: 11835 L: 11442 D: 29526

Passed LTC http://tests.stockfishchess.org/tests/view/5bf816e90ebc5902bced24f1
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 17204 W: 2988 L: 2795 D: 11421

How do we continue from there?

I've recently tried to introduce tropism difference term in kingdanger which
passed STC 6 times but failed LTC all the time. Maybe using quadratic scaling
for it will also be helpful.

Bench 4041387

Remove the tropism term from kingDanger

A recent LTC tuning session by @candirufish showed this term decreasing significantly. It appears that it can be removed altogether without significant Elo loss.

I also thank @GuardianRM, whose attempt to remove tropism from king danger inspired this one.

After this PR is merged, my next step will be to attempt to tune the coefficients of this new, simplified kingDanger calculation.

STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 12518 W: 2795 L: 2656 D: 7067
http://tests.stockfishchess.org/tests/view/5befadda0ebc595e0ae3a289

LTC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 164771 W: 26463 L: 26566 D: 111742
http://tests.stockfishchess.org/tests/view/5befcca70ebc595e0ae3a343

LTC 2, rebased on Stockfish 10 beta:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 75226 W: 12563 L: 12529 D: 50134
http://tests.stockfishchess.org/tests/view/5bf2e8910ebc5902bcecb919

Bench: 3412071

Force time check on TB probe in search.

Because of aggressive time management and optimistic assumptions
about move overhead, it's still very easy to get Stockfish to forfeit
on time when we hit an endgame and have Syzygy EGTB on a spinning
drive. The latency from serving a few thousand EGTB probes (~10ms each),
of which there can currently be up to 4000 outstanding before a time
check, will easily overwhelm the default Move Overhead of 30ms.

This problem was first raised by Gian-Carlo Pascutto and some solutions
and improvements were discussed in the following pull requests:
https://github.com/official-stockfish/Stockfish/pull/1471
https://github.com/official-stockfish/Stockfish/pull/1623
https://github.com/official-stockfish/Stockfish/pull/1783

This patch is a minimal change proposed by Marco Costalba to lower
the impact of the bug. We now force a check of the clock right after
each tablebase read.

No functional change.

Bonus for restricting opponent's piece moves

STC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 51883 W: 11297 L: 10915 D: 29671
http://tests.stockfishchess.org/tests/view/5bf1e2ee0ebc595e0ae3cacd

LTC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 15859 W: 2752 L: 2565 D: 10542
http://tests.stockfishchess.org/tests/view/5bf337980ebc5902bcecbf62

Notes:

(1) The bonus value has not been carefully tested, so it may be possible
to find slightly better values.

(2) Plan is to now try adding similar restriction for pawns. I wanted to
include that as part of this pull request, but I was advised to do it as
two separate pull requests. STC is currently running here, but may not add
enough value to pass green.

Bench: 3679086

Stockfish 10-beta

Preparation commit for the upcoming Stockfish 10 version, giving a chance to catch last minute feature bugs and evaluation regression during the one-week code freeze period. Also changing the copyright dates to include 2019.

No functional change

Tweak Queen PSQT based on tuned values

STC: (Yellow)
LLR: -2.96 (-2.94,2.94) [0.00,4.00]
Total: 63140 W: 13433 L: 13353 D: 36354
http://tests.stockfishchess.org/tests/view/5bed42c90ebc595e0ae37cf5

LTC: (Green)
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 47714 W: 7785 L: 7485 D: 32444
http://tests.stockfishchess.org/tests/view/5bec3b8c0ebc595e0ae36dec

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

Bench: 3717396

Tune evaluation scores

STC:
LLR: -2.96 (-2.94,2.94) [0.00,4.00]
Total: 84697 W: 18173 L: 18009 D: 48515
http://tests.stockfishchess.org/tests/view/5bea366f0ebc595e0ae34793

LTC:
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 157625 W: 25533 L: 24893 D: 107199
http://tests.stockfishchess.org/tests/view/5be8b69e0ebc595e0ae33024

Personally, I feel like SF has been tuned to death recently and that we
need to step away from existing-parameter tunes for a bit and focus more
on new ideas. I don't really think there's much more ELO in these tunes
(for now). For me at least, this was the last existing-parameter tune I'll
be running for quite a while. Cheers!

Bench: 3572567

Remove BlockedStorm array

Apparently, only RANK_3 is relevant. This removes a look-up and the
BlockedStorm array, but adds another conditional.

STC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 84340 W: 18054 L: 18054 D: 48232
http://tests.stockfishchess.org/tests/view/5bea10f40ebc595e0ae3457b

LTC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 31874 W: 5135 L: 5032 D: 21707
http://tests.stockfishchess.org/tests/view/5beadb6a0ebc595e0ae35542

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

Bench: 3799443

Simplify Castle Extension

Remove depth condition in castle extension, also don't extend if
Singular Extension and Check Extansion fail to extend.

STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 42070 W: 9118 L: 9036 D: 23916
http://tests.stockfishchess.org/tests/view/5be899cc0ebc595e0ae32f07

LTC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 78278 W: 12490 L: 12458 D: 53330
http://tests.stockfishchess.org/tests/view/5be8ac420ebc595e0ae33010

Bench: 3611041

Code style in search.cpp

It does not appear to be not necessary or advantageous to
conditionally initialize kingRing[Us] or kingAttackersCount[Them],
so the 'else' can be removed.

STC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 22873 W: 4923 L: 4804 D: 13146
http://tests.stockfishchess.org/tests/view/5be9a8270ebc595e0ae33c7e

No functional change

Update a comment in the evaluate.cpp file to reflect recent change

No functional change

Rook PSQT Tuned

Failed STC (Yellow )
LLR: -2.96 (-2.94,2.94) [0.00,4.00]
Total: 56302 W: 12007 L: 11953 D: 32342
http://tests.stockfishchess.org/tests/view/5be69d210ebc595e0ae3185b

Passed 1st LTC (Green)
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 8745 W: 1480 L: 1301 D: 5964
http://tests.stockfishchess.org/tests/view/5be682960ebc595e0ae31818

Failed 2nd LTC (Red)
LLR: -2.96 (-2.94,2.94) [0.00,4.00]
Total: 19398 W: 3040 L: 3133 D: 13225
http://tests.stockfishchess.org/tests/view/5be69b840ebc595e0ae31856

Passed 3rd LTC (Green)
LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 107516 W: 17342 L: 16858 D: 73316
http://tests.stockfishchess.org/tests/view/5bea879a0ebc595e0ae34d80

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

How to continue from there?

The values in the rook table now look a bit strange for a human eye
and are hard to explain, maybe it would be nice to simplify them
by hand and see if we can pass another (clean) double green with a
more regular array.

Bench: 3188070

Change default contempt from 21 to 24 centipawns

To top the rating lists and get more interesting middle play, it
is a good habit to set the default contempt to the highest value
that does not regress against contempt=0. We recently decreased
PawnValueEg it is logical that to raise a little bit the default
higher contempt because of the following internal dependency in
line 334 of search.cpp :

````
int ct = int(Options["Contempt"]) * PawnValueEg / 100; // From centipawns
````

STC: contempt=24 passed non-regression vs contempt=0
http://tests.stockfishchess.org/tests/view/5bd6d7f80ebc595e0ae21e14

LTC: contempt=24 passed non-regression LTC vs contempt=0
http://tests.stockfishchess.org/tests/view/5bd6e0980ebc595e0ae21f07

On 2018-11-01, we also tested the effects of contempt=21 and contempt=24
against Stockfish 9, and the net result was neutral:

Contempt 21
ELO: 51.68 +-1.9 (95%) LOS: 100.0%
Total: 40000 W: 9487 L: 3581 D: 26932
http://tests.stockfishchess.org/tests/view/5bdb1a140ebc595e0ae2620a

Contempt 24
ELO: 52.21 +-2.0 (95%) LOS: 100.0%
Total: 40000 W: 9759 L: 3793 D: 26448
http://tests.stockfishchess.org/tests/view/5bdb1b680ebc595e0ae2620d

Bench: 3459874

Clear TableBase mappings in Search::clear()

This patch will make possible to free mapped TB files with "ucinewgame" command.

We wrote this patch specifically to address a problem that arose while
running Stockfish with 7-piece tablebases as a kibitzer at TCEC for
extended periods of time across multiple games. It was noted that after
some time, the NPS of the kibitzing Stockfish (which is usually 3x faster
than the Stockfish actually competing) would drop precipitously, eventually
falling to preposterously low numbers until restarted.

Their eval bot basically inputs FEN, go infinite, stop and loop, it probably
didn't do ucinewgame either. As time goes it gradually slowed down and OS
starts to use swap, this is not reasonable since the engine only uses 16GB
hash and the machine has 1TB physical RAM and does nothing else.

Author : noobpwnftw

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

No functional change.

Simplify away redundant condition

No functional change.

Speed up move generation

Simplify move generation for piece promotions,
and fix quiet check piece promotions.

To compensate additionally generated quiet checks,
enable normal SEE calculation for piece promotions.

No functional change for variants without piece promotions.

Avoid qsearch explosions for clobber

Support clobber on 10x10 board

Fix winning condition for racing kings (close #9)

Correctly evaluate positions where both kings are on the back rank.

racingkings STC
LLR: 2.95 (-2.94,2.94) [-10.00,5.00]
Total: 354 W: 144 L: 95 D: 115
http://35.161.250.236:6543/tests/view/5be9cb8e6e23db7639060c7d

racingkings LTC
LLR: 2.97 (-2.94,2.94) [-10.00,5.00]
Total: 273 W: 110 L: 62 D: 101
http://35.161.250.236:6543/tests/view/5bea06106e23db7639060c80

Skip scale factor evaluation for drop games

shogi
ELO: 30.48 +-33.6 (95%) LOS: 96.4%
Total: 400 W: 210 L: 175 D: 15

euroshogi
ELO: 7.82 +-33.2 (95%) LOS: 67.8%
Total: 400 W: 194 L: 185 D: 21

minishogi
ELO: 6.95 +-32.9 (95%) LOS: 66.1%
Total: 400 W: 190 L: 182 D: 28

crazyhouse STC
LLR: -2.97 (-2.94,2.94) [-10.00,5.00]
Total: 8880 W: 4262 L: 4393 D: 225
http://35.161.250.236:6543/tests/view/5bdca1f56e23db7639060c58

crazyhouse LTC
LLR: 2.96 (-2.94,2.94) [-10.00,5.00]
Total: 1761 W: 882 L: 828 D: 51
http://35.161.250.236:6543/tests/view/5be616ff6e23db7639060c7b

Replace the PassedDanger array by an equation

This equation seems to do as well as the current PassedDanger array.

Master values were: 3, 7, 11, 20
The new values given by the equation are: 3, 6, 11, 18

STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 84301 W: 18155 L: 18156 D: 47990
http://tests.stockfishchess.org/tests/view/5bda03180ebc595e0ae2518e

LTC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 7940 W: 1358 L: 1217 D: 5365
http://tests.stockfishchess.org/tests/view/5bdc69880ebc595e0ae27d28

We stopped a LTC run after 70000 games:
LLR: 0.74 (-2.94,2.94) [0.00,4.00]
Total: 70257 W: 11319 L: 11064 D: 47874
http://tests.stockfishchess.org/tests/view/5bdca8420ebc595e0ae281a9

Bench: 3913185

Remove redundant king square parameter

We don't need to pass the king square as an explicit parameter to the functions
king_safety() and do_king_safety() since we already pass in the position.

STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 69686 W: 14894 L: 14866 D: 39926
http://tests.stockfishchess.org/tests/view/5be84ac20ebc595e0ae3283c

No functional change.

Speed up attackers_to

No functional change.

Speed up check info calculation

No functional change.

Simplify tropism. (#1807)

We calculate tropism as a sum of two factors. The first is the number of squares in our kingFlank and Camp that are attacked by the enemy; the second is number of these squares that are attacked twice. Prior to this commit, we excluded squares we defended with pawns from this second value, but this appears unnecessary. (Doubly-attacked squares near our king are still dangerous.) The removal of this exclusion is a possible small Elo gain at STC (estimated +1.59) and almost exactly neutral at LTC (estimated +0.04).

STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 20942 W: 4550 L: 4427 D: 11965
http://tests.stockfishchess.org/tests/view/5be4e0ae0ebc595e0ae308a0

LTC:
LLR: 2.94 (-2.94,2.94) [-3.00,1.00]
Total: 56941 W: 9172 L: 9108 D: 38661
http://tests.stockfishchess.org/tests/view/5be4ec340ebc595e0ae30938

Bench: 3813986

Support dobutsu shogi

Tweak evaluation for capture the flag variants

breakthrough
ELO: 269.37 +-44.7 (95%) LOS: 100.0%
Total: 400 W: 327 L: 67 D: 6

jesonmor
ELO: 338.04 +-110.9 (95%) LOS: 100.0%
Total: 100 W: 87 L: 12 D: 1

No functional change for other variants.

Support extended setup command of UCI2WB

Fix pseudo-legal move validation (resolves #12)

For pieces which move and capture in different ways,
the pseudo-legal move validation needs to take into account
whether a move is a capture or not.

This fixes the pseudo-legal move validation for breakthrough and hoppelpoppel.

breakthrough
ELO: 372.25 +-109.6 (95%) LOS: 100.0%
Total: 100 W: 86 L: 7 D: 7

hoppelpoppel
ELO: 530.72 +-154.4 (95%) LOS: 100.0%
Total: 100 W: 92 L: 1 D: 7

Update list of top CPU contributors

Contributors with >10,000 CPU hours as of November 4, 2018. Thank you!

No functional change

Pawn and Piece Values Tuned at LTC

Failed STC
LLR: -2.96 (-2.94,2.94) [0.00,4.00]
Total: 27487 W: 5846 L: 5903 D: 15738
http://tests.stockfishchess.org/tests/view/5be1d3190ebc595e0ae2e5b8

Passed 1st LTC
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 38503 W: 6270 L: 5999 D: 26234
http://tests.stockfishchess.org/tests/view/5be1f5ef0ebc595e0ae2e750

Passed 2nd LTC
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 34016 W: 5584 L: 5326 D: 23106
http://tests.stockfishchess.org/tests/view/5be2a1970ebc595e0ae2f1b4

This pull request lead to an interesting discussion about testing
methodology for Stockfish:
https://github.com/official-stockfish/Stockfish/pull/1804

Bench: 3647775

fixup

Extension for king moves changing castling rights

passed STC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 8463 W: 1919 L: 1747 D: 4797
http://tests.stockfishchess.org/tests/view/5be15d510ebc595e0ae2dec6

passed LTC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 142590 W: 23263 L: 22587 D: 96740
http://tests.stockfishchess.org/tests/view/5be1667b0ebc595e0ae2df2d

Bench: 3607243

Fix #11 Sittuyin promotion bug

Fix check detection for Sittuyin promotions.

Tweak evaluation for breakthrough

breakthrough
ELO: 200.24 +-78.6 (95%) LOS: 100.0%
Total: 100 W: 73 L: 21 D: 6

Simplify definition of shogi variants

No functional change.

Simplify mobility danger

Check sign only after adding mobility danger term.

STC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 9090 W: 2001 L: 1856 D: 5233
http://tests.stockfishchess.org/tests/view/5bdc5ee10ebc595e0ae27bc2

LTC
LLR: 2.94 (-2.94,2.94) [-3.00,1.00]
Total: 123466 W: 19766 L: 19805 D: 83895
http://tests.stockfishchess.org/tests/view/5bdc678e0ebc595e0ae27cf3

bench: 3630207

Update readme

Support Sittuyin (Burmese chess)

- Rook drops are limited to back ranks.
- Promotion is allowed on main diagonals within opponent's half
  or when only one pawn is left. The player must not have a general.
- Promoting pawns stay on same square or move like a general.
- Pawn promotions may not capture or give check.

Support placement chess (close #10)

In order to support placement chess, new options are added:
- mandatory piece drops
- limiting drops to certain squares
- castling with dropped pieces
- bishop drops on opposite colors

Furthermore, support slash as separator for pieces in hand in FENs
of drop games for compatibility with FENs from pychess and lichess.

Simplify variant definitions

Reuse variant definitions to derive other variants.

No functional change.

Rewrite lambdas into functions

No functional change.

Tweak piece promotion bonus

shogi
ELO: 4.34 +-33.0 (95%) LOS: 60.2%
Total: 400 W: 190 L: 185 D: 25

euroshogi
ELO: 36.62 +-33.8 (95%) LOS: 98.4%
Total: 400 W: 215 L: 173 D: 12

minishogi
ELO: 15.65 +-32.7 (95%) LOS: 82.6%
Total: 400 W: 193 L: 175 D: 32

Penalty for isolated shogi pawns

shogi
ELO: 6.95 +-33.2 (95%) LOS: 66.0%
Total: 400 W: 193 L: 185 D: 22

euroshogi
ELO: 20.87 +-33.1 (95%) LOS: 89.3%
Total: 400 W: 200 L: 176 D: 24

minishogi
ELO: 26.11 +-32.9 (95%) LOS: 94.1%
Total: 400 W: 200 L: 170 D: 30

Consider shogi pawns in threat evaluation

shogi
ELO: 50.74 +-34.0 (95%) LOS: 99.9%
Total: 400 W: 224 L: 166 D: 10

euroshogi
ELO: 14.77 +-33.7 (95%) LOS: 80.6%
Total: 400 W: 203 L: 186 D: 11

minishogi
ELO: -2.61 +-33.1 (95%) LOS: 43.9%
Total: 400 W: 187 L: 190 D: 23

Skip initiative bonus for drop games

shogi
ELO: 23.49 +-33.7 (95%) LOS: 91.5%
Total: 400 W: 208 L: 181 D: 11

euroshogi
ELO: 18.26 +-33.5 (95%) LOS: 85.8%
Total: 400 W: 203 L: 182 D: 15

minishogi
ELO: -6.08 +-33.0 (95%) LOS: 35.9%
Total: 400 W: 184 L: 191 D: 25

crazyhouse STC
LLR: 2.97 (-2.94,2.94) [-10.00,5.00]
Total: 1980 W: 993 L: 940 D: 47
http://35.161.250.236:6543/tests/view/5bdca2176e23db7639060c5a

Add connected bonus for shogi pawns

shogi
ELO: 26.11 +-33.2 (95%) LOS: 93.9%
Total: 400 W: 204 L: 174 D: 22

euroshogi
ELO: 15.65 +-33.7 (95%) LOS: 81.9%
Total: 400 W: 204 L: 186 D: 10

minishogi
ELO: 0.87 +-32.8 (95%) LOS: 52.1%
Total: 400 W: 185 L: 184 D: 31

Tweak mobility bonus for fairy pieces

shogi
ELO: 44.54 +-33.9 (95%) LOS: 99.6%
Total: 400 W: 220 L: 169 D: 11

euroshogi
ELO: 25.23 +-33.6 (95%) LOS: 93.0%
Total: 400 W: 208 L: 179 D: 13

minishogi
ELO: 59.64 +-33.3 (95%) LOS: 100.0%
Total: 400 W: 220 L: 152 D: 28

makruk
ELO: 11.30 +-17.6 (95%) LOS: 89.6%
Total: 400 W: 60 L: 47 D: 293

Implement SEE for piece drops

crazyhouse STC
LLR: 2.96 (-2.94,2.94) [-10.00,5.00]
Total: 199 W: 129 L: 64 D: 6
http://35.161.250.236:6543/tests/view/5bdd6d426e23db7639060c61

shogi
ELO: 15.65 +-33.1 (95%) LOS: 82.4%
Total: 400 W: 197 L: 179 D: 24

euroshogi
ELO: 78.62 +-34.4 (95%) LOS: 100.0%
Total: 400 W: 238 L: 149 D: 13

minishogi
ELO: 36.62 +-32.7 (95%) LOS: 98.7%
Total: 400 W: 203 L: 161 D: 36

Rook tweaks in evaluation

Some small changes in evaluation to try to convince Stockfish to centralize
her rooks more in middle game and avoid trapping them in the corners. Joint
work by SFisGOD and snicolet.

STC:
LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 99826 W: 21895 L: 21341 D: 56590
http://tests.stockfishchess.org/tests/view/5bdc3e280ebc595e0ae277df

LTC:
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 21467 W: 3541 L: 3322 D: 14604
http://tests.stockfishchess.org/tests/view/5bdc9ff30ebc595e0ae28119

Bench: 3631608

Fix calculation of non-pawn material for drop games

Do not consider pieces in hand for nonPawnMaterial.

shogi
ELO: 33.11 +-21.2 (95%) LOS: 99.9%
Total: 1000 W: 529 L: 434 D: 37

euroshogi
ELO: 23.31 +-21.0 (95%) LOS: 98.6%
Total: 1000 W: 508 L: 441 D: 51

minishogi
ELO: -68.99 +-17.5 (95%) LOS: 0.0%
Total: 1000 W: 228 L: 424 D: 348

crazyhouse STC
LLR: -2.98 (-2.94,2.94) [-10.00,5.00]
Total: 1020 W: 463 L: 538 D: 19

Always evaluate space for drop games

Furthermore, consider shogi pawns in space evaluation
and fix a bug for the large board version.

crazyhouse STC (failed)
LLR: -2.97 (-2.94,2.94) [-10.00,5.00]
Total: 3008 W: 1430 L: 1519 D: 59
http://35.161.250.236:6543/tests/view/5bd9a7b96e23db7639060c3e

shogi
ELO: 36.62 +-33.5 (95%) LOS: 98.5%
Total: 400 W: 212 L: 170 D: 18

euroshogi
ELO: 34.86 +-33.4 (95%) LOS: 98.1%
Total: 400 W: 210 L: 170 D: 20

minishogi
ELO: 9.38 +-16.9 (95%) LOS: 86.2%
Total: 1000 W: 322 L: 295 D: 383

chess (large-board version)
ELO: 9.56 +-27.6 (95%) LOS: 75.1%
Total: 400 W: 137 L: 126 D: 137

Fix issues from using adjustedDepth too broadly

The recently committed Fail-High patch (081af9080542a0d076a5482da37103a96ee15f64)
had a number of changes beyond adjusting the depth of search on fail high, with
some undesirable side effects.

1) Decreasing depth on PV output, confusing GUIs and players alike as described in
   issue #1787. The depth printed is anyway a convention, let's consider adjustedDepth
   an implementation detail, and continue to print rootDepth. Depth, nodes, time and
   move quality all increase as we compute more. (fixing this output has no effect on
   play).

2) Fixes go depth output (now based on rootDepth again, no effect on play), also
   reported in issue #1787

3) The depth lastBestDepth is used to compute how long a move is stable, a new move
   found during fail-high is incorrectly considered stable if based on adjustedDepth
   instead of rootDepth (this changes time management). Reverting this passed STC
   and LTC:

   STC
   LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
   Total: 82982 W: 17810 L: 17808 D: 47364
   http://tests.stockfishchess.org/tests/view/5bd391a80ebc595e0ae1e993

   LTC
   LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
   Total: 109083 W: 17602 L: 17619 D: 73862
   http://tests.stockfishchess.org/tests/view/5bd40c820ebc595e0ae1f1fb

4) In the thread voting scheme, the rank of the fail-high thread is now artificially
   low, incorrectly since the quality of the move is much better than what adjustedDepth
   suggests (e.g. if it takes 10 iterations to find VALUE_KNOWN_WIN, it has very low
   depth). Further evidence comes from a test that showed that the move of highest
   depth is not better than that of the last PV (which is potentially of much lower
   adjustedDepth).

   I.e. this test http://tests.stockfishchess.org/tests/view/5bd37a120ebc595e0ae1e7c3
   failed SPRT[0, 5]:

   LLR: -2.95 (-2.94,2.94) [0.00,5.00]
   Total: 10609 W: 2266 L: 2345 D: 5998

   In a running 5+0.05 th 8 test (more than 10000 games) a positive Elo estimate is
   shown (strong enough for a [-3,1], possibly not [0,4]):

   http://tests.stockfishchess.org/tests/view/5bd421be0ebc595e0ae1f315
   LLR: -0.13 (-2.94,2.94) [0.00,4.00]
   Total: 13644 W: 2573 L: 2532 D: 8539
   Elo 1.04 [-2.52,4.61] / LOS 71%

Thus, restore old behavior as a bugfix, keeping the core of the fail-high patch
idea as resolving scheme. This is non-functional for bench, but changes searches
via time management and in the threaded case.

Bench: 3556672

Combo

Combo of two parameter tweaks and tuned values for Queen and ThreatByKing.

STC
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 20180 W: 4439 L: 4198 D: 11543
http://tests.stockfishchess.org/tests/view/5bd7b8250ebc595e0ae22e97

LTC
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 86312 W: 14106 L: 13685 D: 58521
http://tests.stockfishchess.org/tests/view/5bd803560ebc595e0ae23213

This combo consists of the following:

Queen Value (tuned values)
Iter: 72056, A: 5000, alpha 0.602000, gamma 0.101000, clipping old, rounding deterministic
param: QueenValueMg, best: 2528.91, start: 2528.00
param: QueenValueEg, best: 2687.12, start: 2698.00

ThreatByKing (tuned values)
Green STC (50.8k games)
http://tests.stockfishchess.org/tests/view/5bd1d5a00ebc595e0ae1cbec
LTC (I stopped this test at 71.2k games. It's likely yellow.)
http://tests.stockfishchess.org/tests/view/5bd263e70ebc595e0ae1d77e

WeakUnopposedPawn (tweak) by xoto (https://github.com/xoto10)
Green STC (102.8k games)
http://tests.stockfishchess.org/tests/view/5bd306bb0ebc595e0ae1e146
Yellow LTC (90.8k games)
http://tests.stockfishchess.org/tests/view/5bd3ea660ebc595e0ae1f16b

aspiTune1 (tweak) by vondele (https://github.com/vondele)
Green STC (125.9k games)
http://tests.stockfishchess.org/tests/view/5bd2ae100ebc595e0ae1dab0
Yellow LTC (107.9k games)
http://tests.stockfishchess.org/tests/view/5bd3eb700ebc595e0ae1f16f

Thank you @31m059 (Mark Tenzer) for helping me! Also, thank you very much
for recognizing my efforts. I genuinely appreciate it.

Bench: 3556672

Add bonus for potential piece promotions

shogi
ELO: 21.57 +-20.7 (95%) LOS: 98.0%
Total: 1000 W: 490 L: 428 D: 82

euroshogi
ELO: 36.62 +-21.1 (95%) LOS: 100.0%
Total: 1000 W: 528 L: 423 D: 49

minishogi
ELO: 39.08 +-16.9 (95%) LOS: 100.0%
Total: 1000 W: 363 L: 251 D: 386

Cap king danger for all variants

Stabilize evaluation by limiting king danger.

3check STC
LLR: -2.95 (-2.94,2.94) [0.00,10.00]
Total: 12796 W: 5948 L: 5860 D: 988
http://35.161.250.236:6543/tests/view/5b7fa10c6e23db0fbab0dcc7

3check LTC
LLR: 0.04 (-2.94,2.94) [0.00,10.00]
Total: 10691 W: 4990 L: 4836 D: 865
http://35.161.250.236:6543/tests/view/5bc2d7a36e23db7639060bf5

crazyhouse STC
LLR: -2.96 (-2.94,2.94) [0.00,10.00]
Total: 7666 W: 3772 L: 3763 D: 131
http://35.161.250.236:6543/tests/view/5b7f1ad66e23db0fbab0dcbc

crazyhouse LTC
LLR: -2.95 (-2.94,2.94) [0.00,10.00]
Total: 6868 W: 3341 L: 3342 D: 185
http://35.161.250.236:6543/tests/view/5baf76c46e23db0fbab0ddec

chess STC
ELO: 4.17 +-10.1 (95%) LOS: 79.0%
Total: 2000 W: 454 L: 430 D: 1116
http://35.161.250.236:6543/tests/view/5b7fa0d96e23db0fbab0dcc5

chess LTC
ELO: 1.91 +-9.5 (95%) LOS: 65.3%
Total: 2000 W: 398 L: 387 D: 1215
http://35.161.250.236:6543/tests/view/5bbdbcff6e23db7639060be0

shogi
ELO: 25.23 +-32.2 (95%) LOS: 93.9%
Total: 400 W: 192 L: 163 D: 45

euroshogi
ELO: 13.90 +-31.6 (95%) LOS: 80.6%
Total: 400 W: 180 L: 164 D: 56

minishogi
ELO: 24.36 +-27.6 (95%) LOS: 95.9%
Total: 400 W: 145 L: 117 D: 138

bench: 5141418

Less move count pruning for drop variants

crazyhouse STC
LLR: 2.97 (-2.94,2.94) [0.00,10.00]
Total: 1472 W: 780 L: 658 D: 34
http://35.161.250.236:6543/tests/view/5bd8ad6e6e23db7639060c37

More IID for drop games

STC crazyhouse
LLR: 2.95 (-2.94,2.94) [0.00,10.00]
Total: 8079 W: 4045 L: 3829 D: 205
http://35.161.250.236:6543/tests/view/5bd0e26e6e23db7639060c16

Tweak of knight PSQT and mobility bonuses

STC
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 16906 W: 3745 L: 3516 D: 9645
http://tests.stockfishchess.org/tests/view/5bd306a40ebc595e0ae1e144

LTC
LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 62779 W: 10249 L: 9901 D: 42629
http://tests.stockfishchess.org/tests/view/5bd3188f0ebc595e0ae1e296

Bench 3166402

On main thread: reduce depth after fail high

This helps resolving consecutive FH's during aspiration more efficiently

STC:
http://tests.stockfishchess.org/tests/view/5bc857920ebc592439f85765
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 4992 W: 1134 L: 980 D: 2878 Elo +10.72

LTC:
http://tests.stockfishchess.org/tests/view/5bc868050ebc592439f857ef
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 8123 W: 1363 L: 1210 D: 5550 Elo +6.54

No-Regression test with 8 threads, tc=15+0.15:
http://tests.stockfishchess.org/tests/view/5bc874ca0ebc592439f85938
LLR: 2.94 (-2.94,2.94) [-3.00,1.00]
Total: 24740 W: 3977 L: 3863 D: 16900 Elo +1.60

This was a cooperation between me and Michael Stembera:
-me recognizing SF having problems with resolving FH's efficiently at
high depths, thus starting some tests based on consecutive FH's.
-mstembera picking up the idea with first success at STC & LTC (so full
credits to him!)
-me suggesting how to resolve the issues pinpointed by S.G on PR #1768
and finally restricting the logic to the main thread so that it don't
regresses at multi-thread.

bench: 3314347

NUMA for 9 threads or more

Enable numa machinery only for STRICTLY MORE than 8 threads. Reason for this
change is that nowadays SMP tests are always done with 8 threads. That is a
problem for multi-socket Windows machines running on fishtest.

No functional change