+M1 and -M1

Ha, ha, while ago I visited there. Tippp... has the math upside down. An evaluation consists of 2 types of scores

A. The probability of winning, drawing or losing which is for instance represented by a number between -100 en +100 where the mid-range between -2 and +2 represents a draw prediction.

B. When the win/lose outcome is certain (-100 or +100) an extra score can be added to represent the DTM - distance to mate - e.g. +M8, -M3, +M1. A move receiving a B-score always implies an A-score of +100 or -100.

Dually interpretable is the A-score 0.000 which could either represent a completely even position or a certain draw. We can't see that from the score but StockFish knows which one it is. It should tell us in some way e.g. as F0.000 - final score with black and white playing the best moves.

aleph null

YES, INFINITE. at least after one move.

Yeah, of course. COMPLETELY NONSENSE? The evaluation bar drops to literal 0 when the game is over, meaning the other side has an infinite advantage because they are about to win a king which is infinite. Did you THINK ABOUT THAT?

Actually, when checkmating with a knight and bishop, you can FORCE mate, It just isn't too easy. However, rather than saying "M35" or something, it says "49". 49 obviously isn't infinite even though it should be because mate can be forced.

king and rook mate is a rook on seventh rank and kin vs king knight Opposition thing

1,000,000,000,000=checkmate in 1 ? Never saw this . M1 replaces your '1,000,000,000,000'

Infinity is covered.  Infinity -42 is not. 

The standard specifies some special values, and their representation: positive infinity (+∞), negative infinity (−∞), a negative zero (−0) distinct from ordinary ("positive") zero, and "not a number" values (NaNs).

https://en.wikipedia.org/wiki/Floating-point_arithmetic#:~:text=The%20standard%20specifies%20some%20special,number%22%20values%20(NaNs).

------------

that aside, lot of nonsense in this thread (not @ the quoted poster).  No, the computer can't account for you running out of time or resigning before mating.  All it can do is assign a numerical value to the position based off what it knows.  It knows there exists a move or series of moves that will win in 1 move, 2, ... 20 or whatever it runs out to now  in the checks for mate.   Numerical evaluations are largely nonsense when < 1 (possibly, 0.5 and up are valid for high level players) or > 10.  < 1 means its basically equal.  > 10 means someone has a crushing advantage.  Bigger or smaller values don't change that.  Its smart enough even to know that throwing a queen away to get a mate is still infinite/MX rather than -8 points; back in the day this was not always the case.  It can't account for you not seeing it, it just moves to the next position and re-evaluates the score, which could now be anywhere from still winning to losing.  

I've also seen an evaluation of +Mx replaced by +n several times when SF is kibbitzing in Tarrasch. I agree; it's ridiculous. A bug in fact.

Now that we have tablebases you can check before you post.

This is a mate in 60.

(To be more accurate it's a mate in 60 without the 50 move rule in effect that is not frustrated by that rule when the 50 move rule ply count is 0 - as it is in the example. The currently available tablebases don't say what the mate depth is with the 50 move rule in effect.)

Thanks for the link. I took numerical analysis in 1982 (!). What Wikipedia refers to as "the almost mystical reputation that floating-point computation had developed for its hitherto seemingly non-deterministic behavior" was my big take-away from that course.

Is it using Syzygy tablebases? Those are not Depth-to-Mate, which can lead to the evaluation jumping around. That's not a bug, because it's designed for practical play where any win is good enough.

If it's using Nalimov, Lomonosov, or Gaviota, I agree it's a bug.

Without tablebases it can't reliably solve for mate at high depth because of all the pruning. The best it can say is every variation we haven't pruned shows mate in at most X. But then let it calculate and it might re-investigate one of the pruned defenses. That branch was previously discarded at +30 (or whatever high eval), but the second time around, since +30 is better (for the defender) than +Mx, it won't be pruned, and if it leads to mate-in-Y where y > x, then the eval changes to +My.

No engine programmer cares about this class of evaluation error because fixing it would have almost no impact on Elo.

Then that would be a design bug. The fact remains that if a player announces mate in n and can't back it up he finishes up with egg on his face. If programmers do it so do they. If their program hasn't fully verified a mate in n it shouldn't announce it, it should just assign a suitably high evaluation. 

Different engines have different ranges but I think SF15 tops out at just over 152. I've seen the number appear several times just before mate is announced (but I can't remember the decimal part).

Simply adding material appears to be insufficient to achieve the maximum. E.g. this (drawn) position scores only 138.55.

Rybka 2.3.2a on the other hand prefers 6.05 for the same (drawn) position.

I believe engine evaluations are meant to represent real numbers, not cardinals.

This is a serious issue with engine evaluations. Engine evaluations should include every number ever, including imaginary and irrational numbers, and the infinity types of infinity, because why not? It won't make any difference anyways. Chess.com, please fix this issue right now.

Engine evaluations won't ever need to include more than a finite cardinality of numbers because chess is finite.

Not aware of any application of imaginary numbers in chess. Not aware of any way computers can ever represent anything more than a finite number of things anyway.

Main problem with engine evaluations is they don't always work.

But in this position...

... Stockfish says it's 0.0 (draw) while it should be M130 (it's a mate in 130 moves)