Author: Peter McKenzie
Date: 21:31:08 09/30/99
Go up one level in this thread
On September 30, 1999 at 21:56:17, Robert Hyatt wrote: >On September 30, 1999 at 18:11:50, Ed Schröder wrote: > >>On September 30, 1999 at 12:55:40, Robert Hyatt wrote: >> >>>On September 30, 1999 at 10:17:11, Dave Gomboc wrote: >>> >>>>On September 30, 1999 at 02:43:32, Jeremiah Penery wrote: >>>> >>>>>On September 29, 1999 at 19:43:43, Robert Hyatt wrote: >>>>> >>>>>>On September 29, 1999 at 19:21:08, Jeremiah Penery wrote: >>>>>> >>>>>>>Doesn't Rebel not use null-move? >>>>>>> >>>>>>>Jeremiah >>>>>> >>>>>> >>>>>>without the contraction: >>>>>> >>>>>> >>>>>>"does not Rebel not use null-move?" >>>>>> >>>>>>Damned if I know, as I can't parse that. :) >>>>>> >>>>>>But I do get your point... :) >>>>>> >>>>>>Bob >>>>> >>>>>:) >>>>>I originally intended to write something along the lines of "I don't think Rebel >>>>>uses null-move." I figured a question would be better, since I wasn't sure, but >>>>>I couldn't figure out how to phrase it correctly. :P >>>>>I revise: "I think Rebel doesn't use null-move. True?" :)) >>>>> >>>>>Jeremiah >>>> >>>>Ed has said here in the past that he doesn't use null-move. >>>> >>>>I think this was distinct from "doesn't use the null-move in the same way as >>>>e.g. Crafty does". >>>> >>>>Dave >>> >>> >>>No idea. Hiarcs doesn't use null-move like I do, but it definitely suffers from >>>problems with the "null-move observation" being used in some way. Ed has said >>>he does some threat extensions... they probably use the "null move observation" >>>as well.. in some fashion... >> >>No null-move in Rebel. Rebel's evaluation function is much to slow >>for null-move. Besides of that my evaluation function provides me >>so much data I don't need null-move. >> >>I tried null-move once and it gave me a speed-loss of 25%. >> >>Ed > > >Two things come to mind.... > >(1) I don't see how null move R=2 can possibly slow you down, unless you >implemented it in a different way than we are using. IE it only reduces the >depth on bogus branches... but doesn't incur any penalty unless you are already >doing some selective discarding of moves along the way and you suddenly can't >do this with null-move active... My take on this is that Ed is doing something similar (or somehow equivalent) to nullmove pruning using information derived from his evaluation function. For example, in the extreme case lets assume that the information from his evaluation function allows him to prune 100% of the lines that would be pruned by nullmove pruning. Adding nullmove pruning to such a program would merely add the cost of doing the nullmove search but without getting any benefits. Hence clearly a slowdown. Now its highly unlikely Ed's pruning has a 100% match with nullmove pruning, but the principle still applies. If his pruning prunes 90% of the lines pruned by nullmove pruning, then adding nullmove pruning would still probably result in a slowdown. > >(2) Crafty is pretty evaluation-heavy today... ie it is currently spending over >50% of the total search time in Evaluate() and children functions... and that >is in spite of lazy evaluation... yet null move speeds me up by a factor of >2 plies typically... Sure, but Crafty doesn't try to directly use information from the Evaluation for pruning... Peter
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.