Author: Stan Arts
Date: 13:06:58 03/23/04
Go up one level in this thread
>Hi Stan, > > Since I tried to add aspiration search I've found so many problems, that I >don't know where to start (and they all disappear as soon as I disable the >aspiration). > I've just detected a silly one: Searching at fixed depth 1, my program takes a >pawn with a knight, and gives a positive score. Well, after a few captures it >can be seen that the capture was a very bad idea. The first thing I thought was >that I had a bug in my quiescent search, but I didn't: Qsearch called without a >tiny alpha-beta window returns a big negative score. This is what happened: > > The root tried first a capture, it turned out to be bad (-3.26), and alpha is >set at -3.26 (alpha=-INFINITE, beta=INFINITE initially). The second move was >tried, and search was called with a small window around -3.26 (alpha-326, >beta=-325). The problem here is that due to this values for alpha and beta, one >of the captures in the quiscent search is found to be futile (doesn't reach >alpha after capturing), and it stops before completing the full sequence where >it finally looses. > PROBLEM: Qsearch returns a false value, and it is stored in the hash as an >"Exact" value (+0.24). This value fails high (-3.27,-3.25), so a research is >done with a wider windows. But now there is a hash match with +0.24!, so Qsearch >is never called. The result: +0.24. This would have never happened without hash >tables... or with tables but without aspiration. > How to fix this mess? > Thank you, > > Jaime Do you have some margin in the Qsearch to include captures that bring the score within some margin to alpha? If not, you'll need that to, for instance, include captures that could have a high positional value. (for instance passed pawns, or attacking pieces or so) If you measure when a capture is futile in Qsearch with just the material scores of pieces, you'll need such a buffer, because a capture could be worth more then it's "normal" material value. And you could choose the size of that buffer for instance by seeing how much change in positional score you could get from the evaluationfunction with a single capture. Incase you use PVS or any other type of narrow-window search in the tree, does the quiescent search work correctly then? Then, how can a value of 0.24 be stored as "exact" , when you have a window of -326 to -325? If you got back a value of 0.24, that score is not exact, but is above the alpha-beta window, so it's an upper bound, and when you research, and you got that 0.24 to the root as score, you'll have a window that includes 0.24 between alpha and beta, then you have no hashtable value to use there, as the 0.24 was not previously stored as an exact value. Or, if you mean storing that 0.24 at some depth of Qsearch, and later retrieving that 0.24 in Qsearch, again that first time the 0.24 wasn't an exact score. Humm, or if you search the first move with -infite to +infinite, the Qsearch can not give the false score, so the exact scores it stores with that first move, should be correct? Then it seems the score was stored wrong. Tried to name a few things, and hope any of them will be of help. Stan
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.