Author: Bas Hamstra
Date: 12:51:52 05/18/98
Go up one level in this thread
On May 18, 1998 at 11:28:14, Robert Hyatt wrote: >On May 18, 1998 at 09:49:40, Peter Fendrich wrote: > >>Has anyone tried this? >> >>I found the following description at: >>http://www.xs4all.nl/~verhelst/chess/search.html#enhanced-transposition >>---------------------------------------------------------------- >>There may be several successors causing a cutoff and we want to use the >>one with the smalles search tree. One idea that has been tried is to >>look at all successor positions and see if they are in the transposition >>table and cause a cutoff. If one such position is found, no further >>serach has to be done. >>This can save about 20-25% in total tree size. >>---------------------------------------------------------------- >> >> >>//Peter > >I tried it about 2 years ago... It does two things: (1) it will reduce >the size of the tree searched by about 10% according to the tests I ran >way back then. (2) it breaks programs that generate moves in batches, >because you can't... you have to generate *all* the moves, and use each >move to produce a new hash signature that you use to probe the hash >table >to decide which move to try. In Crafty, this cost me more than that 10% >saving in nodes searched. > >If you always generate all the moves (Cray Blitz did because the moves >were vectorized) then this works, and we used it there with success. >But >if you defer move generation as I do in crafty, by generating only >captures, >and then trying killers before generating non-captures, you lose the >benefits of that. A program like dark thought that "generates as >needed" >would probably slow down even more, assuming it still generates moves a >few at a time. Wouldnt it help to only do it for Depth > 3 (supposing endnode has Depth=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.