Author: Robert Hyatt
Date: 19:32:41 02/15/03
Go up one level in this thread
On February 14, 2003 at 13:19:37, Antonio Dieguez wrote: >On February 14, 2003 at 11:33:12, Robert Hyatt wrote: > >>On February 14, 2003 at 00:51:54, Antonio Dieguez wrote: >> >>> >>>>All that is critical is that you store the same depth you probe with. If you >>>>do some extensions before storing, you had better do those same extensions >>>>before probing. IE if you don't, you are going to introduce some huge artifacts >>>>that will break things. >>> >>>It seems that is not all what is critical because precisely you may don't know >>>if the same extensions will happen in both ocassions. >> >> >>That is dangerous. The hash table stores a "position" and a "value". If >>the "position" is different, then the value is useless. If you apply different >>extensions in the _same_ position, then how can you possibly use a hash table >>hit, since you won't know which "case" it should really be matching. > >Anyone who relies on alpha or beta to decide an extension is doing that already. > >>The usual (and correct) way of hashing is to probe in the search, _before_ >>you do any extensions or anything at this specific ply. And when you store, >>you store the _same_ depth you had when you entered search and did the probe >>that failed, so that the next time you probe, and get a match, it makes sense >>to use it. > >Probing before checking for extensions make less sense in the case I mentioned >above. > >>Any other approach is going to produce instabilities. > >I don't think so, especially if there are prunning depending on beta or alpha, >probe and store after making the extension is correct. And the only way wich >could introduce more instability (depending on the program) is probing and >storing with the original depth. > If you read my comment, the main point was that it must be _consistent_. I probe before extensions, and store the same way. If you probe and store after extensions, there is nothing wrong with that since it is _consistent_. But with extensions based on alpha/beta values, this will wreck things. >>> Probing and storing with >>>the _new_ depth remaining solves that at once, but some others have said is a >>>little bit slower for them because they want to probe the hashtable first to >>>hopefully avoid the looking-for-extensions fase. Anyway many things have their >>>good and bad sides. >> >>The only requirement is that for a position P, with draft D (plies remaining >>before you drop into q-search), that D _must_ be the same when you store, as >>it will be when you probe for a match for P later. Any other approach is going >>to produce wrong results. > >The better way is that probing and storing is done with the real depth, so >checking for extensions first is ok, but I'm not saying the other way is too >bad, it may depend on the program. > >Also as I mentioned earlier, storing the real depth is not etc friendly, but in >the general case is completely correct, while storing the original depth not(may >depend on the program), in the meaning that a cutoff or alpha raising may happen >even if past time the position was not extended before and know you would >because of the new window or whatever reason.
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.