tt and mate scoring bug

[ericlangedijk]

True. But my max searchdepth is 128 so I am thinking something is wrong with the score_from_tt and score_to_tt when using a tt_score as static eval in the search.

[ericlangedijk]

Currently I use the safe version which never reports crazy mates.
In both cases the entry score is already adjusted for the current ply.

Code: Select all

    pub fn is_score_usable_as_eval_safe(self: *const Entry) bool {
        return self.flags.bound == .exact and scoring.is_normalscore(self.score);
    }

    pub fn is_score_usable_as_eval_unsafe(self: *const Entry, static_eval: i32) bool {
        if (scoring.is_nullscore(self.score)) {
            return false;
        }
        return switch (self.flags.bound) {
            .none  => false,
            .alpha => self.score <= static_eval,
            .beta  => self.score >= static_eval,
            .exact => true,
        };
    }

[hgm]

True. But my max searchdepth is 128 so I am thinking something is wrong with the score_from_tt and score_to_tt when using a tt_score as static eval in the search.

Not necessarily. With a TT you can easily find mates that are much deeper than the maximum search depth, through grafting. If you never see any mates beyond the search depth this would be suspect, and point to a bug in the TT implementation.

Your 'safe' version basically disables hash pruning, as approximally 0% of all entries has an exact score, typically. Even without restriction on the bound type excluding hits on mate scores should of course be sufficient to suppress any grafting on checkmates. But at least you would still have grafting on heuristic scores.

[ericlangedijk]

That is not entirely true.
This is just about the case where I overwrite the static evaluation with a tt_entry score to use that as a more precise "static_eval". At least... That is what it is meant to do.

[hgm]

Ah, OK.

But this is likely to be an error in itself. The static evaluation is not really needed as a search score in a node that is not a leaf. So I suppose that you use it for things like futility pruning, to prune moves for which staticEval + victimValue + MARGIN < alpha.

The search score is NOT a better approximation of the static eval. The latter judges the material balance in the current position, but the search score retrieved from the TT includes future gains. E.g. suppose that the static eval is 450cP below alpha, and MARGIN = 100cP. Then capturing a hanging Knight (at remainingDepth = 1) would be futile, because it brings you only to 150cP below alpha, which is more than the MARGIN. But the search score in the TT would be 300cP above staticEval, (and thus 150cP below alpha), as it incorporates the gain of the hanging Knight. So TTscore + victimValue + MARGIN would be 250cP above alpha, because you double-counted the gain of the Knight. So using TTscore instead of staticEval would fail to prune the futile capture of the Knight. And also of other minors.

[Aleks Peshkov]

But the search score in the TT would be 300cP above staticEval, (and thus 150cP below alpha), as it incorporates the gain of the hanging Knight. So TTscore + victimValue + MARGIN would be 250cP above alpha, because you double-counted the gain of the Knight. So using TTscore instead of staticEval would fail to prune the futile capture of the Knight. And also of other minors.

"as it incorporates the gain of the hanging Knight" what does gain mean? How TT score of previous search would include gain of capturing Knight if current deeper search should skip it as futile and return fail low?

[hgm]

"as it incorporates the gain of the hanging Knight" what does gain mean? How TT score of previous search would include gain of capturing Knight if current deeper search should skip it as futile and return fail low?

The TT score can be from a deeper search, where you would not do futility pruning. Or from a search with different alpha, so the capture of the Knight would be in window, rather than failing low.

Even if the previous visit searched the same depth with the same window, the capture of the Knight should have received an upper-bound score of staticEval + KnightValue + MARGIN (< alpha), which (assuming it was the best move) would then be the score bound that got stored in the TT, so staticEval + 400cP (= alpha - 50cP) in the example.

[ericlangedijk]

I uploaded a game where chessnix is mating another engine in a KBN_K position.
https://github.com/ericlangedijk/misc/b ... /kbn_k.txt
At line 248 we see the first anomalie: info depth 36 seldepth 73 score cp 29679
which means: 30000 - 29679 = mate in 231 ply.
I only output "mate" when within 128 range. Later on you can see that.
When we see these insane matescores, there is always a mate, so I kept (for my experiment) that "set eval = tt_score logic" when available.
And indeed I use that eval for pruning: rfp, razoring, nmp, fp.
By the way: quiescence search also returns mate scores (when in check), so that could be a thing as well.
The engine plays at a strength of around 3320, so not too bad at all. But this - for me - uncontrollable thing keeps nagging me.

(Many other engines do exactly the same eval overwrite, but maybe I am missing something).

[hgm]

Sounds completely normal to me in KBN_K. This end-game has an enormous opportunity for grafting.

How exactly you do eval-based prunings should not have much effect on the grafting to occur, though; this is purely a matter of hash pruning through overdeep hits. Although perhaps if you wreck the search enough by abundant other prunings you might be able to make it fail seeing the distant checkmates.

As I pointed out setting eval = tt_score is a bug. Scores are fundamentally different quantities than static evals, and the normal implementations of the eval-based prunings rely on future gains not being counted.

[ericlangedijk]

Ok...
Regarding "that is a bug"

Is this one?
https://github.com/aronpetko/integral/b ... ch.cc#L667
One of the examples I know that do the same...