Author: Robert Hyatt
Date: 20:10:07 02/14/01
Go up one level in this thread
On February 14, 2001 at 17:23:50, Frank Phillips wrote: >On February 13, 2001 at 14:09:37, Robert Hyatt wrote: > >>On February 13, 2001 at 11:24:43, Andreas Herrmann wrote: >> >>>On February 13, 2001 at 10:10:50, Robert Hyatt wrote: >>> >>>>On February 13, 2001 at 06:52:05, Andreas Herrmann wrote: >>>> >>>>>Have i to store the depth information to the hash table with or without the >>>>>extension?? >>>>> >>>>>Andreas >>>> >>>>Since you probe at the front of search, if you apply any extensions before you >>>>probe (ie in-check or whatever) then you should apply the same extension before >>>>you store. It is critical that the depth you store is the same as the depth >>>>you probe for given the same position. >>> >>>Hi Robert, >>> >>>i often look to your code, but i have little problems to understand some parts >>>in C code, because i'm a delphi developer. >>>If i saw it right in your code, you stores the depth without the extension to >>>the hash. >>> >>>Andreas >> >> >>That is right, but _be careful_. Note that in Crafty, a check extension is >>done when the check is played, rather than at the next ply after determining it >>is in check there. The main thing is to simply be sure that you are consistent >>in the 'depth' value you use for probing and for storing. IE if you store a >>modified depth value, then you need to modify it before you do the corresponding >>probe to get consistent results. > >If I have understood this at all, Crafty adds the extensions to depth at each >iteration of Search() before calling Search(), so that depth could be greater >leaving Search() than when it entered if the total extension for a move is more >than 2 ply? > No. First, extensions at one ply are limited to a maximum value of one ply. Otherwise you have a problem with non-termination. I do the check extension as I do for the reason that my q-search is very simply, and I would prefer to not reach the q-search 'in check' since it doesn't understand that. With the current approach, the _first_ ply of qsearch is guaranteed to not have the side on move in check, because otherwise it would have been extended at the previous ply and we would still be in Search() and not in Quiesce(). This also handles the 1-reply extension cleaner since the check extension is done at the previous ply and the 1-reply extension is done at the in-check ply. >Anyone like me who hacked fractional extensions onto code that treats depth >0,1,2,3,etc and carry over any residual extension the next call of Search() in a >separate variable, rather than adding it to depth, need to add this to depth at >that next iteration before probing the hash or storing a hash value - correct? > >Frank This is how I do it in Crafty. I maintain "depth" in search, and update a variable "extension" that starts out as -1 ply and gets incremented as extensions are triggered, but it is capped at 0.
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.