🐛 Prevent negative checkmate scores from being lower than EvaluationConstants.MinEval
#1063
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Distance
MinEval
from-CheckMateBaseEvaluation
enough so that there's no possible interference between them at TT level.Now I reaaaally want to change
EvaluationConstants.CheckmateDepthFactor
to 1, but now it's not the time.Logs seen when saving an item to a TT.
Logs seen when retrieving that item from TT, ending up with a score <
EvaluationConstants.MinEval
(-30001).This which eventually causes some NegaMax calls to use that value and return it, which ends up in the situation where other shallower NegaMax instances have a bestScore that never bets beaten in the fail-soft version of alphabeta, eventually causing an empty PV and a crash due to
a8a8
moveLogs produced using b8f23b9, from bugfix/no-pruning-negative-checkmate-score-debugging (#1062)
Code-flow explanation, dumbed for future me:
If
bestScore
isEvaluationContants.MinEval
, the double invocations toTranspositionTableExtensions.RecalculateMateScores
on saving an entry and on retrieving it lead the resulting score to be lower thanEvaluationContants.MinEval
.alpha
andbeta
outside of theif (score > bestScore
conditional.This implies that if the returned
score
is ever lower thanbestScore
, which gets initialized toEvaluationContants.MinEval
, there's never a fail low node that beats alpha, that is there's no move beating the 'no move', so there's no PV populated.bestScore
is lower thanEvaluationConstants.MinEval
butalpha
is restricted to [minEval, ...), so alpha always beatsbestScore
. Given that, we end up in the situation described in https://github.com/🐛 Avoid aspiration windows after a checkmate has been detected in the search #1057 (but not fixed): an infinite Aspiration windows loop where stuff overflows due to the window variable growing indefinitely, variables start to overflow and a cancellation with still no PV ends up happeningAnother 60k games vs the GOAT without illegal moves
8+0.08, no win adjudication,