Author: Russell Reagan
Date: 15:24:40 07/12/03
Go up one level in this thread
On July 12, 2003 at 15:32:54, Bob Durrett wrote: >That is very interesting. What I get out of this is that the "depth" parameter >[or flag] of a hash table entry is very important. If the operator were to find >a way to put "high depth" entries into the hash table, then these entries might >have a significant impact on future computations? Usually the user can't directly add entries to the table. Usually the user is restricted to 1) setting the size of the hash table, and 2) clear the entire hash table if the user chooses to do so. Of course some engines might allow the user more control, and you can always add entries by making the engine search (but you can't really force it to add or keep specific entries). >But if the operator caused these >moves to appear in the hash table as "high depth," then the pruning might not >overlook such moves [assuming they were "good" moves.]? This is true. For instance, let's say we're in a position right now, and there is a best variation. Maybe the null-move pruning (for whatever reason) prunes away the best variation, so the engine won't "see" it. If that position was already in the hash table with a good score, then the search would probably return that score instead of trying a null-move search and wouldn't be pruned (again this could vary from engine to engine). >For example, if the engine has given a recommended move [during infinite >analysis] plus a line, then the operator could go to one of the moves near the >end of that line and have the engine analyze in great depth. Then the operator >might back up to an earlier move [in that line or in the game] and have the >engine analyze that position. The "high depth" analysis should have put entries >into the hash table marked as "high depth." Then the subsequent analysis of the >earlier position might not prune out that data due to it's "high depth" status. >[I assume pruning changes hash table data.] I think some people do this when they are looking for a long mate, for instance. I recall recently that Deiter (author of Yace) posted some long mate like "mate in 183" or something that Yace found, and IIRC he did something similar to what you described, giving the engine "hints" and then backing it up slowly so the engine could "see" the long mate. >I'm not sure what "settings" are, but I imagine the operator influencing the >data content of the hash table. Intuitively, it would seem that the contents of >the hash table [especially if a very large table] would depend primarily on the >history of engine computations leading up to the time when the hash table >contents are examined. The operator has a DIRECT influence on this history. By "settings" I mean what I said above (setting the size of the hash table, etc.).
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.