stevenaaus wrote:How come engines sometime/often dont give the whole mating PV ?
The full list of reasons is complex and varies from enging to engine. But a typical reason that probably affects most engines is TT pruning in PV nodes. Not doing it loses (a little bit of) elo, but doing it means printing truncated PVs sometimes.
Theory and practice sometimes clash. And when that happens, theory loses. Every single time.
Functional programming combines the flexibility and power of abstract mathematics with the intuitive clarity of abstract mathematics. https://github.com/mAarnos
The funny thing is that with engines that extract the PV out of the hash table after the search, you can have the opposite effect. Joker often gave a non-mate-score, and then a PV that ended in checkmate!
Ok, thanks. I'm fixing up Scid vs. PC's depth-based engine annotation, and just noticed this Score to Mate issue.
Scid converts the PV to San and looks for a trailing "#" to determine whether to use "[M3]" or "[score]"
If i just go by the info's "score mate 3" instead, i run into the problem that people see "[M3]" and click Add Variation, but the new line may not result in mate
stevenaaus wrote:How come engines sometime/often dont give the whole mating PV ?
The full list of reasons is complex and varies from enging to engine. But a typical reason that probably affects most engines is TT pruning in PV nodes. Not doing it loses (a little bit of) elo, but doing it means printing truncated PVs sometimes.
There is a well-known solution to solve this without giving up exact TT matches along the PV. See Crafty as one example.
