Computer Chess Club Archives


Search

Terms

Messages

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

Author: Dave Gomboc

Date: 21:14:28 07/18/99

Go up one level in this thread


On July 18, 1999 at 21:11:20, Vincent Diepeveen wrote:

>On July 18, 1999 at 17:14:17, Dave Gomboc wrote:
>
>>On July 18, 1999 at 14:22:14, Vincent Diepeveen wrote:
>>
>>>On July 18, 1999 at 14:10:03, Andrew Williams wrote:
>>>
>>>>In PostModernist's case it would search 1.03, then 1.02, then 0.98, then
>>>>0.89, then 0.73, then 0.48. It would then start to work its way back up,
>>>>0.48, 0.49, 0.51, 0.54 etc.
>>>
>>>>So in this example, PM needs a lot of re-searches, but it's not just to
>>>>do with the gap between the iteration scores - for example, going from 1.03
>>>>down to 0.48 would be considerably faster than going from 1.03 to 0.72,
>>>>because of where the scores lie and because of my approach to traversing
>>>>gaps.
>>>
>>>The idea of having more than 1 research is laughable.
>>>Now you can of course make a statement that the overhead
>>>isn't *that* high, which is more or less true, but still...
>
>>You're forgetting that the searches all cost far less than a PVS search.  You
>>can sum the total time of 6 researches compared with a PVS implementation, and
>>the mtd(f) will still be faster more often than not.
>
>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.

Your choice to ignore hash results from deeper searches than the one you are
currently performing will kill mtd(f).  I previously assumed that you had
disabled this "feature" when testing mtd(f), but it occurs to me that you might
not have.  If not, no wonder you get crappy results.

>>If you tried mtd(f) with a serious effort and could not get it to work better
>>than horribly, my guess would be that the stepping algorithm you used for
>>researches probably was not up to the task.
>
>If you have to step a lot, which is logical as my evaluation ain't dumb,
>then it's quite logical that you search more nonsense, which makes it
>perform bad.

You have to search a tremendous amount of nonsense to make it perform "bad".  (I
am interpreting "bad" to mean >5% slower that PVS.)  mtd(f) isn't always faster
than PVS, but averaged over many positions it should be.

Dave



This page took 0.01 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.