True iterative search...

[syzygy]

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...

Several nullmoves in a line should be fine, but you might want to forbid two consecutive nullmoves.

I suppose nullmoves can add some inconsistency to hash tables (as most other selective search techniques), but hash tables also add inconsistency to the search. This is not something to be too worried about. If null move is really not working for you at all, there is probably a bug somewhere.

[Sven]

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

[Sven]

you might want to forbid two consecutive nullmoves.

Wait until Vincent comes here ...

[syzygy]

you might want to forbid two consecutive nullmoves.

Wait until Vincent comes here ...

I know, and I wanted to add that double nullmove can be OK if you know what you're doing and you're not allowing triple nullmoves. But Vincent might agree that it's best to start simple

[hgm]

I don't think triple null moves do much damage. Null moves that fail low do not affect anything, except that they wasted a little time. And two consecutive moves cannot both fail high. So the third null move will never resort in any effect. And by the time you are there, three null-move reductions will have shrunk the sub-tree to negligibly small size.

If you do the hash probe after the null move, multiple null moves can even be useful; they povide implicit IID.

[Karlo Bala]

I don't think triple null moves do much damage. Null moves that fail low do not affect anything, except that they wasted a little time. And two consecutive moves cannot both fail high. So the third null move will never resort in any effect. And by the time you are there, three null-move reductions will have shrunk the sub-tree to negligibly small size.

If you do the hash probe after the null move, multiple null moves can even be useful; they povide implicit IID.

I guess it depends on the implementation.

http://www.stmintz.com/ccc/index.php?id=241028
http://www.stmintz.com/ccc/index.php?id=240377

[syzygy]

I don't think triple null moves do much damage. Null moves that fail low do not affect anything, except that they wasted a little time. And two consecutive moves cannot both fail high. So the third null move will never resort in any effect. And by the time you are there, three null-move reductions will have shrunk the sub-tree to negligibly small size.

The effect of the third null move is to negate the zugzwang-detection capability of the second null move, which was the reason for allowing the second.

If you do the hash probe after the null move, multiple null moves can even be useful; they povide implicit IID.

Hash probe after null move doesn't seem like a particularly good idea.