Author: Uri Blass
Date: 07:22:25 04/13/03
Go up one level in this thread
On April 13, 2003 at 10:07:27, Vincent Diepeveen wrote: >On April 13, 2003 at 10:01:48, Omid David Tabibi wrote: > >>On April 13, 2003 at 07:41:00, Vincent Diepeveen wrote: >> >>>On April 13, 2003 at 00:14:52, Omid David Tabibi wrote: >>> >>>may i remind you that many programs use R=3 basically with exception sometimes >>>of the nullmove of depthleft == 4. >>> >>>I'm doing more in qsearch than you do. >>> >>>Further your verification search is using R=3 too with a bug in the hashtables >>>management. Because of that bug which is that you do not store in hashtables >>>whether a search result is based upon a verification or not, the worst case >>>performance of verification search is R=3. >> >>One of the reviewers of the article asked several questions regarding the use of >>hash tables in conjunction with verified null-move pruning. I told him exactly >>what I told you, i.e., the depth stored in the hash table is the depth after >>reduction (e.g., if we were in depth 6, have a fail-high report and reduce the >>depth to 5, then the final stored depth in the hash table is 5). That might be >>too conservative a method, but it guarantees that no hash table bugs (of the >>form you mention) are encountered. > >That is not fixing it at all of course. You need to write to hashtable for >*every* position that gets stored whether you did or did not do a verification. Conservative method means that when genesis use hash tables for pruning you can be sure that it already searched the same position for at least the same depth. Can you give an example for a position that was stored at depth X and is practically pruned instead of being searched to a bigger depth? Uri
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.