Author: Vincent Diepeveen
Date: 21:04:33 11/21/02
Go up one level in this thread
On November 21, 2002 at 16:57:34, Tony Werten wrote: >On November 21, 2002 at 16:16:49, Robert Hyatt wrote: > >>On November 21, 2002 at 14:35:54, Tony Werten wrote: >> >>>On November 21, 2002 at 14:33:28, Tony Werten wrote: >>> >>>>On November 20, 2002 at 19:09:01, Omid David Tabibi wrote: >>>> >>>>>On November 20, 2002 at 19:02:49, Gian-Carlo Pascutto wrote: >>>>> >>>>>>On November 20, 2002 at 18:54:30, Omid David Tabibi wrote: >>>>>> >>>>>>>>Could you please compare (Adptv + small quiesc) vs (Vrfd +small quiesc) ? >>>>>> >>>>>>When I have more time. >>>>>> >>>>>>If you want more data, I expect others will post results >>>>>>from their programs as well. Maybe those are more encouraging... >>>>>> >>>>>>>BTW, please allocate more time for each position. The deeper you go, the >greater will be the advantage of verified null-move (see Figure 4 of my >>>>>>>article). >>>>>> >>>>>>Compared to R=2! But it scales inferior to R=3. So I don't expect >>>>>>more time to give it an advantage compared to Heinz Adaptive Nullmove. >>>>>> >>>>>>>Or you might want to conduct a test to a fixed depth of 10 plies, and then >>>>>>>compare the total node count and number of solved positions. >>>>>> >>>>>>Fixed depth tests are nonsense. I play games with a clock, not with >>>>>>a fixed amount of plies. >>>>>> >>>>> >>>>>One comparison method once I thought of, was letting each algorithm search as >>>>>much as it wants until it solves the position. Then compare the total node >>>>>counts of different algorithms. While this is a good practical test, I think the >>>>>academics will still appreciate the classical fixed depth comparisons...! >>>> >>>>The academics are wrong here. Think about it. >>>> >>>>Your program finds the wrong move twice as fast, is that an improvement ? >>>>Your program finds the right move twice as slow as it found the wrong move >>>>before, is that worse ? >>> >>>In addition, the academic way would be that an algoritm that prunes all moves >>>and returns 0 is an improvement. >> >>I think the idea of "one size fits all" is flawed. I much prefer to measure the >>same >>thing different ways, so that I understand what is going on better. A single >>point is >>just a point. Two points give a line. Three or more define a surface. Each of >>which >>reveals more about what I am looking at than the previous case did... > >Agreed, but in this case, time to solution is missing, wich is imo the most >important one. > >Tony also calculate the branching factor of his thing. 6.9 for R=1 3.1 for R=2 3.2 for R=3 and for his verification search it is 3.2 There is something dead wrong in that program. Also 4.3 million nodes on *average* he needs to finish a 9 ply search with R=2. That's *huge*. With R=1, which *does* give a 2 ply reduction for nodes that fail high, he need 80 million nodes on average to finish a 10 ply search for each position. That's *huge* number of nodes to search to a small depth :) >> >>> >>>> >>>>Tony >>>> >>>>> >>>>> >>>>> >>>>>>-- >>>>>>GCP
This page took 0.01 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.