Simplify retrograde analysis capability condition

[pb00068]

by simplifying according condition in search.cpc

Passed STC and LTC non-reg bounds:
https://tests.stockfishchess.org/tests/view/695ce092912b7ff140de60c6
LLR: 3.17 (-2.94,2.94) <-1.75,0.25>
Total: 121728 W: 31439 L: 31298 D: 58991
Ptnml(0-2): 305, 13281, 33554, 13416, 308

https://tests.stockfishchess.org/tests/view/695dfc9702d0182a589fe8e8
LLR: 2.94 (-2.94,2.94) <-1.75,0.25>
Total: 56220 W: 14472 L: 14299 D: 27449
Ptnml(0-2): 30, 5326, 17219, 5511, 24

Superseeds PR #6521

N.B.:
Since current implementation relies completely on TT and relevant pv entries might get overriden by other positions
it is not very robust and depends on hash-size, threads, minimum search depth, and other parameters used.
A robust implementation might be possible but requires additional code.

bench: 2477446

[github-actions]

clang-format 20 needs to be run on this PR.
If you do not have clang-format installed, the maintainer will run it when merging.
For the exact version please see https://packages.ubuntu.com/plucky/clang-format-20.

(execution 21132914050 / attempt 1)

[robertnurnberg]

Since this removes a condition and passes simplification bounds, this PR is fine I think.

The title claims an improvement in retrograde analysis. Is there an objective and reproducible way to quantify this? Similarly to matetrack?

This would help developers in future to, for example, evaluate the merits of something like #6521 etc.

(I will also think about this, but maybe you already have something in mind or even working.)

[pb00068]

Hi Robert,

as said in the main comment the implemtation is not very robust and highly depends on hash-size, threads, minimum search depth, and other parameters used.

Anyway a possible objective and reproducible way to quantify this for the current implementation on given test positions might be following:

1. go mate
2. after mate is found search the same position 25 plies deeper to stabilize & enforce the mating PV.
   For instance if mate on step 1 was found at rootdepth 24 then now submit
   go depth 50
3. now step back on half-move (without clearing hash-table)
4. go depth 51

if search now terminates without regaining the mate-score then the retrograde analysis ability has failed.

example PGN (start from the final position, then go back move by move):
[FEN "6br/1KNp1n1r/2p2p2/P1ppRP2/1kP3pP/3PBB2/PN1P4/8 w - - 0 1"]

1. Bxc5+ Kxc5 2. d4+ Kxd4 3. Nb5+ Kxe5 4. Nd3+ Kxf5 5. Nd4+ Kg6 6. Nf4+ Kg7 7. Nf5+ Kf8 8. Ng6+ Ke8 9. Kc8

[robertnurnberg]

Hm, ideally we would get away from single position test cases and come up with a more systematic approach.

So using the new script from robertnurnberg/matetools#97 I actually find that master is on average better for retrograde analysis than the PR patch, at least for the matetrack set of positions: master and patch are nearly the same.

Master:

> python retrocheck.py
Loaded 6554 FENs, with max(|bm|) = 126.

retrocheck started for ../stockfish/src/master on matetrackpv.epd with --nodes 1000000 --nodesFill 100000 ...
100%|#########################################| 97/97 [1:03:31<00:00, 39.29s/it] 

Using ../stockfish/src/master on matetrackpv.epd with --nodes 1000000 --nodesFill 100000
Engine ID:     Stockfish dev-20260106-c27c1747
Total FENs:    6554
Found mates:   5294
Best mates:    5063

Patch:

> python retrocheck.py
Loaded 6554 FENs, with max(|bm|) = 126.

retrocheck started for ../stockfish/src/patch on matetrackpv.epd with --nodes 1000000 --nodesFill 100000 ...
100%|##########| 97/97 [1:06:01<00:00, 40.84s/it]


Using ../stockfish/src/patch on matetrackpv.epd with --nodes 1000000 --nodesFill 100000
Engine ID:     Stockfish dev-20260108-60e9af62
Total FENs:    6554
Found mates:   5298
Best mates:    5056

For comparison, master on matetrack has these stats: c27c1747e3956bc3048ceb1ced00802bda0ec86d 6554 3244 2334, see https://github.com/vondele/matetrack/blob/9a767c464ced326121508baa2d5f7c6f7429a3c2/matetrack1000000.csv#L4217.

Edit: The numbers were corrected after a bug was found in the retrocheck script by @pb00068.

