Answers.Body: <p>Short principal variations are common if you retrieve the PV from the transposition table. They occur because a position that makes up part of the PV was overwritten in a collision.</p>
  <p>If you want access to the full PV, you need to maintain it separately from the transposition table. However, this can get tricky when you cut a search short due to a table hit because you would only have the PV up until that point. To handle this, you can save the searched line of each PV-node (i.e. a node with an exact score) in a separate table alongside your transposition table. Saving that information will obviously cost you memory, but as PV-nodes are relatively uncommon, it isn't actually that expensive.</p>
  <p>In my chess engine (being written in C#), I maintain the PV in a <a href="https://www.chessprogramming.org/Triangular_PV-Table#:%7E:text=A%20Triangular%20PV%2DTable%20is,propagated%20up%20to%20the%20root." rel="nofollow noreferrer">triangular PV-table</a>. When I save a PV-node, I save the list of moves that were searched after that PV-node into a Dictionary, using the position's Zobrist hash as the key. Later, when retrieving the node from the transposition table, if the node is a PV-node, I retrieve the PV for that position from the Dictionary and overwrite the relevant portion of the triangular-PV-table.</p>
  <p>This is a technique that I implemented after reading a paper that Robert Hyatt had published about ten years ago: <a href="https://www.researchgate.net/publication/279331940_A_Solution_to_Short_PVS_Caused_by_Exact_Hash_Matches" rel="nofollow noreferrer">A solution to short PVs caused by exact hash matches (2014)</a>.</p>
  <p>One thing to note is that this is not a common technique, and that is likely for good reason. This work takes resources that could be dedicated to the search. If your goal is to build the best possible chess-playing engine, you should be fine with truncated PV's as long as you have access to the singular best move from the current position. However, if your goal is to learn and understand your engine better, having access to the full PV is nice as it allows you to see the final position that the score was calculated from.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-09-25T17:07:26.410Z
Answers.LastActivityDate: 2023-09-25T17:33:24.850Z
Answers.LastEditDate: 2023-09-25T17:33:24.850Z
Answers.UserDisplayName: Nelson O
Body: <p>I was running my program on a couple test positions earlier, and I came across a problem where the PV would be shorter than the max search depth. I am now pretty sure this is due to null move reductions (instead of pruning immediately I instead decrease the search depth by one ply and re-search to avoid problems with zugzwang). Is this actually a problem for the search or should I just leave it? If it is a problem, what should I do?</p>
  
Tags: <engines>
Title: Search returns PV that has depth reduced by null move reduction
ThreadText: # Search returns PV that has depth reduced by null move reduction
  
  (Asked by: username_0 on 2023-09-07)
  
  I was running my program on a couple test positions earlier, and I came across a problem where the PV would be shorter than the max search depth. I am now pretty sure this is due to null move reductions (instead of pruning immediately I instead decrease the search depth by one ply and re-search to avoid problems with zugzwang). Is this actually a problem for the search or should I just leave it? If it is a problem, what should I do?
  
  **Tags:** engines
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2023-09-25. Score: 0 | Accepted answer
  
  Short principal variations are common if you retrieve the PV from the transposition table. They occur because a position that makes up part of the PV was overwritten in a collision.
  
  If you want access to the full PV, you need to maintain it separately from the transposition table. However, this can get tricky when you cut a search short due to a table hit because you would only have the PV up until that point. To handle this, you can save the searched line of each PV-node (i.e. a node with an exact score) in a separate table alongside your transposition table. Saving that information will obviously cost you memory, but as PV-nodes are relatively uncommon, it isn't actually that expensive.
  
  In my chess engine (being written in C#), I maintain the PV in a [triangular PV-table](https://www.chessprogramming.org/Triangular_PV-Table#:%7E:text=A%20Triangular%20PV%2DTable%20is,propagated%20up%20to%20the%20root.). When I save a PV-node, I save the list of moves that were searched after that PV-node into a Dictionary, using the position's Zobrist hash as the key. Later, when retrieving the node from the transposition table, if the node is a PV-node, I retrieve the PV for that position from the Dictionary and overwrite the relevant portion of the triangular-PV-table.
  
  This is a technique that I implemented after reading a paper that Robert Hyatt had published about ten years ago: [A solution to short PVs caused by exact hash matches (2014)](https://www.researchgate.net/publication/279331940_A_Solution_to_Short_PVS_Caused_by_Exact_Hash_Matches).
  
  One thing to note is that this is not a common technique, and that is likely for good reason. This work takes resources that could be dedicated to the search. If your goal is to build the best possible chess-playing engine, you should be fine with truncated PV's as long as you have access to the singular best move from the current position. However, if your goal is to learn and understand your engine better, having access to the full PV is nice as it allows you to see the final position that the score was calculated from.
  
  
  ---
  
  