Author: Omid David Tabibi
Date: 17:49:28 11/23/02
Go up one level in this thread
On November 23, 2002 at 20:15:31, Alessandro Damiani wrote: >On November 23, 2002 at 13:42:06, Omid David Tabibi wrote: > >>On November 23, 2002 at 13:29:38, Martin Giepmans wrote: >> >>>On November 23, 2002 at 12:52:21, Omid David Tabibi wrote: >>> >>>>On November 23, 2002 at 11:37:25, Martin Giepmans wrote: >>>> >>>>>On November 23, 2002 at 08:48:36, Omid David Tabibi wrote: >>>>> >>>>>>On November 23, 2002 at 08:45:00, Uri Blass wrote: >>>>>> >>>>>>>On November 23, 2002 at 08:11:37, scott farrell wrote: >>>>>>> >>>>>>>>Just after other people's thoughts. >>>>>>>> >>>>>>>>I think Omid's work overlooked the adapative null move searching many of us do, >>>>>>>>ie. transitioning from r=3 to r=2. >>>>>>>> >>>>>>>>I think adaptive null move tries to GUESS where to use r=2 to reduce the errors >>>>>>>>that R=3 makes. I guess it depends on how often this GUESS is correct, the cost >>>>>>>>of the verification search, and how long it takes the adaptive searching to >>>>>>>>catch the error at the next ply. >>>>>>>> >>>>>>>>Has anyone looked at setting the verification search to reduced depth of 2 >>>>>>>>(rather than 1)? obviously to reduce the cost of the verification search. >>>>>>> >>>>>>>Omid checked it but you also reduce the gain. >>>>>>> >>>>>>>I think that I will look for good rules when to do the verification search so >>>>>>>the cost will be significantly smaller but the gain is going to be the same in >>>>>>>at least 99% of the cases. >>>>>>> >>>>>> >>>>>>I'm currently working on other variations. The initial results are promising. >>>>>> >>>>>>>Uri >>>>> >>>>>I have done some tests with your method at greater depths. >>>>>At depth 12 vrfd R=3 still had an overhead (in terms of treesize) of about >>>>>25% compared to pure R=3. >>>> >>>>Of course verified R=3 will *always* construct a larger tree than standard R=3. >>>>However, starting from a certain depth, it will always construct a smaller tree >>>>than standard R=2. >>>> >>>>Take note, that while verified R=3 constructs a slightly larger tree than >>>>standard R=3, it has a superior tactical strength to even R=2 ! >>>> >>>> >>>>> >>>>>(my engine uses a simple Q-search that shouldn't give problems here) >>>>> >>>>>So the question is if your expectation that the treesize of R=3 and vrfd R=3 >>>>>converge at greater depths (> 11) really holds. >>>>> >>>>>Needs more testing, I think. >>>>> >>>>>Another point: >>>>>I would expect that vrfd R=3 becomes less safe at greater depths. >>>>>The subtrees in which you don't verify nullmove (after the verification) become >>>>>deeper and I see no reason - on logical grounds - why this shouldn't give safety >>>>>problems. >>>>>Even if R=3 and vrfd R=3 converge in terms of treesize, the safety (or rather >>>>>the lack of it) might also converge ... >>>>> >>>> >>>>None will converge. >>> >>>That is what you hope. And hope is a good thing, for sure :) >>> >> >>That's what I hope? No, actually I would be happier if the tree size of vrfd R=3 >>and std R=3 would converge! But that is impossible, since verified R=3 has the >>verification overhead. >> >> >>>But how do you know? In your article there are no results for depths>11. >>> >> >>Look at Figure 4. The deeper you go, the larger becomes the difference between >>the tree size of vrfd R=3 and std R=2. >> >> >>>>However, the deeper you go, the smaller will be the difference in tree size, and the greater the difference in tactical strength. >>>> >>>Again, how do you know? >>> >> >>The "backbone" of verified null move pruning is R=3. So it is natural that the >>deeper you go, the size of the tree will be closer to standard R=3 than to >>standard R=2 (again see Figure 4). >> > >Or in other words, R=3 dominates the verification search. > Standard R=3 dominated verified R=3 in terms of tree size, but is far worse in terms of tactical strength, and thus a significantly inferior option. Omid. P.S. By saying "verification search" you refer only to the piece of code in charge of verification! Please refer to the algorithm as "verified null-move pruning". >Alessandro > > > > >>>Martin >>>> >>>>>In any case, thanks for sharing. >>>>> >>>>>Martin
This page took 0 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.