Page 1 of 1

null move

Posted: Fri Apr 14, 2017 8:51 am
by flok
Hi,

I think I may have a new idea (but someone else probably tried it before): storing a bit in the tt which indicates if null move should be done in this node or not. E.g. when score != exact and null move did not cause a cut-off, then set the bit in the tt so that for a next time we know null move is not required.
It gave embla a 16 elo improvement (44k games played).

Re: null move

Posted: Fri Apr 14, 2017 9:42 am
by Desperado
Hi.

It is a good idea especially if it is tested and works well. The idea is already known for a long time but of course it feels very good to invent some features by your own. Congrats. :)

Re: null move

Posted: Fri Apr 14, 2017 9:45 am
by hgm
In many cases you can already see that from the fact that the TT entry specifies a hash move. As null move would be searched before any real move, the fact that the previous visit of the node did search a real move (and found it to score above alpha) implies that the null move must have failed low. That suggests you can skip the null move search if you have a hash move.

If the previous visit of the node failed low (i.e. TT score is an upper bound), this also implies that the null move must have failed low. If the TT score is a lower bound, but there is no hash move, this implies the node must have failed high through a null move. (Or a stand pat, when the depth was <= 0.)

The question of course is that when a null move failed low at depth=d, how large is the probability that it will also fail low at depth=d+1. This will also depend on whether you do null move only when the current evaluation is above beta. And it also depends on whether the search window changed. In a null move failed low the previous time when beta = 100cP, and you now revisit the position for the next highest depth, but with beta = 0cP, you suddenly have a much better chance that the null move would work this time. The true score after null move could be 50cP, after all.