user12873: When I let Stockfish get to a certain depth (say depth 33), it gives some evaluation. Then I refresh the position (while leaving Stockfish on) and when it gets to the same depth it gives a different evaluation.
I know it uses previous analysis stored in a hash table to get to the same depth quicker the second time around, but why it can give a different evaluation puzzles me. Previous analysis should only improve search speed for a deterministic engine.
For anyone familiar with Stockfish's source code, any reasons this could be?

user15415: If Stockfish was a pure minimax/alpha-beta searcher with all leaves having a predetermined depth, your assumption that the search result should be reproducible would hold true, even with a different state of the hash table. That is because the result in minimax/alpha-beta only depends on the evaluation function, but not on the order in which the moves are searched, which only has an impact on speed.
However, in fact Stockfish is using a lot of forward pruning, reduction and extension techniques that are state/history dependent, so the results of the search of a subtree depends on the state/history with which it entered the subtree. Therefore, starting with hash table entries that influence move ordering (and can actually return a different evaluation than searching the subtree again) leads to a different result of for a search of same depth.
There is one more detail in the Stockfish case why even with pure alpha-beta search re-searching the position again would give different results. The evaluation of draws is pseudo-randomized with small fluctuation from zero in order to avoid some search artefacts in case of repetition draws, and this pseudo-random number depends on the node count of the current search. Therefore, using a different move ordering due to the hash entries would lead to different pseudo-random numbers, and hence potentially a different search result.

12873: <p>When I let Stockfish get to a certain depth (say depth 33), it gives some evaluation. Then I refresh the position (while leaving Stockfish on) and when it gets to the same depth it gives a different evaluation.</p>

<p>I know it uses previous analysis stored in a hash table to get to the same depth quicker the second time around, but why it can give a different evaluation puzzles me. Previous analysis should only improve search speed for a deterministic engine.</p>

<p>For anyone familiar with Stockfish's source code, any reasons this could be?</p>
 15415: <p>If Stockfish was a pure minimax/alpha-beta searcher with all leaves having a predetermined depth, your assumption that the search result should be reproducible would hold true, even with a different state of the hash table. That is because the result in minimax/alpha-beta only depends on the evaluation function, but not on the order in which the moves are searched, which only has an impact on speed.</p>

<p>However, in fact Stockfish is using a lot of <a href="https://www.chessprogramming.org/Selectivity" rel="noreferrer">forward pruning, reduction and extension techniques</a> that are state/history dependent, so the results of the search of a subtree depends on the state/history with which it entered the subtree. Therefore, starting with hash table entries that influence move ordering (and can actually return a different evaluation than searching the subtree again) leads to a different result of for a search of same depth.</p>

<p>There is one more detail in the Stockfish case why even with pure alpha-beta search re-searching the position again would give different results. The <a href="https://github.com/official-stockfish/Stockfish/blob/8fec8834715a440ac18e24e130888c2c60bab352/src/search.cpp#L88-L92" rel="noreferrer">evaluation of draws is pseudo-randomized</a> with small fluctuation from zero in order to avoid some search artefacts in case of repetition draws, and this pseudo-random number depends on the node count of the current search. Therefore, using a different move ordering due to the hash entries would lead to different pseudo-random numbers, and hence potentially a different search result.</p>
