bob wrote:Maybe you are correct. I might not have quite understood what you meant initially, but in thinking about it, the only problem I see is that you can have mate bounds near the root, and when you do alpha/beta comparisons near the tip the bounds are not compatible with the altered score.
Note that I do not adjust the score in the tree search, but only when I store or retrieve a score from the table. Backing up changing mate scores from ply to ply would still seem to be problematic to me from that perspective...
An example. At the root your bounds are (say) (Mate-in-6, mate in 4). The mate score (mate in 0) doesn't compare very well to those bounds... If you are at depth 10 and discover you are mated, back at ply 9 you have a score of mate in 5, which is within those bounds, normally. But in your case, you would have a score of mate, which is outside the window. How do you handle that???
That's a good point, and one that I handn't originally thought of. 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.
All in all, I won't disagree that this is not quite as simple as I made it out to be. Perhaps simply returning "mate-in-ply" when the mate is discovered and adjusting the score in the hash table is in fact the more elegant solution here.