Author: Robert Hyatt
Date: 21:33:03 05/29/04
Go up one level in this thread
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. :) > > >> >> >> >> >> >>>-- >>>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.