Criteria for Null Move Pruning

[YumYum]

After reading many posts here about Null Move Pruning and following up with various other resources I have implemented Null Move Pruning in my engine. The code is very much in prototype form (ugly and inefficient) but the results have been remarkable so I'm looking at refining it and making it a permanent fixture.

My reading did lead to a number of criteria being suggested for when to apply NMP. I'd really appreciate the thoughts of those more experienced with NMP as to what their experiences were.

The criteria I have found for applying NMP are:
1 - Static evaluation of the current position being greater than beta. This is a no-brainer but does it need to be a full evaluation or would a simpler material only one suffice?

2 - Not being in the PV.

3 - Not being in check.

4 - The player moving having pieces worth at least X (3?) points. From what I can see this is to minimise the chance of zugzwang?

5 - Not being in a tactical sequence. I'm guessing that this is because it can give an artificially inflated/deflated view of the static position.

6 - Not being in the middle of a reduced search which is part of a null move prune test.

If we take criteria 1 as mandatory then there are 32 combinations of the remaining criteria. I do plan to run my own efficacy tests using cutechess-cli but anything I can do to reduce (or target) these tests would be welcomed.


Thanks in advance

Simon

[syzygy]

If we take criteria 1 as mandatory then there are 32 combinations of the remaining criteria. I do plan to run my own efficacy tests using cutechess-cli but anything I can do to reduce (or target) these tests would be welcomed.

Not being in check also seems rather mandatory.

[YumYum]

Cheers Syzygy

S

[Viz]

Not being in check is mandatory, 1st one is actually not.
Usual form in modern engines is smth like ss->staticEval >= beta - 23 * depth + 400 - so it can be lower than beta at higher depths.

[hgm]

What I am missing is the condition "not twice in a row", which many engines use. Doing it only when current eval >= beta guarantees that (assuming symmetric eval, without side-to-move bonus), but more relaxed conditions on eval don't.

Fairy-Max, as well as ome of my other engines do null move when it check. It is in fact how they determine that they are in check. If the null move scores -INF, they award a check extension.

I've never seen condition (5). I thought everyone preferred trying null move over recapturing a hanging Queen, if even without that Queen you would still be above beta. Because the null move would be reduced, and recapturing the Queen not. I always felt this was a mistake. (Recapturing the Queen deserves to be reduced even more...)

[Viz]

IIRC not doing it twice in a row isn't doing much elo wise.

[hgm]

Allowing it twice in a row is a form of null-move verification. The second null move would refute the first, if the first only failed high because it dodged a low-depth zugzwang. If you already have implemented some explicit form of verification, this is of course redundant, and a waste of time. But if the reduction per null move is high, the line is so heavily reduced that the wasted time is negligible. Especially if it happens only in a very narrow range of eval around beta.

Note that there are many forms of strikingly stupid behavior that don't do much Elo-wise. Blundering away 0.5 point every 100 games causes an Elo drop that would require some 25k games to notice. But users will already notice it after some 100 games.

[YumYum]

Thanks everyone. Some really useful points here for me to think about. Also, hopefully, useful for anyone else who's interested.

S