No functional change

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

Verified also in the Chess960 castling case by running a couple of perft, see
the pull request discussion: #2460

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

No functional change

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

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

Closes #2485

No functional change

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

master: 39.4 seconds
patch: 11.4 seconds.

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

Closes #2498

No functional change

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

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

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

Closes #2502

No functional change

Fixes conflict with tune.h STRINGIFY macro.

No functional change

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

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

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

CLoses #2496

bench: 4561386

At expected PV nodes or nodes which marked as PV node in the hash table,
reduce escape moves even one ply less.

STC:
LLR: 2.94 (-2.94,2.94) {-1.00,3.00}
Total: 31795 W: 6140 L: 5953 D: 19702
Ptnml(0-2): 525, 3625, 7455, 3695, 583
http://tests.stockfishchess.org/tests/view/5e25d77fc3b97aa0d75bc013

LTC:
LLR: 2.94 (-2.94,2.94) {0.00,2.00}
Total: 43975 W: 5708 L: 5454 D: 32813
Ptnml(0-2): 314, 4012, 13070, 4242, 325
http://tests.stockfishchess.org/tests/view/5e2618c1c3b97aa0d75bc03c

Closes #2505

Bench: 4475583

This patch greatly increases the endgame penalty for having a trapped rook.
Idea was a result of witnessing Stockfish losing some games at CCCC exchanging
pieces in the position with a trapped rook which directly lead to a lost endgame.
This patch should partially fix such behavior making this penalty high even in
deep endgames.

Passed STC
http://tests.stockfishchess.org/tests/view/5e279d7cc3b97aa0d75bc1c4
LLR: 2.94 (-2.94,2.94) {-1.00,3.00}
Total: 8528 W: 1706 L: 1588 D: 5234
Ptnml(0-2): 133, 957, 1985, 1024, 159

Passed LTC
http://tests.stockfishchess.org/tests/view/5e27aee4c3b97aa0d75bc1e1
LLR: 2.95 (-2.94,2.94) {0.00,2.00}
Total: 88713 W: 11520 L: 11130 D: 66063
Ptnml(0-2): 646, 8170, 26342, 8492, 676

Closes #2510

Bench: 4964462

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

Comment by Malcolm Campbell:

Congrats! I think this might be a common pattern - scores that seem to mainly apply
to the midgame are often better with a similar (or at least fairly big) endgame value
as well. Maybe there are others eval parameters we can tweak like this...

Use a SEE pruned capture move for history updates: this patch collects
pruned capture moves also in the failed captures list, so that they get
an update in capture history.

STC:
LLR: 2.95 (-2.94,2.94) {-1.00,3.00}
Total: 11124 W: 2222 L: 2089 D: 6813
Ptnml(0-2): 186, 1280, 2506, 1381, 200
http://tests.stockfishchess.org/tests/view/5e28995fc3b97aa0d75bc294

LTC:
LLR: 2.94 (-2.94,2.94) {0.00,2.00}
Total: 25552 W: 3418 L: 3211 D: 18923
Ptnml(0-2): 168, 2354, 7538, 2490, 200
http://tests.stockfishchess.org/tests/view/5e2943734744cfa4d6af415b

Closes #2511

Bench: 4810202

Double the "RestrictedPiece" bonus for restricted moves targeting
occupied squares.

STC LLR: 3.58 (-2.94,2.94) {-1.00,3.00}
    Total: 25504 W: 4887 L: 4697 D: 15920
    Ptnml(0-2): 387, 2935, 5947, 3051, 422
    https://tests.stockfishchess.org/tests/view/5e2aa15dab2d69d58394f94d

LTC LLR: 2.94 (-2.94,2.94) {0.00,2.00}
    Total: 28572 W: 3826 L: 3621 D: 21125
    Ptnml(0-2): 224, 2609, 8403, 2791, 239
    https://tests.stockfishchess.org/tests/view/5e2ae7f4ab2d69d58394f9a6

Bench: 4719086

Instead of computing the initiative bonus on the material score + dynamic score
compute it on (material score/2) + dynamic score,

Passed STC
http://tests.stockfishchess.org/tests/view/5e2c4945ab2d69d58394fa8f
LLR: 2.94 (-2.94,2.94) {-1.00,3.00}
Total: 39387 W: 7594 L: 7386 D: 24407
Ptnml(0-2): 658, 4519, 9165, 4649, 697

