Author: Chris Whittington
Date: 04:05:28 11/24/97
Go up one level in this thread
On November 24, 1997 at 06:36:34, Amir Ban wrote: >On November 24, 1997 at 04:44:53, Chris Whittington wrote: > >> >>On November 24, 1997 at 01:35:38, Komputer Korner wrote: >> >>>Now that we have your word that everyone uses some sort of replacement >>>strategy when the hash table fills up, doesn't this mean that Chris >>>Whittington's description of the program acting like a drunken sailor >>>when the hash table is filled, a bit of an inaccuracy, thus the results >>>of the Korrespondence Kup are valid? >> >>No it doesn't and no it doesn't. >> >>Korner, imagine your bath tub, full of water. >> >>You want to put something in it, possibly yourself. >> >>But it can't take being full of water plus your volume as well. >> >>So when you get in, a load of water has to be displaced out, no ? >> >>So you put in the new information at the cost of the old information, >>yes ? >> >>When you need the old information it's not there, yes ? >> >>Eureka ! >> >>Chris Whittington >> > > >Eureka ? I never could understand this. If we are talking about >transposition tables, then any sensible replacement policy would leave >in the high-ply nodes and leave out the low-ply nodes. Naturellement. Its better to save the important data, and overwrite the less important data; but, nevertheless, the table can still get full; so you start by overwriting the less important data (except this data still was of some importance because you woudln't have saved it in the first place otherwise). so when you have far more entries competing for the avilable table space than the available table space, you are effectively hashing a small subset of the tree (hopefully the area near the root, plus important main lines); and not hashing the rest of the tree. So (again) the search is hash-guided whenever you're 'in' the subset; but not when you're outside it. Korner's drunken sailor fixation behavious will tend to take place in this area outside of the hashed sub-tree. Chris Whittington > Hash hits are >more important in the higher parts of the tree, and exponentially so, so >it seems that even if you are overcommitting your space 10 to 1, you >shouldn't really get hit badly. My program used to make quite a good >career with a 500KB hash or so. Of course having 50 MB is better, but >it's nothing to write home about. > >Maybe we are not talking about transposition tables here ? For the node >evaluators who speed up things by hashing several features, losing an >entry is bad news, because they have to recalculate it, and it doesn't >really matter in which level in the tree that happens. Is that it ? > >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.