Author: Vincent Diepeveen
Date: 19:42:50 11/21/02
Go up one level in this thread
On November 21, 2002 at 22:08:22, Uri Blass wrote: >On November 21, 2002 at 22:00:21, Vincent Diepeveen wrote: > >>On November 21, 2002 at 21:43:46, Uri Blass wrote: >> >>>On November 21, 2002 at 21:38:43, Vincent Diepeveen wrote: >>> >>>>On November 20, 2002 at 16:55:41, Gian-Carlo Pascutto wrote: >>>> >>>>Of course it doesn't work for you. you compare searchtimes >>>>with each other. In his article he compares search depths with >>>>each other. He claims 10 ply fullwidth is better finding >>>>a bit more at testsets than 10 ply >>>>with nullmove for tactical reasons, >>>>forgetting to tell of course what time it takes to get it. >>>> >>>>You are comparing search depths which is correct. He isn't. >>>>See his article. >>> >>>He also did games and at least it was clearly superior in games relative to R=2. >>>It may be interesting to find out if it is also superior in games relative to >>>R=3 or relative to other algorithms. >>> >>>Uri >> >>It means his implementation of nullmove has a bug obviously. >> >>Also his 50% figure is wrong. He claims that R=3 always is >>outperforming his algorithm only by factor 2. >> >>That is wrong. It should not be factor 2. It should be several >>plies of course. And default R=2 also should outperform (timewise) >>his algorithm bigtime. His tests don't show it. >> >>It is trivial that a reduction of 1 ply is going to be more expensive >>than a nullmove reduction of R=2 + 1 = 3 ply. >> >>Do you see that too? > >No > >I see that after the first reduction of 1 ply you have a recursive null move >pruning with no 1 ply reductions. > >I do not see a recursive null move pruning with no 1 ply reduction in part of >the tree with R=2. > >I think that you should apologize for always assuming that other people have >bugs. No he has *major* bugs in his program. Normal nullmove r=2 ==> with a tree of R=2+1=3 ply reduction you give a cutoff. He's doing also a nullmove after that a search of 1 ply reduction. So if we assume a depth of 10 ply left, then the R=2 nullmove search reduces to 7 ply. That 7 ply search cutoffs. That's it. Omid is doing a nullmove also but after that he reduces 1 ply. 10 ply minus 1 = 9 ply. So he is claiming in his article that a 9 ply search is more efficient than a 7 ply search. That's not true of course. It can only be explained by bugs in his program. For example that he doesn't catch a hashtable probe or something which was already based upon a reduced depth and now again gets reduced ==> FHR bug problem. Or some bug in nullmove. >Uri
This page took 0.01 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.