Author: Nagendra Singh Tomar
Date: 20:25:01 10/29/02
Go up one level in this thread
On October 29, 2002 at 11:31:10, Robert Hyatt wrote: >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. I was waiting for your *answer* Let me go and understand IID thanx tomar
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.