Author: Ed Schröder
Date: 07:55:45 10/18/98
Go up one level in this thread
>>>I do the same, but I generate 48-bit numbers (actually only 45-bit, because I >>>don't bother completing the MSbit), not 32-bit as you do. I think it's >>>generally cknowledged that 32-bit is not enough ? >>>Amir >>He is actually using more than 32 bits. We had a long discussion about >>this last year, where he is storing the move that produced this position >>(the move that takes him from the parent position to the current position >>in addition to the best move from this position). This is another way of >>adding bits (in his case I'd say the effect is like an extra 8-12 bits of >>hash signature...) >??? >If you treat the move that produced the position as part of the key, then you >will not recognize transpositions. Of course. I check for hash-errors in 2 ways: #1. The "best-move" in the HT must be a legal move. #2. The "to-square" and "piece-type" leading to the current position must be found in the history till the root. This in steps of 2 plies of course. If it does not exist you for 99.9% have a hash-error. Example: 1.e4 e5 2.f4 When 2.f4 is stored in the HT I store square "f4" and piece-type "pawn" too. 1.f4 e5 2.e4 Since this position occurs in the HT the square "f4" and piece-type "pawn" MUST be found in the history. It fits with 1.f4 searching back 2 plies in this particular case. If it not fits (f4 and pawn are not found) I do not reward the transposition. There is one weird exception to this rule where for instance 2 knights exchange squares in the tree. But so what. It's very rare and not rewarding a transposition does no harm. - Ed - >Amir
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.