In many positions, different moves are functionally the same, and an engine should return the same evaluation. For example, in a KR vs. KR endgame, (almost) every move that does not lose the rook should give exactly the same evaluation: 0.00. How does an engine choose between them then?

  • 1
    Not an answer, as I don't think it was ever implemented. I've seen a discussion (comp.rec.computers?) several years ago about using non-positional factors and gamesmanship, in particular the 'shape' of the search tree, to identify moves leading to situations human players would be less likely to disentangle in the time still available. That is, when your opponent has time problem, go for complexity. But I don't know that anything like that has been implemented, as it would requiring adding additional 'difficulty' tables to endgame databases (which was the focus of that discussion). – user18412 Oct 3 '19 at 5:18
  • 2
    That's probably why computers suck at endgames! – David Oct 3 '19 at 9:00

The answer is simple for traditional engines like Stockfish and the like: if multiple moves have the same evaluation, they pick whichever move was searched first.

All strong alpha-beta engines employ move-ordering heuristics which guess the moves that are likely to be strongest in a position, before actually searching those moves. This is advantageous because the best case for alpha-beta search (especially for PVS) occurs when the strongest move is searched first, allowing beta cutoffs to occur as soon as possible and also avoiding repeated searches.

So when two moves are found to have the same evaluation, the tie is broken by move ordering heuristics.

Evaluation granularity also plays a role. Stockfish evaluates positions to the nearest 1/256th of a pawn, but only reports evaluations in 1/100th of a pawn, so there could be internal differentiation which is not visible to a user. MCTS engines like Lc0 make decisions based on the number of nodes searched in the subtrees of each move. This information wouldn't make sense to report as centipawns, so a conversion function is used. If many nodes have been searched, multiple moves may map to the same centipawn evaluation even if they can be differentiated internally.


Some engines uses three decimals in its evaluation. That's how can introduce a difference. I have read that its in use a technique to add a really small but ramdom number, to make them different. Don't have the references at hand, but can be known from the read.me of every engine.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.