Answers.Body: <p>Ok, I've finally found the root cause of your problem: you are storing the ply rather than the depth in the transposition table. This is wrong, and it ultimately causes your table to save only the results that you have the least information about, and only accept the results which are least informative.</p>
  <p>In a transposition table, we save the value of the depth parameter because this tells us how much further we searched beyond that position before we reached the calculated score. The ply tells you how far into the search you were before you reached this position. The evaluation of a position does not depend on history (which is what the ply would hint at), it only depends on what happens after the position. It does not matter if we reached the position on move 1, 5, 10, 50, the best follow-up will always be the same.</p>
  <p>When retrieving the results from the table, we compare the depth that the saved result was searched to against the depth that we need to search to. If the saved result was searched at least as deeply as we were planning to search, we can return that result immediately. If not, we can't accept the prior results and need to continue further. As implemented currently, you are essentially doing the opposite. If the saved result was searched more deeply than you plan to search, you ignore it, but if it was searched less deeply, you accept it, leading to blunders due to the low search depth in these evaluations.</p>
  <hr />
  <p>The fix is not too difficult. In the Search, you should be saving the value of <code>depth</code> in the TranspositionTable, and comparing the <code>depth</code> against the saved depth in the entry. You should also update the names of the relevant variables in TranspositionTable and TranspositionEntry so that it is clear that you are saving depth, not ply.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-08-11T03:36:04.457Z
Answers.Text: That seems to have worked, thank you so much! Kind of annoying such a minor error was creating such a huge problem.
Answers.UserDisplayName: Nikhil
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-01-07T15:39:02.590Z
Answers.Text: Doesn't the move we reach a position in matter, though, because of the 50-move rule (and maybe also because of the threefold repetition rule)?
Answers.UserDisplayName: HelloGoodbye
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-01-08T17:16:41.357Z
Answers.Text: @HelloGoodbye That is true, and that is why it is a good idea to consider those rules prior to looking at the transposition table. In Stockfish, the position is evaluated for a draw prior to querying the transposition table, and the score from the transposition table is also not returned if we are within 10 ply (so 5 turns) of the 50-move rule being relevant. It is important to consider these rules, but it is easy enough to handle them separately so that the bulk of the search can ignore these exceptions.
Answers.UserDisplayName: Nelson O
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-01-10T07:25:49.353Z
Answers.Text: That makes sense. But it feels like that instead of ignoring the transposition table altogether when you are within 10 ply of the 50-move rule being relevant, you could instead just make the hash code dependent on how many moves that have been made since the last capture (even if you only do so in the cases where you would otherwise have ignored the transposition table).
Answers.UserDisplayName: HelloGoodbye
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-08-08T22:06:57.480Z
Answers.LastActivityDate: 2023-08-08T22:06:57.480Z
Answers.UserDisplayName: Nelson O
Body: <p>I am developing a chess engine and have implemented various basic algorithms such as negamax search, alpha beta pruning with move ordering, and quiescence search. I have a transposition table with an always-replace scheme because it seems to work better, however I've found that if I don't clear my transposition table between every move, the engine sometimes makes terrible blunders like hanging mate in one. I've looked online for solutions and a common error I found was that the table can sometimes become polluted with draw scores, however I've set up my code such that any draw scores simply aren't stored in the table, but that hasn't fixed the problem. I've made sure my zobrist hashing is working correctly, I'm not really sure what else could be causing this issue.</p>
  <p>I've based my negamax search off this website.</p>
  <p><a href="https://en.wikipedia.org/wiki/Negamax" rel="nofollow noreferrer">https://en.wikipedia.org/wiki/Negamax</a></p>
  <p>Any help would be appreciated.</p>
  <p>Edit: Here's a link to my code if anyone wants to go further in detail. <a href="https://github.com/nikhilsarin1/Chess-Engine" rel="nofollow noreferrer">https://github.com/nikhilsarin1/Chess-Engine</a></p>
  <pre><code>public int search(int depth, int ply, int alpha, int beta) {
      int alphaOriginal = alpha;
  
      long zobristKey = model.getZobristKey();
  
      TranspositionEntry entry = model.transpositionTable.getPosition(zobristKey);
  
      if (entry != null &amp;&amp; entry.ply() &gt;= ply) {
        if (entry.flag() == TranspositionEntry.Flag.EXACT) {
          bestMoveForCurrentSearch = entry.bestMove();
          return entry.score();
        } else if (entry.flag() == TranspositionEntry.Flag.LOWER_BOUND) {
          alpha = Math.max(alpha, entry.score());
        } else if (entry.flag() == TranspositionEntry.Flag.UPPER_BOUND) {
          beta = Math.min(beta, entry.score());
        }
        if (alpha &gt;= beta) {
          return entry.score();
        }
      }
  
      if (model.isCheckmate()) {
        return -mateScore + ply;
      } else if (model.isDraw()) {
        return 0;
      }
  
      if (depth == 0) {
        return quiescenceSearch(alpha, beta);
      }
  
      int evaluation = -999999999;
      Move bestMoveAtCurrentDepth = null;
  
      for (Move move : model.getBitboard().getLegalMoves()) {
        searchCount++;
        model.movePiece(move, false, depth);
        int score = -search(depth - 1, ply + 1, -beta, -alpha);
        model.undoMove();
  
        if (score &gt; evaluation) {
          evaluation = score;
          bestMoveAtCurrentDepth = move; // Update the best move at this depth
        }
  
        alpha = Math.max(alpha, evaluation);
  
        if (alpha &gt;= beta) {
          model.getBitboard().recordKillerMove(move, depth);
          break;
        }
      }
  
      TranspositionEntry.Flag flag;
  
      if (evaluation &lt;= alphaOriginal) {
        flag = TranspositionEntry.Flag.UPPER_BOUND;
      } else if (evaluation &gt;= beta) {
        flag = TranspositionEntry.Flag.LOWER_BOUND;
      } else {
        flag = TranspositionEntry.Flag.EXACT;
      }
  
      if (evaluation != 0) {
        model.transpositionTable.storePosition(
            zobristKey, ply, evaluation, flag, bestMoveAtCurrentDepth);
      }
  
      bestMoveForCurrentSearch = bestMoveAtCurrentDepth;
      return evaluation;
    }
  
  </code></pre>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2023-08-01T15:44:26.657Z
