Author: Bas Hamstra
Date: 08:33:20 10/19/00
Go up one level in this thread
On October 18, 2000 at 09:48:53, José Carlos wrote: >On October 18, 2000 at 09:13:13, Bas Hamstra wrote: > >>On October 18, 2000 at 08:06:23, David Rasmussen wrote: >> >>>I was wondering about a potential "bug" or at least "unwanted feature" of the >>>way hashing and extensions affect eachother in, say, Crafty. >>> >>>The problem is basically this: >>> >>>In Crafty, whenever depth is used for other purposes than searching (that is >>>hashing and nullmove), the extension factor isn't included. That means that a >>>search that essentially asked for a depth=5 + extensions=3 == 8 ply search, will >>>return with success from the hashprobe if the draft is just 6 or 7. Shouldn't >>>the depth parameter ALWAYS be used with relevant extensions for the search to be >>>(at least more) theoretically correct ? >>> >>>Am I making sense? >> >>I think I know what you mean. I store always as draft the depth that is actually >>searched below this node. So if I normally would search 5 ply, but there is 1 >>extension, this node is searched at 6 ply. So store draft=6. >> >>Now when the search asked for a 6 ply depth, and there was no extension, the >>hashrecord with draft=6 could theoretically be returned. >> >>I believe Crafty does something different, that I too don't understand. >> >> >>Regards, >>Bas Hamstra. > > I think I don't understand you. When you say you store the depth that is >actually searched below this node, do you mean the depth of the PV? Because >there can be a lot of extensions in other branchs of the tree... > I say I don't understand because: Practically the first thing I do when entering a node, is setting the extensions. That is, sometimes MaxDepth will be increased by 1. For instance when MoveColor is in check, MaxDepth is increased (I use MaxDepth and Depth, Draft is MaxDepth-Depth for me). Then follows the probe in the hashtable, and after that nullmove/search. All based on the same adjusted (or not) MaxDepth. I think this is a consistent scheme. Of course below this node new extensions might follow. But that is not to foresee at this point and I cannot let the Draft that is stored in the hashtable at this node be affected. So when normally below this node 5 ply is to be searched, BUT there was a check extension (that increased MaxDepth at the beginning of this node), I store Draft=6. The tree below this node has actually been searched at that depth, so that is the Draft I want in the hashtable. > -you start a search for depth=5. > -when the search returns, you get an actual depth of 6 due to a check >extension in the PV. > -then you store depth=6 in the hash table??? No, that is not what I meant. > IMO, this is wrong, because if you reach that position again with depth=6 and >use the value from the HT, you are actually missing a ply (the extra ply you'd >extend if you searched the node). > > But, probably, I've misuderstood you both :( > Regards, > José C. Regards, Bas.
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.