[pb00068]

Hi @robertnurnberg ,

thank you very much for your work and analysis!

I have a question/doubt on how retrocheck.py works.
Since it was started on matetrackpv.epd with 6554 FEN's and as it should start from the final mating position back some moves (until the starting position?) trying o find the mate (again) on each halfmove I was excecting numbers with an completely different magnitude.
(If average matedistance from starting position on matetrackpv.epd is, lets say, 25, then the number of mate-searches should be approximately 6554 x 25).

N.B.: I have now https://tests.stockfishchess.org/tests/view/696138808709a8d27c038387 branch https://github.com/pb00068/Stockfish/tree/retro which should be very strong & robust on
retrograde mate finding. Pre-condition or better said: what I excpect from an retrograde analysis tool, is that from a loosing position (-Mxx) it steps back no more than one halfmove before searching again.

[robertnurnberg]

Hm, I fear that counting all the found mates along the mating line will somehow dilute the statistics, and make it harder to differentiate good from bad patches. (think of all the short mates that will be found by almost all versions of sf).

I like that the current tool shows the improvement of hash filling compared to the plain matetrack runs. And somehow we have decided for sf development to look at those 6554 puzzles, so we can do the same for retro analysis.

If there are other mates/puzzles one is interested in (such as along all the nodes along a mating line), one can create a separate .epd file and run the script on that.

[pb00068]

@maintainers:
In my opinion the current version of retrocheck.py is not well suited for measuring the efficiency of this patch.
Please see comments on robertnurnberg/matetools#97 for more details.

[pb00068]

@robertnurnberg There must be something wrong with your current version of retrocheck.py

It reports failings on simpliest problems:
I verified problem with FEN 8/B3p3/2K1p1p1/4Pkpb/5pn1/2P2N1B/4PP2/6R1 w - - bm M3; PV: c6d7 f5e4 d7e6 g4h2 f3g5;
Both engines master and patch are able to find the M3 well below 1.000.000 nodes directly from the starting pos.
If I simulate the whole procedure with Chess Arena it easily finds the mate:

1. Open Arena GUI and analyze FEN 8/B3p3/2K1p1p1/4Pkpb/5pn1/2P2N1B/4PP2/6R1 w - -
   After mating PV is found append the variation to the end (can be choosen after right mouse click on engine window)
2. Go to one move before the mating position
3. Under Levels -> Adjust -> choose Nodes set to 100.000 (=nodes fill rate)
4. Restart the engine and press CTRL-Z, this will submit to the engine
   go nodes 100000
5. Move one move back and press CTRL-Z again
6. Repeat it until the starting pos is reached
7. Under Levels -> Adjust -> choose Nodes set to 1.000.000 (=nodes rate)
8. press CTRL-Z again and you will see the mate in 3 will be found.

In turn the retrocheck.py script reports this problem as fail:

py retrocheck.py --engine ..\sf\stockfish.exe --hash 128 --nodes 1000000 --nodesFill 100000
Loaded 1 FENs, with max(|bm|) = 3.

retrocheck started for ..\sf\stockfish.exe on matetrackpv.epd with --nodes 1000000 --nodesFill 100000 --hash 128 ...

Did not Find mate for FEN "8/B3p3/2K1p1p1/4Pkpb/5pn1/2P2N1B/4PP2/6R1 w - -" with bm #3.

Using ..\sf\stockfish.exe on matetrackpv.epd with --nodes 1000000 --nodesFill 100000 --hash 128
Engine ID:     Stockfish dev-20260113-nogit
Total FENs:    1
Found mates:   0
Best mates:    0

PS.: After adding

with engine.analysis(board, self.limitFill, game=board) as analysist:
                        for info in analysist:
                            dummy= ""

the script seems work correcty:

Using ..\sf\stockfish.exe on matetrackpv.epd with --nodes 1000000 --nodesFill 100000 --hash 128
Engine ID:     Stockfish dev-20260113-nogit
Total FENs:    1
Found mates:   1
Best mates:    1

[robertnurnberg]

Thanks. This has now been fixed. I will repeat the checks that I reported above and correct the results.
(If I understand the bug correctly, then the old backward hash filling may have been nearly random and mostly incomplete.)

[pb00068]

After further tests I came to the conclusion that this change does not influence the retrograde analysis capability in a measureable way. Therefore I changed the subject of the PR now and handle/describe it as a pure simplification.