hash table destroys my search

[Pierre Bokma]

Hi

My hash table is giving problems. In my search (not at root level) i have the following line of code:

beta=min(beta,hashtable.beta)

basically the value of beta is adjusted to the value found in the hashtable if the hash table entry contains an UBOUND.

This line give problems at root level as it sometimes has the effect of finding the wrong move in the root: a move is choosen apparently without any search with a pv length of 1 even if depth > 2.

i have seen my engine make serious blunders due to this line.
The problem is gone when this line is commented out.

anybody have an idea how to solve this problem

thanks !

[Sven]

I do the same narrowing of the window and encounter no problems. Do you probe the hash table at the root node? I don't, and if you do then you might consider to try not probing there.

EDIT: I see you wrote "not at root level", so I can assume you don't probe at the root node.

I do this narrowing of beta only in case the stored draft was sufficient but the hash table score turned out to be > alpha, so that the TT lookup did not return a value useful for TT cutoff.

Sven

[Joost Buijs]

Maybe the problem is that you use the Upperbound instead of the Lowerbound when adjusting beta.
Normally Ubound <= alpha and Lbound >= beta.
Maybe it's the other way around in your engine, I don't know.

[hgm]

beta=min(beta,hashtable.beta)

basically the value of beta is adjusted to the value found in the hashtable if the hash table entry contains an UBOUND.

I don't get it. What is this new beta supposed to be used for? Are you going to do a re-search on moves that exceed this beta later on, in PVS style? In PVS this would only apply in PV nodes, as other nodes are searched with null window, and having the ubound < beta would also mean it is <= alpha, so you could take an immediate hash cut.

[Sven]

Maybe the problem is that you use the Upperbound instead of the Lowerbound when adjusting beta.
Normally Ubound <= alpha and Lbound >= beta.
Maybe it's the other way around in your engine, I don't know.

If the TT entry contains a value V with the type "upper bound" then it means that the search that stored this value was failing low and returned the information "the value is <= V". If looking up this TT entry at a later time does not lead to a TT cutoff then you may still have a chance to use this information to narrow the alpha-beta window. This would be the case if the stored value V were lower than "beta" of your current search. In that case you would combine existing information as follows:
- the TT holds a value V that is < beta for my current position;
- the TT further says that V was an upper bound;
- so I could change my beta to V.

I had found that idea on the Bruce Moreland pages if I remember correctly. I think it is theoretically sound but I have no "formal proof" available for it.

The same can be done on the "alpha" side of the window if V is a lower bound (alpha := Max(alpha, V) ).

There may be conditions where this does not work, I don't know.

Sven

[lucasart]

IMO updating the bounds with htable entries at PV nodes (not only the root) is dangerous for two reasons:
1/ search inconsistencies
2/ you don't use exact depth match but certainly tt.depth >= depth

[Joost Buijs]

If the TT entry contains a value V with the type "upper bound" then it means that the search that stored this value was failing low and returned the information "the value is <= V". If looking up this TT entry at a later time does not lead to a TT cutoff then you may still have a chance to use this information to narrow the alpha-beta window. This would be the case if the stored value V were lower than "beta" of your current search. In that case you would combine existing information as follows:
- the TT holds a value V that is < beta for my current position;
- the TT further says that V was an upper bound;
- so I could change my beta to V.

Yes I guess you are right, I didn't think about it that much.
I don't use it in my engine, but maybe it's something to try.
It probably gives a little reduction in nodes searched.

[hgm]

- the TT holds a value V that is < beta for my current position;
- the TT further says that V was an upper bound;
- so I could change my beta to V.

But when one of the moves on search then returns a value larger than the TT.beta, but smaller than the original beta, you would take a beta cutoff when there really isn't one. That usually leads to arbitrarily large blunders.