Comments.Text: Do you see any weird issues with castling rights? It looks like your rank masks define Rank 1 as 0xFF, which should imply that the white Queenside Rook is on square 1 and the Kingside Rook is on Square 7, but the move code uses those for the origin squares (and capture squares) of black rooks when updating castling rights. I don't know if that's the (or even an) issue, but it's just something I've noticed so far.
Comments.UserDisplayName: Nelson O
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2023-08-01T18:25:34.023Z
Comments.Text: Another point: the Transposition Table in chess engines do not typically use a built-in map/dictionary data structure. They typically use fixed-size arrays and use the hashkey to figure out the index in the array that the value should be stored at. Collisions in the index is what "always overwrite" refers to as collisions on hashes is very unlikely in a single game. Using the Map would mean that every analyzed position is saved and your hash table will continue to grow. If you don't clear it between moves, does memory usage continue to grow?
Comments.UserDisplayName: Nelson O
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2023-08-08T02:49:02.257Z
Comments.Text: @NelsonO I haven't noticed any issues with castling rights. My move generation passes all PerfT tests I gave which includes various edge cases for castling (enemy attacks, king/rook moves, enemy capturing rook, etc) so I would assume it works based on that, but I could've missed an edge case I didn't think about. I think my code is poorly written in that the LSB of my bitboard represents square a1 but the array index of that in the char array representation of the board is 56, so that would make the black queen side rook index 0 or a8. I can see how that would be unnecessarily confusing.
Comments.UserDisplayName: Nikhil
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2023-08-08T03:14:54.447Z
Comments.Text: @NelsonO That is something I saw in other people's codes, but I just assumed it didn't matter, but I'm now realizing that may have been a faulty assumption. I'm not sure why using a fixed-size array vs a built-in Java map structure makes a difference though. My thought was that if I use a Map, I can avoid the problem of index collisions to a greater extent since java automatically increases the capacity of the hash map based on the load factor and as long as my Zobrist keys are generated correctly, I should very rarely be generating the same key for different positions.
Comments.UserDisplayName: Nikhil
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2023-08-08T21:07:56.053Z
Comments.Text: It's too much to go into detail here, but the gist is that a transposition table cannot reasonably store all evaluated positions, so we do not need a structure that attempts to store everything that we give it. Aside from that, many positions eventually become irrelevant due to irreversible moves, so we are also fine with a data structure that overwrites data. Lastly, growing a table is expensive, so we prefer to specify a fixed size when initializing the engine to both constrain the maximum size, and also avoid reorganizing the table during a search.
Comments.UserDisplayName: Nelson O
Tags: <engines><programming>
Title: Chess Programming, Have to clear my transposition table after every move
ThreadText: # Chess Programming, Have to clear my transposition table after every move
  
  (Asked by: username_0 on 2023-07-24)
  
  I am developing a chess engine and have implemented various basic algorithms such as negamax search, alpha beta pruning with move ordering, and quiescence search. I have a transposition table with an always-replace scheme because it seems to work better, however I've found that if I don't clear my transposition table between every move, the engine sometimes makes terrible blunders like hanging mate in one. I've looked online for solutions and a common error I found was that the table can sometimes become polluted with draw scores, however I've set up my code such that any draw scores simply aren't stored in the table, but that hasn't fixed the problem. I've made sure my zobrist hashing is working correctly, I'm not really sure what else could be causing this issue.
  
  I've based my negamax search off this website.
  
  <https://en.wikipedia.org/wiki/Negamax>
  
  Any help would be appreciated.
  
  Edit: Here's a link to my code if anyone wants to go further in detail. <https://github.com/nikhilsarin1/Chess-Engine>
  
  ```
  public int search(int depth, int ply, int alpha, int beta) {
      int alphaOriginal = alpha;
  
      long zobristKey = model.getZobristKey();
  
      TranspositionEntry entry = model.transpositionTable.getPosition(zobristKey);
  
      if (entry != null && entry.ply() >= ply) {
        if (entry.flag() == TranspositionEntry.Flag.EXACT) {
          bestMoveForCurrentSearch = entry.bestMove();
          return entry.score();
        } else if (entry.flag() == TranspositionEntry.Flag.LOWER_BOUND) {
          alpha = Math.max(alpha, entry.score());
        } else if (entry.flag() == TranspositionEntry.Flag.UPPER_BOUND) {
          beta = Math.min(beta, entry.score());
        }
        if (alpha >= beta) {
          return entry.score();
        }
      }
  
      if (model.isCheckmate()) {
        return -mateScore + ply;
      } else if (model.isDraw()) {
        return 0;
      }
  
      if (depth == 0) {
        return quiescenceSearch(alpha, beta);
      }
  
      int evaluation = -999999999;
      Move bestMoveAtCurrentDepth = null;
  
      for (Move move : model.getBitboard().getLegalMoves()) {
        searchCount++;
        model.movePiece(move, false, depth);
        int score = -search(depth - 1, ply + 1, -beta, -alpha);
        model.undoMove();
  
        if (score > evaluation) {
          evaluation = score;
          bestMoveAtCurrentDepth = move; // Update the best move at this depth
        }
  
        alpha = Math.max(alpha, evaluation);
  
        if (alpha >= beta) {
          model.getBitboard().recordKillerMove(move, depth);
          break;
        }
      }
  
      TranspositionEntry.Flag flag;
  
      if (evaluation <= alphaOriginal) {
        flag = TranspositionEntry.Flag.UPPER_BOUND;
      } else if (evaluation >= beta) {
        flag = TranspositionEntry.Flag.LOWER_BOUND;
      } else {
        flag = TranspositionEntry.Flag.EXACT;
      }
  
      if (evaluation != 0) {
        model.transpositionTable.storePosition(
            zobristKey, ply, evaluation, flag, bestMoveAtCurrentDepth);
      }
  
      bestMoveForCurrentSearch = bestMoveAtCurrentDepth;
      return evaluation;
    }
  
  ```
  
  **Tags:** engines, programming
  
  > **Comments:**
  > **username_1**: Do you see any weird issues with castling rights? It looks like your rank masks define Rank 1 as 0xFF, which should imply that the white Queenside Rook is on square 1 and the Kingside Rook is on Square 7, but the move code uses those for the origin squares (and capture squares) of black rooks when updating castling rights. I don't know if that's the (or even an) issue, but it's just something I've noticed so far.  
  > **username_1**: Another point: the Transposition Table in chess engines do not typically use a built-in map/dictionary data structure. They typically use fixed-size arrays and use the hashkey to figure out the index in the array that the value should be stored at. Collisions in the index is what "always overwrite" refers to as collisions on hashes is very unlikely in a single game. Using the Map would mean that every analyzed position is saved and your hash table will continue to grow. If you don't clear it between moves, does memory usage continue to grow?  
  > **username_0**: @username_1 I haven't noticed any issues with castling rights. My move generation passes all PerfT tests I gave which includes various edge cases for castling (enemy attacks, king/rook moves, enemy capturing rook, etc) so I would assume it works based on that, but I could've missed an edge case I didn't think about. I think my code is poorly written in that the LSB of my bitboard represents square a1 but the array index of that in the char array representation of the board is 56, so that would make the black queen side rook index 0 or a8. I can see how that would be unnecessarily confusing.  
  > **username_0**: @username_1 That is something I saw in other people's codes, but I just assumed it didn't matter, but I'm now realizing that may have been a faulty assumption. I'm not sure why using a fixed-size array vs a built-in Java map structure makes a difference though. My thought was that if I use a Map, I can avoid the problem of index collisions to a greater extent since java automatically increases the capacity of the hash map based on the load factor and as long as my Zobrist keys are generated correctly, I should very rarely be generating the same key for different positions.  
  > **username_1**: It's too much to go into detail here, but the gist is that a transposition table cannot reasonably store all evaluated positions, so we do not need a structure that attempts to store everything that we give it. Aside from that, many positions eventually become irrelevant due to irreversible moves, so we are also fine with a data structure that overwrites data. Lastly, growing a table is expensive, so we prefer to specify a fixed size when initializing the engine to both constrain the maximum size, and also avoid reorganizing the table during a search.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2023-08-08. Score: 4 | Accepted answer
  
  Ok, I've finally found the root cause of your problem: you are storing the ply rather than the depth in the transposition table. This is wrong, and it ultimately causes your table to save only the results that you have the least information about, and only accept the results which are least informative.
  
  In a transposition table, we save the value of the depth parameter because this tells us how much further we searched beyond that position before we reached the calculated score. The ply tells you how far into the search you were before you reached this position. The evaluation of a position does not depend on history (which is what the ply would hint at), it only depends on what happens after the position. It does not matter if we reached the position on move 1, 5, 10, 50, the best follow-up will always be the same.
  
  When retrieving the results from the table, we compare the depth that the saved result was searched to against the depth that we need to search to. If the saved result was searched at least as deeply as we were planning to search, we can return that result immediately. If not, we can't accept the prior results and need to continue further. As implemented currently, you are essentially doing the opposite. If the saved result was searched more deeply than you plan to search, you ignore it, but if it was searched less deeply, you accept it, leading to blunders due to the low search depth in these evaluations.
  
  ---
  
  The fix is not too difficult. In the Search, you should be saving the value of `depth` in the TranspositionTable, and comparing the `depth` against the saved depth in the entry. You should also update the names of the relevant variables in TranspositionTable and TranspositionEntry so that it is clear that you are saving depth, not ply.
  
  > **Comments:**
  > **username_0**: That seems to have worked, thank you so much! Kind of annoying such a minor error was creating such a huge problem.  
  > **username_2**: Doesn't the move we reach a position in matter, though, because of the 50-move rule (and maybe also because of the threefold repetition rule)?  
  > **username_1**: @username_2 That is true, and that is why it is a good idea to consider those rules prior to looking at the transposition table. In Stockfish, the position is evaluated for a draw prior to querying the transposition table, and the score from the transposition table is also not returned if we are within 10 ply (so 5 turns) of the 50-move rule being relevant. It is important to consider these rules, but it is easy enough to handle them separately so that the bulk of the search can ignore these exceptions.  
  > **username_2**: That makes sense. But it feels like that instead of ignoring the transposition table altogether when you are within 10 ply of the 50-move rule being relevant, you could instead just make the hash code dependent on how many moves that have been made since the last capture (even if you only do so in the cases where you would otherwise have ignored the transposition table).  
  
  ---
  
  