-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mate finding issue #5504
Comments
I think this kind of unactionable issues are not the best, The expected behavior of |
You may well be right. I just wanted to bring it to the attention of people who understand mate finding such as your self. I'm happy to close it if others agree. |
Things can always be improved, but let's summarize what we have as data and what we have done so far. First, we trace now since quite a while the mate finding performance of SF. In a dedicated repo, we have the tools to see how well SF finds mates: In the development version, each mate announcement is now, as far as we know, correct. This hasn't always been the case in SF, one can consider that a fixed bug. As a new feature, each mate announcement (in completed iterations) now comes with a PV that ends in mate. So no cutoffs or so in mating lines. I think that's pretty unique among top engines. I also think it is valuable, what's the value of a mate score if the user doesn't now it is correct, or the way to mate if unknown. Similar guarantees are now in place for TB scores as well. Decisive TB scores guarantee a TB win, the plies to entering the TB position (from the score) are correct. Given sufficient time, TB continuation lines to mate will be constructed. Yet, of course, having a better matetrack scores is definitely something to keep an eye on, but shouldn't get in the way of Elo gains. Ideally we can learn what are patches that improve matefinding, and turn them into patches that both improve mate finding and Elo. What I'm not 100% certain of yet, is how search in TB regime is influenced by the presence of TB. This is nothing new, but I suspect that scoring TB wins might sometimes make mate finding less efficient (this could be what is happening in the game you posted). Needs some careful look at how TB scoring in search actually happens once we have entered TB already. |
IIRC the TB scores are treated as bounds (e.g. a TBWin is a lower bound) instead of as exact scores. They may give cut-offs but they don't forcibly stop the search. |
Well in the case we see in the game, the game plies that didn't report mate reported +200 so we see TB in root with a score of +200 for couple of plies this means that the search wasn't influnced by TB hits since we stopped looking for them, when the root is in TB we only sort the root-moves in such case and the score is masked when printing the PV and not in search, so I can say that the search was at least most likely similar to the search without TB with good confidence theoritcally. Lines 691 to 698 in a8401e8
|
Quite interesting on the response there |
Just wondering if this changed in a recent version of SF, or (likely) if I misunderstood the issue, because SF seems to find mate right away if I put that position here: https://lichess.org/analysis/8/8/R3bk2/4n3/1K6/8/8/7R_w_-_-_0_1 |
I don't think SF on lichess has access to endgame tablebases, whereas the issue concerns tablebase scores potentially reducing mate-finding capabilities. |
Describe the issue
In this CCC game https://www.chess.com/computer-chess-championship#event=ccc23-blitz-finals&game=385 Stockfish doesn't find mate till move 168 whereas Torch finds it a full 15 ply earlier on move 160.
Expected behavior
Consistent mate finding.
Steps to reproduce
Play through https://www.chess.com/computer-chess-championship#event=ccc23-blitz-finals&game=385
Anything else?
No response
Operating system
All
Stockfish version
dev-20240706-4d6e1225
The text was updated successfully, but these errors were encountered: