I don't see the problem. Why use an imperfect solution when a completely correct solution is so easy to do? Yes you can convert mate scores to a bound. And you lose information. You could convert scores where you are more than a pawn above beta into a bound of "at least beta + pawn". But why? Why not simply store the correct score?
I've never seen as many bad ideas dealing with one subject. Some say don't store mate scores. Some say don't use EXACT scores in PV nodes. Some say don't store draw scores in TT. Some say store 'em but don't use 'em except for cutoffs. Some say store bounds rather than mate scores. The list goes on. Why not do the logical thing, which is both consistent and works well.
Evert wrote:It's necessary to change the window bounds if they indicate a mate score, so bounds of (mate-in-6, mate-in-4) become (mated-in-3, mated-in-5) etc.
I'll have to check whether the way I handle that now is correct, because as I say it's not something I had originally thought of.
I use fail-soft alpha-beta, so I think a mate-score that is outside the window bounds will still be backed up to the root correctly, or at least there's a chance it will be backed up correctly even with incorrect window bounds, but I'll need to sit down with pen&paper to check my suspicion here.
I'll also make a note to double-check my code to make sure I handle this correctly. I know I don't have a problem with finding and delivering mates, but that doesn't mean there are no bugs there.
Turns out I did have a bug in the adjustment of alpha and beta when they indicate a mate score, which mainly blew up the search when a (deep) mate was found. The correct mate itself was still found, but the search took more time.
The reason this didn't lead to a complete disaster is because of the non-zero aspiration window used for the principle variation: although the alpha-beta bounds were, strictly speaking, wrong, because of the open window the mate score still fell within it.
