In the following technically drawn ending, it's no surprise Stockfish recognizes the situation without need of a search or EGT. The static eval gives white a symbolic edge of 0.08. Unfortunately, the pretty output doesn't show what it's using to offset the material difference, even if that's just a line for Known Draw. Not sure there's a question here, just an observation.
zenpawn wrote:In the following technically drawn ending, it's no surprise Stockfish recognizes the situation without need of a search or EGT. The static eval gives white a symbolic edge of 0.08. Unfortunately, the pretty output doesn't show what it's using to offset the material difference, even if that's just a line for Known Draw. Not sure there's a question here, just an observation.
Stockfish detects this wrong-colored bishop endgame and therefore scales the evaluation down close to zero. But the table above does not contain the scaling factor that may have been found. The final score is not exactly zero because (as I understand it) the scaling factor is applied to the endgame component of the score while the middlegame component remains unscaled. Since the position has almost no pieces the endgame term is dominating but the middlegame term still has a very small influence.
Yeah, guess I was just hoping for it to have a line in the table. Still a nice display nonetheless.
On the topic of static evals, is there a way/program to run through a PGN to get the evaluations of the positions along the way without the engine doing any search? I came close by setting Fritz 15 to perform its blunder check with depth 1 and margin (to consider a move a blunder) of 0.
zenpawn wrote:In the following technically drawn ending, it's no surprise Stockfish recognizes the situation without need of a search or EGT. The static eval gives white a symbolic edge of 0.08. Unfortunately, the pretty output doesn't show what it's using to offset the material difference, even if that's just a line for Known Draw. Not sure there's a question here, just an observation.
Stockfish detects this wrong-colored bishop endgame and therefore scales the evaluation down close to zero. But the table above does not contain the scaling factor that may have been found. The final score is not exactly zero because (as I understand it) the scaling factor is applied to the endgame component of the score while the middlegame component remains unscaled. Since the position has almost no pieces the endgame term is dominating but the middlegame term still has a very small influence.
No, it's the tempo bonus added for the side to move.
Sven Schüle wrote:The final score is not exactly zero because (as I understand it) the scaling factor is applied to the endgame component of the score while the middlegame component remains unscaled. Since the position has almost no pieces the endgame term is dominating but the middlegame term still has a very small influence.
No, it's the tempo bonus added for the side to move.
Sven Schüle wrote:The final score is not exactly zero because (as I understand it) the scaling factor is applied to the endgame component of the score while the middlegame component remains unscaled. Since the position has almost no pieces the endgame term is dominating but the middlegame term still has a very small influence.
No, it's the tempo bonus added for the side to move.
Sven Schüle wrote:The final score is not exactly zero because (as I understand it) the scaling factor is applied to the endgame component of the score while the middlegame component remains unscaled. Since the position has almost no pieces the endgame term is dominating but the middlegame term still has a very small influence.
No, it's the tempo bonus added for the side to move.
Ok, I see you are right, I forgot that the internal SF scoring is not in centipawns. (Note: it is not in uci.cpp but in evaluate.cpp where the table above is printed within do_trace() - called when the user types the "eval" command - using the function to_cp() for the total score, but the principle is the same.)
So the scaling of the score without the tempo bonus seems to result in an internal score of at most 3, since otherwise rounding of (20 + 4) / 258 = 0.093.... would have printed 0.09 (the code for printing the eval table uses setprecision(2) which does not round as far as I know). I did not check that since it is not directly related to the original topic of this thread which is now solved ...
Nevertheless, I'd still propose to extend the table output by adding both the scaling factor and the tempo bonus, for completeness.
Sven Schüle wrote:So the scaling of the score without the tempo bonus seems to result in an internal score of at most 3, since otherwise rounding of (20 + 4) / 258 = 0.093.... would have printed 0.09 (the code for printing the eval table uses setprecision(2) which does not round as far as I know). I did not check that since it is not directly related to the original topic of this thread which is now solved ...
To close this last topic as well: in the given position the game_phase is 0 since the value of the non-pawn material (only one white bishop) is less than the constant "EndgameLimit". Therefore the middlegame part of the score actually has zero influence in this case, as in all endgames with few non-pawn pieces. E.g. QR or Q vs. R is below that limit while Q vs. BN is above it.
KQkr is one of the endgames that have their own special evaluation functions in endgame.cpp. As you point out, these special endgame scores are not covered by the "eval" command output so far.