Author: Robert Hyatt
Date: 07:43:45 05/30/04
Go up one level in this thread
On May 30, 2004 at 07:08:33, James Swafford wrote: >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 > There may be such a testing methodology. One thing is to only use exact depth matches everywhere, although that might have a flaw itself for all I know... I usually use a position like fine 70 as broken hashing will often wreck it completely.... If you validate the hash signature so you know it never gets corrupted, you have eliminated 90% of the potential bugs right there... > > >> >> >>> >>> >>>> >>>> >>>> >>>> >>>> >>>>>-- >>>>>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.