Merge official-stockfish/master

bench: 4756806

Speed up move generation for xiangqi

Filter out invalid soldier and general moves early.

Fix perpetual check detection

Consider also perpetual checks by side to move
in order to avoid wrong draw scores.

Closes #49.

More pieceToCharTable definitions

Merge official-stockfish/master

bench: 4552352

Add xiangqihouse to variants.ini

Enhance bitboard parsing to simplify definition.

Introduce king flank defenders

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

What to do based on this?

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

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

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

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

Bench: 4496847

Add pieceToCharTable for more variants

Improve XBoard compatibility for more variants.

Tweak piece values for xiangqi

xiangqi
LLR: 2.97 (-2.94,2.94) [0.00,10.00]
Total: 1704 W: 506 L: 416 D: 782

Improve displaying of position

Add side to move and pockets to output of `d` command (#47).

Support Manchu chess

https://en.wikipedia.org/wiki/Manchu_chess

bench: 4700464

Define variant template for minixiangqi

Improve XBoard compatibility

Support pieceToCharTable in setup command to improve compatibility (#54).

Improve XBoard compatibility for makruk variants

Prune before extension

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

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

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

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

Bench: 4532366

Support New Zealand chess

Allow castling with one non-rook piece type and add New Zealand chess (#52).

bench: 4470822

Support Centaur chess

https://www.chessvariants.com/large.dir/contest/royalcourt.html

Closes #33.

bench: 4556696

Support debug commands also in XBoard protocol

Commands `d` and `eval` can now also be used in xboard protocol (#47).

Separate XBoard protocol code

Split UCI and XBoard protocol code for better maintainability.

No functional change.

Tweak piece values for hoppelpoppel

hoppelpoppel STC
LLR: 2.95 (-2.94,2.94) [0.00,10.00]
Total: 159 W: 113 L: 25 D: 21
http://www.variantfishtest.org:6543/tests/view/5dcc4d846e23db1ffe4a2734

hoppelpoppel LTC
LLR: 2.95 (-2.94,2.94) [0.00,10.00]
Total: 136 W: 100 L: 16 D: 20
http://www.variantfishtest.org:6543/tests/view/5dcc61d96e23db1ffe4a2739

Rank-based outposts

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

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

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

Bench: 4778405

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

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

Avoid copying of pieceToChar string

Small speed-up by using references.

Fix description of chancellor in variants.ini

Support perft command in xboard protocol

Update documentation in variants.ini

Describe recently added configuration options.

Shallow depth pruning on NonPV advanced pawn push

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

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

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

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

Bench: 4422068

Remove explicit moveCount pruning

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

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

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

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

Bench: 4256440

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

How to continue from there?

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

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

Sequencing tweak in tbprobe()

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

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

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

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

Non functional change

Fix incorrect mate score.

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

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

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

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

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

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

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

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

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

Bench: 4362323

Set default variant based on protocol

Improve compatibility with shogi and xiangqi GUIs
by setting suitable defaults for UCI_Variant:
UCI: chess
USI: shogi
UCCI: xiangqi
xboard: chess

Update list of supported protocols in readme

Further increase king danger for xiangqi

xiangqi
LLR: 2.97 (-2.94,2.94) [0.00,10.00]
Total: 564 W: 199 L: 121 D: 244

Fix king ring for non-standard board sizes

Adjust king danger for shogi variants to compensate for effect of fix.

Fix attackers calculation for xiangqi generals

xiangqi
LLR: 1.77 (-2.94,2.94) [0.00,10.00]
Total: 1000 W: 330 L: 274 D: 396

Mitigate perpetual check blindness

Improve handling of problematic positions in #49.

Increase king danger for xiangqi generals

xiangqi
LLR: 2.95 (-2.94,2.94) [0.00,10.00]
Total: 648 W: 249 L: 166 D: 233

Calculate pins by cannons

xiangqi
LLR: 3.01 (-2.94,2.94) [0.00,10.00]
Total: 868 W: 303 L: 218 D: 347

Tweak endgame scale factor for xiangqi

xiangqi
LLR: 3.00 (-2.94,2.94) [0.00,10.00]
Total: 1232 W: 413 L: 324 D: 495

Improve CI coverage

Support UCCI protocol

http://www.xqbase.com/protocol/cchess_ucci.htm

Closes #46.

Search checking captures early in drop variants

crazyhouse STC (yellow)
LLR: -2.96 (-2.94,2.94) [0.00,10.00]
Total: 19119 W: 9373 L: 9198 D: 548
http://www.variantfishtest.org:6543/tests/view/5d93b6486e23db3768ec0881

crazyhouse LTC
LLR: 2.97 (-2.94,2.94) [0.00,10.00]
Total: 5822 W: 2894 L: 2711 D: 217
http://www.variantfishtest.org:6543/tests/view/5d94cc056e23db3768ec0892

crazyhouse VLTC
LLR: 2.95 (-2.94,2.94) [0.00,10.00]
Total: 10293 W: 5048 L: 4802 D: 443
http://www.variantfishtest.org:6543/tests/view/5d97772d6e23db3768ec0898

Support xiangqi and minixiangqi

New features:
- Piece types soldier, horse, and elephant
- Restriction of piece mobility
- Flying general rule
- Piece synonyms

Closes #31.

bench: 4448277

Revert "Rook PSQT Tuned"

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

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

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

Bench: 4362323

Rook PSQT Tuned

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

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

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

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

Bench: 4707799

Remove shuffle extension

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

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

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

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

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

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

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

Bench: 4362323

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

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

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

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

Make Square and Bitboard operators commutative

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

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

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

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

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

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

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

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

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

No functional change.

Ensure that GUI sends time command in CECP

Fix mate score for XBoard protocol (#44)

Replace hard-coded variant name

No functional change.

Fix mate score for XBoard protocol (#44)

Support XBoard protocol (close #37)

Fix quiet check move generation

Do not generate quiet checks outside of board in quiescence search.

Closes #45.

Combo of Parameter Tweaks

This patch is a combo of the following tweaks:

Complexity parameters
Knight PSQT
Bishop PSQT
King PSQT
Piece Values

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

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

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

Bench: 4312945

Simplify kingRing

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

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

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

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

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

Bench: 4959244

Consolidate pawn_push and up

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

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

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

No functional change

Tweak dynamic contempt (the birthday patch)

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

Further proceedings:

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

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

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

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

No functional change (for current default contempt 24).

Consistent capture_or_promotion for special moves

No functional change except for cambodian, micro, and kyotoshogi.

Rewrite king danger of pieces in hand

crazyhouse STC
LLR: 2.96 (-2.94,2.94) [0.00,10.00]
Total: 1056 W: 576 L: 460 D: 20
http://www.variantfishtest.org:6543/tests/view/5db370d96e23db1ffe4a2671

crazyhouse LTC
LLR: 2.96 (-2.94,2.94) [0.00,10.00]
Total: 708 W: 399 L: 289 D: 20
http://www.variantfishtest.org:6543/tests/view/5db410896e23db1ffe4a2679

Refactor final stats updates.

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

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

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

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

No functional change

Assorted trivial cleanups

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

No functional change

Reduce memory footprint of continuation history

Close #43.

No functional change.

Merge official-stockfish/master

bench: 4231542

Simplify reductions on singular extension

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

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

Claims the first blue at STC and LTC:

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

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

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

Bench: 5115841

Avoid crashing on Log File opening

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

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

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

No functional change.

Return to development version

Fairy-Stockfish 10.3

bench: 3686859

Describe variant configuration inheritance in INI

Remove uithread

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

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

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

No functional change.

Scale piece values with board size

losalamos STC
LLR: 2.98 (-2.94,2.94) [0.00,10.00]
Total: 786 W: 242 L: 164 D: 380
http://35.161.250.236:6543/tests/view/5da456e16e23db3768ec0928

losalamos LTC
LLR: 2.97 (-2.94,2.94) [0.00,10.00]
Total: 480 W: 161 L: 87 D: 232
http://35.161.250.236:6543/tests/view/5da4790a6e23db3768ec092a

courier STC
LLR: 2.98 (-2.94,2.94) [0.00,10.00]
Total: 1971 W: 550 L: 459 D: 962
http://35.161.250.236:6543/tests/view/5da4f9696e23db3768ec0938

courier LTC
LLR: 2.97 (-2.94,2.94) [0.00,10.00]
Total: 755 W: 231 L: 154 D: 370
http://35.161.250.236:6543/tests/view/5da4fa306e23db3768ec093b

Current capture for Counter-Move history

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

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

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

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

Bench: 4423737

More documentation in variants.ini (close #30)

Fix #41: 50-move rule for Sittuyin

Add four positions to bench

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

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

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

Bench: 4590210

Support Cambodian chess (Ouk Chatrang, Kar Ouk) (close #39)

https://en.wikipedia.org/wiki/Makruk#Cambodian_chess

- Captures by special move of queen/neang are allowed.
- King may only make its leap if the side to move is not in check,
  and if the move does not capture a piece.

No functional change for existing variants.

Set castling rights only if enabled

Makes FEN parsing more robust and allows to support S-Chess without castling.

Fix compiler warnings for large-board version

No functional change.

Amendment for documentation update (#30)

Extend variant INI documentation (#30)

Introduce separate counter-move tables for inCheck

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

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

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

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

Bench: 4053577

No reachable outpost bonus for bishops

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

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

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

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

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

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

Bench: 3941591

Fix pseudo-legal move validation (close #35)

sittuyin STC
LLR: 2.95 (-2.94,2.94) [0.00,10.00]
Total: 126 W: 60 L: 2 D: 64
http://35.161.250.236:6543/tests/view/5d9b94916e23db3768ec08f3

sittuyin LTC
LLR: 2.96 (-2.94,2.94) [0.00,10.00]
Total: 111 W: 58 L: 1 D: 52
http://35.161.250.236:6543/tests/view/5d9b9f566e23db3768ec08fd

bench: 3686859

Adjust aspiration window with eval

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

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

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

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

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

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

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

Bench: 4043748

Tweak kingFlankAttacks factor in kingDanger

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

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

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

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

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

Bench: 4042155

Adjust pawn span

Run as a simplification

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

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

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

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

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

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

bench: 3812891

Make priorCapture a bool

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

No functional change.

Introduce separate counter-move tables for captures

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

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

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

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

Bench: 4131643

Eliminate ONE_PLY

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

No functional change

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

The argument favoring eliminating ONE_PLY:

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

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

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

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

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

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

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

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

Fix compare function in previous patch

Bench: 4012371

Remove temporary shelter array

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

Speed benchmark did not measure any difference.

No functional change

Support generation of SFEN (gbtami/pychess-variants#36)

Report SFEN next to FEN in the "d" command.

Support Makrukhouse (Makruk+Crazyhouse hybrid)

Speed up move picking for losing chess

giveaway STC
LLR: 2.95 (-2.94,2.94) [0.00,10.00]
Total: 403 W: 203 L: 114 D: 86
http://35.161.250.236:6543/tests/view/5d93a8726e23db3768ec087a

giveaway LTC
LLR: 2.96 (-2.94,2.94) [0.00,10.00]
Total: 369 W: 178 L: 93 D: 98
http://35.161.250.236:6543/tests/view/5d93be896e23db3768ec088a

losers STC
LLR: 2.96 (-2.94,2.94) [0.00,10.00]
Total: 539 W: 290 L: 190 D: 59
http://35.161.250.236:6543/tests/view/5d93a8fd6e23db3768ec087d

losers LTC
LLR: 2.97 (-2.94,2.94) [0.00,10.00]
Total: 604 W: 314 L: 214 D: 76
http://35.161.250.236:6543/tests/view/5d93be916e23db3768ec088c

codrus STC
LLR: 2.95 (-2.94,2.94) [0.00,10.00]
Total: 857 W: 477 L: 364 D: 16
http://35.161.250.236:6543/tests/view/5d93a9126e23db3768ec087f

More accurate pawn attack span definition

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

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

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

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

Bench: 4012371

Adjust reductions based on the number of threads

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

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

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

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

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

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

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

Bench: 4088701

Fixup: remove redundant code.

Make drop region constraint more explicit

No functional change.

Remove ThreatByRank

This is a functional simplification that removes ThreatByRank.

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

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

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

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

bench 4088701

Remove depth dependence in value_draw().

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

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

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

Bench: 4062526

Extend castling independently of singular extension

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

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

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

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

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

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

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

Bench: 3728191

--------

Where do we go from here?

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

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

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

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

Simplify RookOnPawn

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

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

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

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

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

Run as a simplification

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

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

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

bench: 4037914

Support "coffeehouse" chess

Crazyhouse with mandatory captures.