Author: James Swafford
Date: 04:08:33 05/30/04
Go up one level in this thread
On May 30, 2004 at 00:33:03, Robert Hyatt wrote: >On May 29, 2004 at 22:50:44, James Swafford wrote: > >>On May 29, 2004 at 22:21:55, Robert Hyatt wrote: >> >>>On May 29, 2004 at 22:01:23, James Swafford wrote: >>> >>>>On May 29, 2004 at 21:23:28, Robert Hyatt wrote: >>>> >>>>>On May 29, 2004 at 11:10:47, James Swafford wrote: >>>>> >>>>>>In a recent post, Tord suggested setting a flag in >>>>>>the search when the hash table suggests a fail high, and >>>>>>testing whether the search would indeed fail high. >>>>>> >>>>>>The idea seems so simple I'm embarassed I haven't thought >>>>>>of it before. :) >>>>>> >>>>>>I've been 'pretty sure' for a long time that I've got some >>>>>>nasty hash bugs. I'm in the mood to exterminate them. >>>>>> >>>>>>Last night I implemented Tord's idea and, to my dismay >>>>>>(but not to my surprise) my hash table is saying 'fail >>>>>>high' when the search wouldn't have failed high. And- >>>>>>it doesn't take very long. :) >>>>> >>>>>This is _not_ necessarily a bug. >>>>> >>>>>Your hash table entry can have a draft > depth, while the real search you will >>>>>do will only go to depth. A deeper search might say fail high while a shallower >>>>>search fails low. >>>>> >>>>>That test is no good... >>>>> >>>> >>>>That was suggested below, so I modifed the test to only set >>>>the 'hash_says_fh' flag if the hash depth == current search depth, >>>>and disabled null move, extensions, other hash table cutoffs, >>>>etc. >>>> >>>>On move 41 of WAC, it happened again. I've not even >>>>begun to hunt it down (maybe just a collision?), but >>>>I will. >>>> >>> >>>Again, that will _not_ work. You still probe the table below the point where >>>you decide to do a search to see if the table result is correct. And down into >>>the tree there you can get different results again. >>> >> >>I don't understand what you're saying. I probe the table towards >>the top of my search (only time check comes before that). > >Here is what I thought you are doing... > >1. probe the table to see what you get; > >2. Ignore that and do a real search; > >3. Compare what the real search returned vs what the table said to return, and >if they don't agree, report an "error". > >That won't work. A probe gets a static result computed when this position was >searched the last time. A search gets a dynamic result that can use information >produced _since_ that hash entry was stored, to provide a more accurate result. >So the search can produce a better result than what you get from the static hash >probe. Not often, but it happens enough... > > >> >>I'm not allowing _any_ cutoffs during this test. No fail highs, >>no fail lows, no exact scores. I'm simply recording that the >>hash table says I _should_ fail high, and I only do that IF the >>depth recorded in the table is exactly the same as 'depth' in the >>search. > > > >See above. That fails because the search you do to verify what the table says >is different than the search done to store the table result the first time, >because the verification search has access to information (hash table info) that >the original search did not. Hence, differences... > > >> >>>You simply can not test the hashing that way. Unless you restrict _all_ hash >>>probes to only match on exact depth as well... By "all" I mean _all_ and not >>>just the probes where you are going to validate them by a search... >> >>I just disabled the other hash probes. >> >>Do you still think the test is flawed? > >Yep. And badly. :) Well #?^&@*@#$!!!! :) Other than storing some or all of the board position and verifying that on a 'hit', do you use or know of any methods to test out a hash table? I just want to be sure it does the 'right thing'. -- James > > >> >> >>> >>> >>> >>> >>> >>>>-- >>>>James >>>> >>>> >>>> >>>>> >>>>>> >>>>>>This seems like a nasty thing to debug. I'm comtemplating >>>>>>how I might go about it. I'm hoping some of you can >>>>>>provide some suggestions... >>>>>> >>>>>>-- >>>>>>James
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.