Fix for incorrect VALUE_MATE_IN_MAX_PLY usage.
authorJoost VandeVondele <Joost.VandeVondele@gmail.com>
Tue, 11 Feb 2020 19:42:32 +0000 (20:42 +0100)
committerJoost VandeVondele <Joost.VandeVondele@gmail.com>
Sat, 15 Feb 2020 14:10:07 +0000 (15:10 +0100)
commitbe5a2f015e45886e32867b4559ef51dd694a3cec
treed36a0799b6acbf5d50684c1a8765436509d835e6
parent4e8986483a83296e37433da7b07b64de53613f6f
Fix for incorrect VALUE_MATE_IN_MAX_PLY usage.

Fixes #2533, fixes #2543, fixes #2423.

the code that prevents false mate announcements depending on the TT
state (GHI), incorrectly used VALUE_MATE_IN_MAX_PLY. The latter
constant, however, also includes, counterintuitively, the TB win range.

This patch fixes that, by restoring the behavior for TB win scores,
while retaining the false mate correctness, and improving the mate
finding ability. In particular

no alse mates are announced with the poisened hash testcase
```
position fen 8/8/8/3k4/8/8/6K1/7R w - - 0 1
go depth 40
position fen 8/8/8/3k4/8/8/6K1/7R w - - 76 1
go depth 20
ucinewgame
```

mates are found with the testcases reported in #2543
```
position fen 4k3/3pp3/8/8/8/8/2PPP3/4K3 w - - 0 1
setoption name Hash value 1024
go depth 55
ucinewgame
```
and
```
position fen 4k3/4p3/8/8/8/8/3PP3/4K3 w - - 0 1
setoption name Hash value 1024
go depth 45
ucinewgame
```

furthermore, on the mate finding benchmark (ChestUCI_23102018.epd),
performance improves over master, roughly reaching performance with the
false mate protection reverted
```
Analyzing 6566 mate positions for best and found mates:

                 ----------------best ---------------found
           nodes master revert  fixed master revert  fixed
        16000000   4233   4236   4235   5200   5201   5199
        32000000   4583   4585   4585   5417   5424   5418
        64000000   4852   4853   4855   5575   5584   5579
       128000000   5071   5068   5066   5710   5720   5716
       256000000   5280   5282   5279   5819   5827   5826
       512000000   5471   5468   5468   5919   5935   5932
```

On a testcase with TB enabled, progress is made consistently, contrary
to master
```
setoption name SyzygyPath value ../../../syzygy/3-4-5/
setoption name Hash value 2048
position fen 1R6/3k4/8/K2p4/4n3/2P5/8/8 w - - 0 1
go depth 58
ucinewgame
```

The PR (prior to a rewrite for clarity)

passed STC:
LLR: 2.94 (-2.94,2.94) {-1.50,0.50}
Total: 65405 W: 12454 L: 12384 D: 40567
Ptnml(0-2): 920, 7256, 16285, 7286, 944
http://tests.stockfishchess.org/tests/view/5e441a3be70d848499f63d15

passed LTC:
LLR: 2.94 (-2.94,2.94) {-1.50,0.50}
Total: 27096 W: 3477 L: 3413 D: 20206
Ptnml(0-2): 128, 2215, 8776, 2292, 122
http://tests.stockfishchess.org/tests/view/5e44e277e70d848499f63d63

The incorrectly named VALUE_MATE_IN_MAX_PLY and VALUE_MATED_IN_MAX_PLY
were renamed into VALUE_TB_WIN_IN_MAX_PLY and VALUE_TB_LOSS_IN_MAX_PLY,
and correclty defined VALUE_MATE_IN_MAX_PLY and VALUE_MATED_IN_MAX_PLY
were introduced.

One further (corner case) mistake using these constants was fixed (go
mate X), which could lead to a premature return if X > MAX_PLY / 2,
but TB were present.

Thanks to @svivanov72 for one of the reports and help fixing the issue.

closes https://github.com/official-stockfish/Stockfish/pull/2552

Bench: 4932981
src/endgame.cpp
src/search.cpp
src/types.h