Author: Vincent Diepeveen
Date: 13:06:49 07/19/99
Go up one level in this thread
On July 19, 1999 at 13:41:37, Dave Gomboc wrote: >On July 19, 1999 at 06:14:45, Vincent Diepeveen wrote: > >>On July 19, 1999 at 00:14:28, Dave Gomboc wrote: >> >>>On July 18, 1999 at 21:11:20, Vincent Diepeveen wrote: >>> > >[snip] > >>>>That's not true, as in the worst case your window is a pawn off. >>>>So the first 5 researches are searching space which is completely useless, >>>>where in PVS the search overhead only depends upon move ordering. >>> >>>The more useless the search, the quicker it terminates. If you're a pawn off, a >>>cutoff should be extremely quick. Searches that are close to the proper value >>>take longer, precisely because they are searching space that is not "completely >>>useless", as you put it. And that effort will be caught in the hash table, so >>>you don't have to search it twice. >> >>That's not entirely true. >> >>a) it's overhead which PVS doesn't search > >mtd(f) searches minimal trees to prove what it needs to prove. PVS also has a >lot of overhead that mtd(f) doesn't search. You really eat that? >>b) you do not get it from hashtable as you search with a way lower bound >> next iteration, and then another lower research, where nullmove >> has the habit to give for alfa and beta scores back which are simply >> equal to alfa and beta. So you do need to research and can't >> use hashtable cheap >When the score doesn't move far, a ton of the re-search is in the hash table. >When it does, the first search didn't take very long anyway. Please reread what i wrote. Your assumption is not true. Score is namely far of. >[snip] > >Dave
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.