Answers.Body: <p>No. Your assumption is based on searching everything up to depth <code>D</code>, but no modern chess engine would do that. It's complicated to explain, but fair to assume only some subtrees up to depth <code>D</code> are explored. The other trees got "cut" off for various reasons, most likely they are not good.</p>
  
  <p>Chess programming is all about skipping the search tree accurately. The conditions could depend on the depth to the root, previously visited nodes, and many others. As you make a move on the board, all parameters change, even the cache for keeping the transposition table change. Trees that are previously visited may now be skipped, and vice versa. The change of information in the transposition table could have a significant impact in the new search path.</p>
  
  <blockquote>
    <p>it will be negative if the engine prefers the player's move to its initial choice after seeing one ply farther in the line beginning with the player's move. Is this expected and acceptable? </p>
  </blockquote>
  
  <p>Anything can happen. The difference can be positive, negative, or remain unchanged.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-03-24T00:18:20.267Z
Answers.Text: Thank you for relieving me of my illusions surrounding how straightforward a modern engine's search function is. Is it the case, then, that you simply get an engine's evaluation with certain parameters, make the player's move, and get a second evaluation with the same parameters? That's what I'm doing right now.
Answers.UserDisplayName: DATACOMMANDER
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-03-23T10:24:28.120Z
Answers.LastActivityDate: 2020-03-23T10:24:28.120Z
Answers.UserDisplayName: SmallChess
Body: <p>I've been letting the engine analyze a position at depth D, then making the player's move and letting the engine analyze the resulting position at the same depth D, and then taking the difference between the first score and the second score (both from the same player's perspective, of course). This procedure has the property that it's possible to have a negative centipawn loss: it will be negative if the engine prefers the player's move to its initial choice after seeing one ply farther in the line beginning with the player's move. Is this expected and acceptable? The alternative would be to have the engine analyze the position after the player's move at depth D - 1, which would guarantee a non-negative centipawn loss. </p>
  
Tags: <engines>
Title: What's the correct way to calculate centipawn loss?
ThreadText: # What's the correct way to calculate centipawn loss?
  
  (Asked by: username_0 on 2020-03-23)
  
  I've been letting the engine analyze a position at depth D, then making the player's move and letting the engine analyze the resulting position at the same depth D, and then taking the difference between the first score and the second score (both from the same player's perspective, of course). This procedure has the property that it's possible to have a negative centipawn loss: it will be negative if the engine prefers the player's move to its initial choice after seeing one ply farther in the line beginning with the player's move. Is this expected and acceptable? The alternative would be to have the engine analyze the position after the player's move at depth D - 1, which would guarantee a non-negative centipawn loss.
  
  **Tags:** engines
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2020-03-23. Score: 3
  
  No. Your assumption is based on searching everything up to depth `D`, but no modern chess engine would do that. It's complicated to explain, but fair to assume only some subtrees up to depth `D` are explored. The other trees got "cut" off for various reasons, most likely they are not good.
  
  Chess programming is all about skipping the search tree accurately. The conditions could depend on the depth to the root, previously visited nodes, and many others. As you make a move on the board, all parameters change, even the cache for keeping the transposition table change. Trees that are previously visited may now be skipped, and vice versa. The change of information in the transposition table could have a significant impact in the new search path.
  
  > it will be negative if the engine prefers the player's move to its initial choice after seeing one ply farther in the line beginning with the player's move. Is this expected and acceptable?
  
  Anything can happen. The difference can be positive, negative, or remain unchanged.
  
  > **Comments:**
  > **username_0**: Thank you for relieving me of my illusions surrounding how straightforward a modern engine's search function is. Is it the case, then, that you simply get an engine's evaluation with certain parameters, make the player's move, and get a second evaluation with the same parameters? That's what I'm doing right now.  
  
  ---
  
  