Author: Robert Hyatt
Date: 12:44:26 09/22/98
Go up one level in this thread
On September 22, 1998 at 15:38:55, Robert Hyatt wrote: >> >>But surely then you need to probe twice in table look-ups, since there are two >>possible positions in memory where the entry might be found? Do you access the >>depth-preferred table first, and only probe the always-store table if you don't >>find a match in the depth-preferred? And when you are storing a position, do you >>move the old entry to always store (1st clause of code above) even if it is the >>same position with lower depth, rather than a different position at lower depth? >>If so, then how do you deal with the possibility of two entries for the same >>position at different depths? >> I hit "submit" too quickly (by accident) and didn't answer all of your question. It is unlikely that I would ever try to store a position X with depth N in the table when the same position X is there with a depth N+anything. Because the depth N+anything entry should, had it been useful, caused a cutoff already... so I ignore this... > > >very unlikely to happen, but possible. I probe the depth-first table which >is a pretty sure guarantee to hold the deepest entries. It is unlikely that >both will hold the same one, because if so, I would have gotten a hash hit >before searching here most likely. But I don't waste time. If I hit on >the depth-preferred table, I don't even probe the other one.. but it would >be easy to instrument to see if it would ever happen.. > > > > > >>In the depth preferred table, how do you recognise old entries from searches >>that were done so far back in the game to have lost any relavence to the currant >>position? This is a poblem I currantly ignore, but I bet I am clogging up the >>table to some extent in this way. I am hoping to overhaul all my hashing code in >>the near future, so I would like to plan all the details now before I get >>started. I store a small "counter" called "transposition_id". this counter is incremented each time a move is made on the real board, and wraps around when it reaches 8. The valid values are 1-7, and I reserve "0" for "permanent entries" such as those from the position learning file, when this is turned on. When I do a store, the first test is if trans_id[entry] != transposition_id then I overwrite that entry immediately, even in the depth-preferred table where the depth of the entry is greater than the current depth... >> >>There's more to this hashing thing than I realised! >> >>Best wishes, >>Roberto
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.