Author: Tony Werten
Date: 10:14:43 12/18/02
Go up one level in this thread
On December 18, 2002 at 11:15:01, Omid David Tabibi wrote: > >Of course. If you try to implement it on XiniX, or GCP on Sjeng, or Uri on >Movei, then you certainly care about fixed time. But if I want to present the >data in a generic manner, I have to persent them in the most hardware/software >independant way I can. > >I further don't understand why all the fire is directed at me; It isn't. >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 think it has more to do with the same person insisting on fixed depth test results ? If so then it's not strange that an outdated test setup is choosen. Tony > >Omid. > > >>Tony >> >>> >>>1) The amount of time taken to process a leaf node may very well be less than >>>the amount of time taken to process an interior node (not including its >>>children, of course). So if the tree shape changes, it is possible that it >>>could take longer to search a smaller tree. Unless that is ruled out, all that >>>has been proven is that VR=3 works in fewer nodes. That is pretty interesting, >>>but I think it makes a stronger case if *time* is used as well, so we will know >>>that there is at least one real case where this technique makes the program >>>faster. >>> >>>2) The amount of nodes traversed to get through ply 10, with R=3, is about 60% >>>of the number taken to get through ply 10 with VR=3. It can be assumed (perhaps >>>wrongly, due to my previous point) that this search takes 60% as long. The >>>number of solutions found by R=3 is fewer than with VR=3, granted. But what is >>>the R=3 version doing while the other version is trying to finish up ply 10? It >>>is going on to ply 11. How many solutions has it found in ply 11 before VR=3 >>>has finished ply 10? In this case, 65 is sufficiently less than 71 that the >>>answer is probably less then 71. But maybe not! >>> >>>It seems likely that VR=3 is tactically faster than R=3, but I cannot know for >>>sure, since the results have not been reported! We do not know if VR=3 is >>>tactically *faster* than R=3. Isn't that an important point, since all of us >>>who read this article are wondering if we can stick this in our own programs and >>>obtain benefit? >>> >>>I have seen people report results like this forever. I wish that they would use >>>a the more sensible method of reporting number of solutions found correct in a >>>certain amount of *time*, since that is the true measure of tactical speed. >>> >>>Nothing personal, Omid. >>> >>>I'm trying to verify your results by using ECM with Gerbil. First I have to get >>>good numbers for R=2 and R=3. >>> >>>By the way, if anyone wants to take Gerbil and use it as a second example when >>>writing articles like this, I'm all for it. It's simple so it should be pretty >>>easy to modify. >>> >>>bruce
This page took 0.18 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.