add retrocheck.py - #97
Conversation
|
Hi Robert, to have a better and more valuable measurment of the "retrograde analysis" capability I suggest to count not only the occurences when the mate is still found on the starting (=puzzle) position, but also count each time SF finds (regains) the mate again along the mating line while going backwards. |
|
Thanks for your feedback. I can think about adding this as an option. Note that for now the PV along which the hash is filled need not be a complete mating line at all. In theory it can be any sequence of moves. |
|
Yes, but my point is, that once you get lost about the mating line while stepping back, it's very improbable that when stepping back you suddenly again regain the mating line. |
|
The idea of the script is that you somehow pre-fill the hash table with shallow searches in the subtree, before you do the actual analysis of the puzzle. In particular, usually you would use a higher nodes/depth limit at root than along the given PV. What you have in mind is implemented in the script But I wanted to keep the |
|
@robertnurnberg There must be something wrong with your current version of retrocheck.py It reports failings on simpliest problems: In contrast the retrocheck.py script reports this problem as fail: PS.: After adding the script seems work correcty: |
|
Thanks! Should be fixed with 2221195. |
|
OK, thanks. |
The new script allows to systematically and automatically evaluate the "retrograde analysis" capabilities of an engine. It works similarly to the
matecheck.pyscript from https://github.com/vondele/matetrack, but before the final search for each position it fills the engine's hash table by performing searches long the given mating line, going backwards from the checkmate to the puzzle position.A clear improvement can be seen comparing "hash filling" with 1 node searches compared to 1000 node searches.
Setting any of the fill limits to zero is equivalent to running
matecheck.py:Edit: Numbers fixed after the application of 2221195.