Author: Heiner Marxen
Date: 09:17:09 06/06/99
Go up one level in this thread
On June 04, 1999 at 15:05:46, blass uri wrote: >On June 04, 1999 at 14:22:24, Heiner Marxen wrote: > >>While I agree that "null move" is a good thing, there is >>one disadvantage: it is sometimes wrong, especially in >>zugzwang positions. This *can* be a problem, although rarely. >> >>I wonder whether this disadvantage can be corrected such, >>that the speed advantage is not given up, but at least >>at greater depths the error is detected/corrected. >> >>My idea: when doing a null move search with depth-R does >>produce a beta cutoff, (and depth-R is large enough,) >>verify the result by another search with depth-R-1 (say), >>with null move suppressed at the top of that search. >>The additional search is reduced in depth, again, >>and hence should not cost more than the null move search >>itself. And to some extent we would now be more sure, >>that there really exists a legal move which is good >>enough. And with more depth this would become more accurate. >> >>Is this possible? Or meaningless? > >It is possible but I think that if the program is slowed down by a factor of 2 >or 1.5 then the program is going to be weaker in games because zungwangs are >rare. I agree. A slow down factor 1.5 would be too much. But then, I would expect my idea to produce a much nicer slow down factor, if done right. Since I'm not an active chess programmer I have not much chance to test it by myself and deliberately left out all details. What constitutes "done right" is open to discussion. >I think that it is possible to avoid stupid null move mistakes like not seeing >mate in 2 without doing the peogram weaker. > >one simple idea is to use the first 1% of your time for comparing between the >evaluation with null move and without null move. > >If you find a big difference in the evaluation then do not use null move in the >search and otherwise use null move. Interesting idea. But I see problems in making that work: First, how do you measure the difference in the presence of a transposition table (TT), which carrys evaluations from one branch to another etc? At least TT entries would need to be marked whether they are constructed with or without null move. Second, I don't like the idea to turn off null move for complete trees, since it *is* very good, and most of the time produces better results due to the increased depth it reaches. I'd rather turn off null move exactly where it *is* going wrong, and keep the others. >The program is going to be slowed down by less than 1% but it is going to avoid >stupid blunders that make the users angry. > >I think that if the time that you use for comparing between evaluation with >null move and evaluation without null move is small enough and the time for >all game is big enough then the program is going to be slightly stronger in >games. I want to check for the validity of the null move assumption (aka there is a legal move at least as good as the null move), using not more additional time than 1% (say). And to achieve this I propose to use another search with an even more reduced depth. And since this additional search is done to check the null move validity at the top, it must not rely on it, itself. How much more the depth of the additional move is reduced, is open. This is how we may reduce the additional cost to that fraction, which we want to tolerate. May be, we can even play with the a/b bounds, here. >Uri Heiner
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.