Author: Dieter Buerssner
Date: 08:22:14 01/05/01
Go up one level in this thread
On January 05, 2001 at 10:23:26, Gian-Carlo Pascutto wrote: [fail high and then fail low for the same move, and the other way around] >Since this happens a lot in my program, I spent some time tracking down >what were the minimal conditions: > >- aspiration window (no fail high/low otherwise) >- null move >- hash table used for move ordering (not for scores, not even on exact matches) > >Now it still isn't making sense to me...how can you produce a different >_score_ anywhere in the tree by just altering move ordering?? > >Anybody who knows an explanation here? 'You _must_ have a bug' is acceptable >too. I think, this can still happen, when you use pruning techniques, that depend on the window. On such technique is null move. Perhaps with beta 1.0 the null move will fail high. With 1.1 it won't fail high anymore. You would no assume, that later in the "normal" search, you get a score >= 1.0. But this might not be the case, because actually the null move refutation would have been wrong for 1.0 allready (perhaps because of some slight Zugzwang). The window, with which a position is searched, can depend on the sorting of the moves (not only at the root). Also, when extensions depend on the window, such artifacts can arise. Regards, Dieter
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.