Author: Sune Fischer
Date: 06:01:09 07/04/02
Go up one level in this thread
On July 04, 2002 at 07:29:31, Sven Reichard wrote: >>>Inheritance?! Put everything that is common to both tables in a base class, and >>>derive the hash table and the pawn hash table from it. If you want to go to >>>extremes, write a template class which gets the respective table entries as a >>>parameter. >> >>yeah, ok, if you absolutely must do it OO, but the point of doing it like that >>is very limited when they have no common member vars or functions, IMO. > >If there is no common functionality, then there is not point in doing that, I >agree. However, since both are hash tables, I would expect some common things >(updating the zobrist key, finding the correct entry, verifying the entry, >etc.). Other than a partial name, I can't see them as having much in common. The pawnhash doesn't care about who is to move, it doesn't care about search flags or bounds, you may want partial scores for things to use in the other eval (ex: if passed pawns, then also check if king is within square, but this can't be done in the pawn evaluation only), you don't want to store a hash move.... And the key size is different in my program, I use 64 bit keys for the real hash and 32 bit (upperkey) for the pawnhash. I think 32 bits plus those bits used for indexing (~20 bits) is enough to avoid collisions in this case. It may even be enough for the real hash, but I haven't tested, even if you get 1 collision an hour it probably would be smarter to dense up the table by saving 4 bytes. >>>The only place where you need the hash table is the search algorithm, isn't it? >> >>Some also use the HT for generating PV's, I don't do that, yet. >I have a method HashedAlphaBeta::printPV(std::ostream); > >>Besides I could have more "search" instances in a parallel program, so the HT >>would have to at least be static. >> >I haven't found an application of two search algorithms sharing the same HT. The >qsearch, which is in a different class, doesn't use the HT yet. (Maybe that's >why my trees are so big:)) If it does, I can give it access to the instance in >HashedAlphaBeta. BTW, how do you handle the transposition tables in the qsearch? I don't. It would be complicated because qsearch is a heavily 'pruned' search, and I wouldn't trust these scores in the real search. Vincent said he hashed qsearch, maybe it can be done, but I have no idea how. Instead, if you have a really huge eval, you could do the same as with the pawn hash, just save the static score in an evalhash, again you wouldn't need to worry about who to move or hashmove etc. because it's just not a part of the search (unless you use that information in the evaluation of course). Lazy eval can't be done this way as far as I can tell, the bounds play a role. -S.
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.