Author: Vincent Diepeveen
Date: 03:14:45 07/19/99
Go up one level in this thread
On July 19, 1999 at 00:14:28, Dave Gomboc wrote:
>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.
That's not entirely true.
a) it's overhead which PVS 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
>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.
I'm quite positive my 8 probe hashtable works excellent.
I'm quite sure i investigated MTD very well.
So what are we talking about?
i give 2 reasons why MTD sucks bigtime for my program namely:
- it searches space PVS doesn't search; called overhead
- it's worst case behaviour is simply losing games for me,
as in *some* positions where it's already tough to search with PVS
it is only busy researching and researching to get a bound.
The only thing you say then is that i'm not using hashtables?
Comon drop dead.
>>>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 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.