concurring nullmoves (both colors) in subtrees?

[smrf]

Considering whether it would make sense to permit nullmoves for both sides within a subtree, I expect that then a lot of unwanted position repetitions would occur. Thus equal nodes would be evaluated by very different search levels. Thus I think it would be better to ban such concurring nullmoves by permitting nullmoves for one color side only inside of any subtree.

I have been told that there is a double nullmove heuristic intended for a better handling of zugzwang positions. But that seems to cause just a special case of such concurring nullmoves and thus doubling nodes at different plys.

Have there been already thoughts on that matter?

[bob]

Considering whether it would make sense to permit nullmoves for both sides within a subtree, I expect that then a lot of unwanted position repetitions would occur. Thus equal nodes would be evaluated by very different search levels. Thus I think it would be better to ban such concurring nullmoves by permitting nullmoves for one color side only inside of any subtree.

I have been told that there is a double nullmove heuristic intended for a better handling of zugzwang positions. But that seems to cause just a special case of such concurring nullmoves and thus doubling nodes at different plys.

Have there been already thoughts on that matter?

First, you can solve the draw problem if you set the 50 move counter to zero when you try a null-move, and you use this to limit how far you go back in the rep list.

However, I have tried that and it actually costs a couple of Elo. In thinking about it, terminating the search due to a repetition is not a bad event. The tree below a null-move is bogus anyway, and the quicker we "get out" the better.

Finally, I don't think your concern is something to lose sleep over. The sub-tree below a null-move is just another sub-tree. In many branches, the _other_ side could suddenly be winning, because so many moves in the tree are just outright blunders, and a null-move refutes blunders quicker than anything. I don't see why you would want to disable this quick refutation idea for one side, because the other side has previously tried a null earlier in the tree.

[smrf]

... The tree below a null-move is bogus anyway, and the quicker we "get out" the better. ...

Does this mean not to reuse or store node results within subtrees below nullmoves?

[bob]

... The tree below a null-move is bogus anyway, and the quicker we "get out" the better. ...

Does this mean not to reuse or store node results within subtrees below nullmoves?

No. I do exactly the opposite and do everything completely normally. Repetition checks. Hash probes and stores. Etc.