user9436: I'm using SCID with the latest Stockfish 7 on my Ubuntu PC. When I'm analyzing a position, I can see the depth counter on the left. After seeing that the move, Nf3 say, get to depth 25, I go to play the move. I would expect that when the engine is analyzing this new position, it would start at depth 25, but this is not the case. The engine needs to work up to there from the first observed depth considering the exponential increase in time-computing depth, around 14 or so. 
Am I misinterpreting the depth counts or is there some technical reason as to why this is happening? One reason I thought, might be because if I hadn't chosen Nf3, and chose one of the worst moves, then there would be many missing branches due to pruning between candidate moves. This would mean evaluating the move using previous information would save little time since few variations have been examined. 

user7314: I think the answer is that, although the engine has indeed calculated to depth 25, it has certainly not been able to store anywhere near the amount of the tree it examined during that search, no matter the memory allocated to the transposition table (hashtable). A lot of that tree (even of the pruned tree) is discarded as the depth-25 calculation continues, and so it pretty much has to be recreated after each move.
You may object that, almost certainly there must be a depth-24 value for the position after Nf3 stored in the hashtable left over from the previous depth-25 calculation. But that kind of proves the point -- the hashtable only stores a single value and a single "principle variation" leading to that value, not the whole depth-24 tree from which that principle variation was determined, by any means.

9436: <p>I'm using SCID with the latest Stockfish 7 on my Ubuntu PC. When I'm analyzing a position, I can see the depth counter on the left. After seeing that the move, Nf3 say, get to depth 25, I go to play the move. I would expect that when the engine is analyzing this new position, it would start at depth 25, but this is not the case. The engine needs to work up to there from the first observed depth considering the exponential increase in time-computing depth, around 14 or so. </p>

<p>Am I misinterpreting the depth counts or is there some technical reason as to why this is happening? One reason I thought, might be because if I hadn't chosen Nf3, and chose one of the worst moves, then there would be many missing branches due to pruning between candidate moves. This would mean evaluating the move using previous information would save little time since few variations have been examined. </p>
 7314: <p>I think the answer is that, although the engine has indeed calculated to depth 25, it has certainly not been able to store anywhere near the amount of the tree it examined during that search, no matter the memory allocated to the transposition table (hashtable). A <em>lot</em> of that tree (even of the pruned tree) is discarded as the depth-25 calculation continues, and so it pretty much has to be recreated after each move.</p>

<p>You may object that, almost certainly there must be a depth-24 value for the position after Nf3 stored in the hashtable left over from the previous depth-25 calculation. But that kind of proves the point -- the hashtable only stores a single value and a single "principle variation" leading to that value, not the whole depth-24 tree from which that principle variation was determined, by any means.</p>
