3

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
4

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.

| improve this answer | |
  • Not every program does it the same way. The optimum way to pick between moves that are equal is to do it randomly. – edwina oliver Jan 28 at 2:06
  • Obviously not, but as I said in my answer, every program that uses PVS will distinguish between moves of equal evaluation with their move ordering heuristics. Chess engines cannot know that two moves are equal (only that they have the same evaluation when searched). If two moves were known to be equal, then it does not matter whether you pick randomly because it does not matter which one you pick. – konsolas Jan 28 at 13:27
  • Not every program works the same way. My answer is CORRECT. – edwina oliver Jan 28 at 14:35
  • Logic and truth make me happy. All means ALL not just most. – edwina oliver Jan 29 at 0:20
1

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.

| improve this answer | |
  • Some is not all. You know a lot of engines but you do not know them all. – edwina oliver Jan 29 at 0:19

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.