Author: Sune Fischer
Date: 09:13:36 09/11/04
Go up one level in this thread
On September 11, 2004 at 00:08:20, Stuart Cracraft wrote: >Hi, > >I added keeping a triangular pv in main search and quiescence >to compare it with the output of my walk-the-hashtable-pv. > >The two differ frequently but quite often are also mostly >identical all the way through. Don't forget to check the hash flag, that the moves are actually PV moves. Mostly you get them overwritten with upper or lower moves, those should not go in the PV. >Which should I trust? Seems like the hash table is getting >overwritten with other variations (not sure why). What >kind of scenario would cause that? My algorithm is >length >= depth to replace. That's not a very good replacement scheme, if you only have a single bin I'd recommend using replace always. >Seems like triangular would be better and then use that to >prefill the hash table from the last iteration before the >next iteration would be best, as Bob Hyatt mentioned. > >In looking at both pv's, they look fine and lead to positions >that are often equal in material without any gross material errors that >could be attributed to a misimplementation but there are definite >differences between the two methods for me. There shouldn't be if you extract PV moves. It can theoreticly happen but it should be very rare. The biggest problem is short PV's. >Before I throw out the walk-the-hashtablepv, I want to be sure >that it is really no good. So I want to know exactly how a hash >table can be damaged such that its PV is corrupted. Under precisely >what circumstances can this happen? Well if you do it right I think it can only happen in one specific case; Your first PV store gets overwritten by something else, later on you reach the orginal PV node with a different depth (smaller), due to the difference in depth and missing hash entry you research and get a different PV move to store. It is unlikely I think, it might be possible to look at the depth (draft) and check for this, ie. last move had depth searched=8 plies but this move has depth searched=5. Unless you have that kind of pruning/extensions that should tell you it's a fake PV move. >I would have thought length >= depth would have prevented it as long >as there are no collisions. My hashkey is 64-bits and I am searching ><1M nodes per move for my 1 second searches so I'd expect no collisons. >Should I have some hook in there to check the collisions aren't happening >and are causing damage to the pv or is there another hash table side >effect that results in that damage? You must check for collisions in any case, but I don't think that is what causing it. -S. >Thanks all, > >Stuart
This page took 0.01 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.