Author: Stuart Cracraft
Date: 11:36:54 09/11/04
Go up one level in this thread
On September 11, 2004 at 12:13:36, Sune Fischer wrote: >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. I don't do this since after each iteration is done I walk the PV from the hash table, put it in a separate array, and then have a function called insidepv() which returns true if the current position is along the PV that's in that array. All of this will have to switch to using the trianular array (small change but may improve searching a fair amount) as well as using this to pre-fill the hash table before each iteration per Bob. > >Mostly you get them overwritten with upper or lower moves, those should not go >in the PV. They don't. See above. My PV is stored outside of the hash table before the next iteration begins. This wasn't perfect for the old scheme and the hash moves must have been overwritten but it was better than nothing. > >>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. I tested length >= depth and length > depth. But I did not test replace always (i.e. length =/>/< depth). Why would you want to replace a hash position if length < depth? I want deeper searches not shallower ones unless your point is recency/age. > >>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. Okay -- I'll await Bob's usually crystal clear explanation but this is a start. > >>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 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.