aspiration search problem: research within original window

[Pierre Bokma]

hi friends

i have been fighting all weekend with a search problem (i explained in my previous post). The aspiration search is not working properly.

int the root the first move is searched with an aspiration window of about half a pawn around the value of the best move at the previous search depth. if the value of this search is outside the aspiration window the move is researched with a completely open window (-INF,INF).

The strange thing is that i often see the aspiration search returning a score > beta while the research returns a score within the original aspiration window. Is this normal or is that a mistake. The problem is that sometimes a pv length of one results.

for testing purposes i have turned evering thing out, so no hashtable, no nullmove etc.

hope anybody van hop

regard
Pierre

[micron]

It's called search instability.
http://chessprogramming.wikispaces.com/ ... nstability

Robert P.

[tpetzke]

I encountered something similar with the zero window verification

http://talkchess.com/forum/viewtopic.ph ... ht=#410771

It seems there is nothing you can do about it. Using a fail hard framework is supposed to help a bit, but it will not eliminate it.

Thomas...

[Pierre Bokma]

thanks for the reply so far.

i guess it is normal behaviour but still i consider it strange. i have put everything fnacing off in my search so the engine does a full with search in each node, no hash table, no null move, only alpha beta. And it does not happen every once in while but regulary.

regards Pierre

[tpetzke]

yes it is ugly. I came for my self to the following explanation, might be a silly one

If you search a move with a small window you might find a move with a score that falls out of the window, so you do a research with a full window.

Maybe in one of the explored nodes a move that caused a beta cutoff in the (small window search) is not able to cause a beta cutoff anymore (and maybe none of the moves here is able to do that) but one of the moves raises the score just a bit above alpha, so the pv changes. This can have the effect that another part of the search tree is now explored and this gives a score at the end that would fit in the original small window.

Thomas...

[kbhearn]

it does sound kinda like you have a bug. any dynamic move ordering / reductions left in your search? Any random/dynamic terms in your eval? A pure alpha beta with deterministic eval and no hash table shouldn't show instabilities.

[hgm]

i guess it is normal behaviour but still i consider it strange. i have put everything fnacing off in my search so the engine does a full with search in each node, no hash table, no null move, only alpha beta. And it does not happen every once in while but regulary.

This is a bug for sure. Without hash table, LMR and null move (and other window-dependent pruning such as futility) you should have no search instability, and any bound should be a hard bound that can never be violated by a re-search to the same depth with another window.

So better track the bug first, and fix it. But after that, when real life starts again (with hash table etc.) you'd better learn the program to live with the instability as well.

[Pierre Bokma]

thanks guys,

i have completely rewritten my search and removed futility pruning in qsearch aswell. (i forgot). now this problem is gone but now the value of the first move is often taken directly form the hash table resulting in a one ply pv.

any solution for this problem?

regards

[tpetzke]

You do look whether the entry in the hash table has enough draft to be used for pruning, don't you ???

It's normal that the value of the root position is found in the hash table (when you do IID at least) but usually its draft is not enough as it is the result of a shallower search.

If you find an entry with enough draft, because of deeper previous searches, you can use it. It's fine and the PV can still be retrieved from the hash table (unless you had a collision along the way).

Thomas...

[Sven]

thanks guys,

i have completely rewritten my search and removed futility pruning in qsearch aswell. (i forgot). now this problem is gone but now the value of the first move is often taken directly form the hash table resulting in a one ply pv.

any solution for this problem?

regards

You could reconstruct the full PV (or at least a longer one) from the TT right before printing it. But take care to check legality of each hash move you find when following that path, and of course to unmake these moves again when you're done

@Thomas: I think Pierre did not mean that the value of the root position is found but the value of the position after the first move. Nevertheless your remark applies in general, too.

Sven