Q: How to Detect a Draw?

[Steve Maughan]

When Stockfish (or any other strong engine) plays it often gives a "0.00" draw score — sometimes in the middlegame. It's unlikely an evaluation function would come out exactly at 0.00. How does Stockfish do this?

In the early days of NNUE we had win-loss-draw probabilities. Is the evaluation assumed to be 0.00 if the draw probability is above a certain threshold?

— Steve

[towforce]

I'm going to take a guess for fun: is it that these middle game positions are actually far enough advanced that the search is terminating in all branches of the game tree in positions that are known to be drawn?

[hgm]

Well, for one the chances are not that small. Many of the games are not yet decided at that point, and 1% of the scores between -0.50 and 0.50 are exactly 0.00.

It would of course be interesting to have the heuristic evaluation never return 0.00 (e.g. subtact 0.01 if it would be <= 0). Then you would know for sure that a 0.00 score in the root could only be caused by all relevant branches leading to a draw condition (3-fold-rep, 50-move, stalemate, insufficient material). It would mean that that player can force such a reglementary draw, and that it would judge itself to be at a disadvantage in any line that doesn't do that.

You don't have to be advanced very far to get that; you might be able to force a perpetual check.

[towforce]

Many of the games are not yet decided at that point, and 1% of the scores between -0.50 and 0.50 are exactly 0.00.

Why are evals only calculated to 2 digits?

I'm not saying you'd get better move selection with more - but why go to the computational effort of truncating?

In order to truncate to 2 digits, one must use a "decimal" or "money" number format. Working with these formats is, computationally, MUCH more expensive (hence slower) that working with the float format - but if you don't use these formats, decimal numbers might not sum correctly - hence those of us who write business applications that sum numbers representing money don't think twice about using money formats - it's absolutely the right thing to do. However, in a chess engine that's generating game trees, CPU time is precious!

[AndrewGrant]

Why are evals only calculated to 2 digits?

I'm not saying you'd get better move selection with more - but why go to the computational effort of truncating?

Engines don't use floats for the evals. HGM is just expressing some conversation of engine eval into "human eval".

[towforce]

Why are evals only calculated to 2 digits?

I'm not saying you'd get better move selection with more - but why go to the computational effort of truncating?

Engines don't use floats for the evals. HGM is just expressing some conversation of engine eval into "human eval".

Thank you Andrew - that's a good and clear answer.

[Ras]

Why are evals only calculted to 2 digits?

Because both UCI and CECP transmit the score in centipawns. Even if an engine calculates e.g. in millipawns internally, or something entirely different such as winnning probability, it has to convert that to centipawns externally.

[hgm]

In order to truncate to 2 digits, one must use a "decimal" or "money" number format. Working with these formats is, computationally, MUCH more expensive (hence slower) that working with the float format - but if you don't use these formats, decimal numbers might not sum correctly - hence those of us who write business applications that sum numbers representing money don't think twice about using money formats - it's absolutely the right thing to do. However, in a chess engine that's generating game trees, CPU time is precious!

'Money format' is a concept of output formatting. Apart from that does not exist in most high-level computer languages used for programming engines, and is not supported by hardware. The only formats there are integer and floating point, and in the old days most CPUs did not support the latter (so the high-level languages emulated it with integer arithmetic). Floating-point formats tend to be large; the lowest precision x68 hardware supports is 4 bytes. So if you don't need that precision or wide value range, you can potentially save a factor 4 on table sizes. This can significantly reduce cache pressure on large tables, such as used to define neural nets.

So most engines only use integer arithmetic, often stored in byte-size variables. For things like piece-square tables that is good enough. The number 1 then represents the 'evaluation quantum'. It can be a centi-pawn, but doesn't need to be. E.g. in Joker I use 1/256 Pawn as quantum, and all evaluation weights are expressed as an integer multiple of this. That means you can use the fastest possible arithmetic on it, even on CPUs that do not support floating point at all. For relaying the score to the GUI the internal value is converted (and rounded) to an integer number of centi-pawn, as the communication protocol requires.

[smatovic]

[...]
Floating-point formats tend to be large; the lowest precision x68 hardware supports is 4 bytes. So if you don't need that precision or wide value range, you can potentially save a factor 4 on table sizes. This can significantly reduce cache pressure on large tables, such as used to define neural nets.
[...]

Wish to add that the x87 FPU suported 32-bit, 64-bit and also 80-bit (think Fortran) floating-point format, with x86-64 SSE2 80-bit support (and x87 co-processor) was dropped, and meanwhile newer SIMD ISAs support also FP16 and BF16 format (Google's 16-bit floating-point format). As mentioned, this is of interest for neural networks, new GPUs increased throughput by FP8, FP6 and FP4 for LLMs, some papers mention that FP mixed precision is of interest for training NNs.

https://en.wikipedia.org/wiki/X87
https://en.wikipedia.org/wiki/SSE2#Diff ... U_and_SSE2
https://en.wikipedia.org/wiki/AVX-512#FP16

--
Srdja

[syzygy]

Well, for one the chances are not that small. Many of the games are not yet decided at that point, and 1% of the scores between -0.50 and 0.50 are exactly 0.00.

It would of course be interesting to have the heuristic evaluation never return 0.00 (e.g. subtact 0.01 if it would be <= 0). Then you would know for sure that a 0.00 score in the root could only be caused by all relevant branches leading to a draw condition (3-fold-rep, 50-move, stalemate, insufficient material). It would mean that that player can force such a reglementary draw, and that it would judge itself to be at a disadvantage in any line that doesn't do that.

It would not mean that a draw can be forced by either side. One or both players could potentially reach a winning position that is statically evaluated as negative for that player.