Author: Robert Hyatt
Date: 08:31:10 10/29/02
Go up one level in this thread
On October 29, 2002 at 11:29:40, Robert Hyatt wrote: >On October 28, 2002 at 19:39:15, Nagendra Singh Tomar wrote: > >>I am using iterative deepening with transposition tables. Suppose at some >>point in the match I have a board that is say stored in hash with stored depth >>10. So when iterative deepening searches that position with increasing depth, >>till depth 10 hash_probe will return the stored position and so alphabeta >>returns instantly. Since I am not using some hash2pv kind of function, I get a >>PV length of 1 with the best hash move being on the PV. But now when the >>iterative deepening searches for depth 11, the (stored_depth>= depth) clause >>is not true inside hash_probe and hence it does not return the stored >>position. > >Just because the draft was insufficient to let you take the score as good and >produce a cutoff, you _still_ use the hash move as the first move to search at >this ply... > > >>Now alphabeta is on its own with no PV to help it order the moves >>(just some help from the hash inmove ordering). In such cases my program takes >>an unusually *long* time to search the next iteration (11th in this example). >>This reminds me of the days when I was not using iterative deepening and >>searching to a fixed depth. >>Is this normal behaviour, or dies it say something about the inefficiency of >>the hash ? >>What do we do to avoid this ? >> >>regds >>tomar Another point. If you are talking about the case where you get a short PV at depth N and then depth N+1 is harder to search, look up "Internal Iterative Deepening" which will help in that particular case significantly.
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.