Author: Vincent Diepeveen
Date: 14:05:54 04/14/03
Go up one level in this thread
On April 13, 2003 at 10:22:25, Uri Blass wrote: >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? this is trivial. first do a at a big depth a verification. then verification = false. We make a few nonsense moves. Now we get to position P depth == 2 for example. P delivers a cutoff by nullmove. However, opponent has unavoidable threat to put a queen near my king which threatens my kingsafety. I don't extend that but might give it +25 pawns bonus. That gets stored in hashtable now incorrectly as >= beta. Now we do again a search the same way but by other moves. Forcing moves in fact. So no verification has occured yet. We get to position P by transposition in short. Depthleft == 2. Hashtable gives incorrectly transposition now. End of proof. It should not give transposition as it should see in hashtable that the position was stored with verification = off and recognize now that verification == on now. You could even further optimize it than that, but that is not relevant here. >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.