JBNielsen wrote:Sven Schüle wrote:
Is it possible that you store the distance to the root node instead of the remaining depth? That would explain why you think that "nullmoves involved in the line" play any role. The PV of a node will never contain a null move.
Sven
So the node(s) above the nullmove never contains a PV with the nullmove?! Hmmmm.
I do store the remaining depht. But as far as I remember I tried with several nullmoves in a line, and perhaps this is causing problems...
It might be worth to have a look at it again...
A PV never contains a null move since the null move is never the best move in a position, only "something like a move" that can be sufficient to refute the opponent's previous move. What you probably mean is the "current line", not the PV. A move can (should) only make it into the PV if searching it returns a value above alpha and below beta. If a null move causes a cutoff then its value is >= beta, otherwise you continue normal search and either obtain a PV from there or none at all. If you observe a PV containing a null move anywhere then something goes wrong.
Also the PV of a node is below the node, not above. That node can be part of its parent's PV, and even of the root node, but that is not what I was talking about. I mentioned the PV since it represents the result of searching a node to a given depth, together with the value returned. And you store that value, the best move (first move of PV) - if available - and some more data. Null moves can occur on the path from the root to that node but why do you care about them? It does not matter how you reach a node, you put information about a node itself into the hash table but not about any possible path to it. It is (also) about transpositions.
If your program has trouble with its hash table implementation and you believe it can be related to null moves then you should test both features separately:
a) disable null move pruning to look whether the problematic behaviour stays or disappears,
b) disable the hash table usage to look whether the null move implementation itself works correctly without it.
Usually it is an extremely rare case that a certain program bug occurs only with the combination of two different complex features. Most probably one of the two features themselves has a problem, or even both. That's my experience at least.
Sven