Glitchy eval about stockfish

[peregrineshahin]

I just realized that the line I mentioned has nothing to do with 96.05 value since it's VALUE_MATE_IN_MAX_PLY - 1; (96.814) and not VALUE_TB_WIN_IN_MAX_PLY - 1 (96.05)

Stockfish/src/search.cpp

Line 1667 in 42d2842

return VALUE_MATE_IN_MAX_PLY - 1; // do not return a potentially false mate score

return VALUE_MATE_IN_MAX_PLY - 1; // do not return a potentially false mate score

and the culprit line is the fix I introduced for the null move issue returning values higher than TB by clamping it to lower than TB range this explains why it happens on pretty low depth as vondele reported.
https://github.com/official-stockfish/Stockfish/blob/42d28424bc64246e141e9f06a2a518592272f8fd/src/search.cpp#L803C2-L807C34
I'm thinking about a better solution now.

[peregrineshahin]

OK. I found something else also regarding the 96.05 thing
In qSearch we don't Probe TB's this means that the maximum Best value for new nodes (that are not in TT) is the Static Evaluation and Since a qSearch PV search can update PV and thus root score. Current guard against pruning in such case is only
// Step 6. Pruning.
if (bestValue > VALUE_TB_LOSS_IN_MAX_PLY)

which means that following moves of the moves loop can be pruned (loop breaks and pv updated) if we only had at least one move that gives us maximum static evaluation (96.05).

[peregrineshahin]

Well this assuming that the staticEval returns the max value on a drawn position which we can't do anything about
so 96.05 is indeed safe here
what is not safe is
what we do in null move search
downgrading a mate/a TB score to that maximum static evaluation ignoring zugzwangs