Passed LTC
http://tests.stockfishchess.org/tests/view/5e2c85ccab2d69d58394faa7
LLR: 2.95 (-2.94,2.94) {0.00,2.00}
Total: 32588 W: 4206 L: 3986 D: 24396
Ptnml(0-2): 244, 2909, 9738, 3111, 253

closes #2516

Bench: 4765486

Align the TT allocation by 2M to make it huge page friendly and advise the
kernel to use huge pages.

Benchmarks on my i7-8700K (6C/12T) box: (3 runs per bench per config)

                    vanilla (nps)               hugepages (nps)              avg
==================================================================================
bench             | 3012490  3024364  3036331   3071052  3067544  3071052    +1.5%
bench 16 12 20    | 19237932 19050166 19085315  19266346 19207025 19548758   +1.1%
bench 16384 12 20 | 18182313 18371581 18336838  19381275 19738012 19620225   +7.0%

On my box, huge pages have a significant perf impact when using a big
hash size. They also speed up TT initialization big time:

                                  vanilla (s)  huge pages (s)  speed-up
=======================================================================
time stockfish bench 16384 1 1  | 5.37         1.48            3.6x

In practice, huge pages with auto-defrag may always be enabled in the
system, in which case this patch has no effect. This
depends on the values in /sys/kernel/mm/transparent_hugepage/enabled
and /sys/kernel/mm/transparent_hugepage/defrag.

closes #2463

No functional change

Adjust initiative score by psqt/2 instead of materialScore/2 which simplifies #2516

Passed STC
http://tests.stockfishchess.org/tests/view/5e2e667dab2d69d58394fc73
LLR: 2.94 (-2.94,2.94) {-1.50,0.50}
Total: 23198 W: 4506 L: 4353 D: 14339
Ptnml(0-2): 396, 2615, 5380, 2728, 418

Passed LTC
http://tests.stockfishchess.org/tests/view/5e2ed75cab2d69d58394fcbf
LLR: 2.94 (-2.94,2.94) {-1.50,0.50}
Total: 8519 W: 1179 L: 1062 D: 6278
Ptnml(0-2): 50, 775, 2472, 843, 74

closes #2522

Bench:  4684459

The intention of the patch is to avoid aggressive null move pruning (NMP)
in positions that have previously been found to be important (PV nodes).
If we already do not apply NMP for current PV nodes, it makes sense to apply
it less often for positions that have previously been PV nodes too.

STC:
LLR: 2.96 (-2.94,2.94) {-1.00,3.00}
Total: 14959 W: 2921 L: 2782 D: 9256
Ptnml(0-2): 254, 1679, 3493, 1762, 282
http://tests.stockfishchess.org/tests/view/5e2f6637ab2d69d58394fcfd

LTC:
LLR: 2.95 (-2.94,2.94) {0.00,2.00}
Total: 6442 W: 899 L: 753 D: 4790
Ptnml(0-2): 42, 549, 1885, 659, 61
http://tests.stockfishchess.org/tests/view/5e2f767bab2d69d58394fd04

closes #2525

Bench: 4725546

It looks like it is important to keep past PV (ttPv) nodes as close as possible to current PV nodes.
Credits to Mark Tenzer (31m059) & Stefan Geschwentner who first tried ideas on ttPv nodes.

STC:
https://tests.stockfishchess.org/tests/view/5e2ff5efab2d69d58394fd52
LLR: 2.95 (-2.94,2.94) {-1.00,3.00}
Total: 13302 W: 2647 L: 2507 D: 8148
Ptnml(0-2): 237, 1540, 2956, 1632, 260

LTC:
https://tests.stockfishchess.org/tests/view/5e2fff38ab2d69d58394fd55
LLR: 2.95 (-2.94,2.94) {0.00,2.00}
Total: 15797 W: 2137 L: 1960 D: 11700
Ptnml(0-2): 96, 1443, 4628, 1547, 130

closes #2529

bench: 5545845

We can simplify the calculation of the hashfull info by looping over exact 1,000 entries,
and then divide the result by ClusterSize. Somewhat memory accesses, somewhat more accurate.

Passed non-regression LTC
https://tests.stockfishchess.org/tests/view/5e30079dab2d69d58394fd5d
LLR: 2.94 (-2.94,2.94) {-1.50,0.50}
Total: 30125 W: 3987 L: 3926 D: 22212
Ptnml(0-2): 177, 2504, 9558, 2642, 141

closes #2523

No functional change.

Fall back to the default implementation of aligned_ttmem_alloc, which
was introduced as part of 39437f4

Fixes  #2524

No functional change.

Bench: 5153165