Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: MTD concept and why PVS is superior

Author: Bo Persson

Date: 14:16:45 06/23/05

Go up one level in this thread


On June 22, 2005 at 19:39:43, Robert Hyatt wrote:

>On June 22, 2005 at 17:15:13, Bo Persson wrote:
>
>>On June 22, 2005 at 10:01:12, Vincent Diepeveen wrote:
>>
>>>On June 21, 2005 at 16:11:50, Bo Persson wrote:
>>>
>>>>On June 20, 2005 at 08:06:08, Vincent Diepeveen wrote:
>>>>
>>>>>
>>>>>If at 13 ply the score of other moves is 0.35 or so and from this root move it's
>>>>>0.400, then we have a 100 point difference between 0.300 and 0.400.
>>>>>
>>>>>Now we need possibly a 100 researches to get to 0.400, but at least 2 dozen or
>>>>>so. As we will use bounds 0.300 0.301 0.302 0.303 0.304, hoping that the score
>>>>>is close to 0.300 of iteration 12 of course.
>>>>>
>>>>>PVS is far superior in this as we can determine the true bound directly by
>>>>>taking the tree of 12 ply search depth. We add 1 ply to it and we already have a
>>>>>root score of real close to 0.400 to it. So for the price of a node or 50 using
>>>>>hashtables we directly determine a true bound or somethign real close to the
>>>>>true bound, where MTD needs 20+ researches for.
>>>>>
>>>>>Is my point clear now?
>>>>
>>>>This is the usual Vincent thing - he can't get it to work, so it just doesn't
>>>>work.
>>>>
>>>>Who said you had to add 1 millipawn for each research? You can accellerate the
>>>>step (+16, +32, +64, etc), until you step over the target, and then zoom in
>>>>again.
>>>>
>>>>To go from 0.300 to 0.400, my program tries this series:
>>>>
>>>>0.300 0.316 0.348 0.412 (fail low!) 0.380 0.396 0.404 0.400
>>>>
>>>>That's eight (8) searches, not 100, not even 20+ !
>>>
>>>>Bo Persson
>>>
>>>By not using step 1 initially you remove all advantages that MTD *might* offer.
>>
>>No.
>>
>>If the final score would actually be 0.301, I would go
>>
>>0.300 0.316 0.308 0.304 0.302 0.301
>>
>>That's 6 null window searches. Not bad.
>>
>>Of course, if the new score just happened to be 0.316, I would find it really
>>fast!
>>
>>Why optimize for the 0.300 -> 0.301 case? Is that very frequent in your program?
>>
>>
>>Bo Persson
>
>
>This is a hopeless argument of course.  The main problem I had in fooling with
>this was "lazy eval" caused way too many problems.  Don D. suggested a fix that
>seemed reasonable later, but you don't want to let lazy eval trick you into
>failing the wrong direction just because the eval says <X or >Y and returning a
>bound that is too far off...


Was it Don D. that suggested using the root window as global upper and lower
bounds? That works pretty well for me.

My objections were against Vincent suggesting that you need 100 iterations to
move 100 eval points. That's just plain wrong. You might need more like 6-8
iterations, some of which are mostly very fast hash table lookups. With some
luck, you can sometimes get away with fewer iterations, if you happen to step
close to the final score.


Bo Persson




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.