Author: Andrew Williams
Date: 02:56:33 02/18/04
Go up one level in this thread
On February 18, 2004 at 02:55:48, milix wrote: >Hi to everyone! >In my amateur engine I encounter a really nasty >hash table related bug. A hash element contained a >position and a best move, say Ra8-a4. When this >position occured again in a search, the rook was not >on a8 but on a2. So the right best move should be >Ra2-a4. So, I added a routine to check for such >'corrupted' hash moves. I currently solve the above >mentioned problem by looking at legal moves in the position >that had a move with the best's move 'to' square and is moving >the best's move piece. This correction is only done when I retrieve >the PV from the hash table, so it is practically cheap. > >I have one question about the above concept: >Is this happen to every hash table or I have a pathological >situation which may (or may already have) introduce >other bugs? My hash table uses the replace always scheme >and is cleared only at the start of a new game. If you do the standard thing this could happen, but it should be VERY rare. Most modern programs use a 64-bit hash key. We store this key in the hash record. When we come to store a record in the table, we use the bottom N bits of the hash key to determine which entry in the table to put the information in. When we come to check the table to see if the current (board) position is in there, we check the hash key stored in the table against the current hash key (which represents the board position). A 64-bit collision should occur only *VERY* rarely, even with today's very fast hardware. We only proceed to use the best-move information if we are sure that the move does actually belong to this position. You don't strictly need to generate legal moves to do this, although that is clearly the only way to be 100% sure. Andrew
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.