Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Proving something is better

Author: Omid David Tabibi

Date: 12:58:09 12/18/02

Go up one level in this thread


On December 18, 2002 at 15:49:14, Uri Blass wrote:

>On December 18, 2002 at 15:43:56, Omid David Tabibi wrote:
>
>>On December 18, 2002 at 14:31:21, Bruce Moreland wrote:
>>
>>>On December 18, 2002 at 11:29:37, Omid David Tabibi wrote:
>>>
>>>>On December 18, 2002 at 11:23:38, Gian-Carlo Pascutto wrote:
>>>>
>>>>>On December 18, 2002 at 11:15:01, Omid David Tabibi wrote:
>>>>>
>>>>>>I further don't understand why all the fire is directed at me; fixed depth
>>>>>>comparisons are the common accepted comparison methods, which are completely
>>>>>>hardware independant.
>>>>>>
>>>>>>For the most recent examples take a look at Heinz and Plaat's numerous >articles, all of which were conducted in fixed depth.
>>>>>
>>>>>I would think that the best research is the one that improves upon
>>>>>the mistakes of previous ones.
>>>>>
>>>>
>>>>I am yet to be convinced that the methodology practiced by Hyatt, Schaeffer,
>>>>Marsland, Buro, Plaat, Heinz, and others, is mistake.
>>>
>>>I have complaint with how this is applied, sometimes.
>>>
>>>One type of test involves making the tree smaller, period, while doing the same
>>>kinds of work.  If Schaeffer is going to test the history heuristic, that's
>>>great -- if the tree is smaller, it's a win, because if you can consistently do
>>>the *same* stuff in fewer nodes, that's always good.
>>>
>>>The only possible criticism I can have of something like this is if it doesn't
>>>use enough test positions.
>>>
>>>If you are trying to prove that something sees more, what does seeing more mean?
>>> You can blow the tree size up by extending everywhere, and you will see more in
>>>a given depth.  But depth is not the proper measure, since a larger tree size
>>>will also take more time to search.
>>>
>>>If you want to "improve" a chess program in this manner, just incorporate a
>>>two-ply search into your eval function.  You'll find stuff two plies sooner.
>>>
>>>The only reason that your experiment shows that VR=3 is better than R=2 is that
>>>the solution set was bigger *and* the node counts were smaller.  You can
>>>*assume* from that that the times are also reduced.
>>>
>>>You can't make these assumptions about R=3 as compared with VR=3.
>>>And for that
>>>matter, you can't make them about R=3 as compared with R=2, given the data you
>>>present.
>>>
>>>Your data strongly implies that R=3 is better than R=2.  That is disturbing,
>>
>>
>>>since your paper regards the superiority of R=2 over R=3 as axiomatic.
>>
>>I didn't intend to reinvent the cycle. It has already been shown elsewhere that
>>std R=2 is superior to std R=3.
>
>if std R=2 is superior to std R=3 for program X when  VR=3 is superior to std
>R=2 for program Y then it does not prove superiority of  VR=3 to std R=3
>
>I believe that R=2 is not superior to R=3 for Genesis and I remember that even
>before the article you claimed that R=3 is better than R=2 for genesis at long
>time control.
>

No, I claimed that for longer time controls the superiority of std R=2 over std
R=3 is not that significant. But I never said that std R=3 is better than std
R=2 under any time control.

>Uri



This page took 0.09 seconds to execute

Last modified: Thu, 07 Jul 11 08:48:38 -0700

Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.