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