Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Building the Principal Variation in MTD(f) searches

Author: Dave Gomboc

Date: 10:41:37 07/19/99

Go up one level in this thread


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.

>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.

[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.