Null move and node type

[mjlef]

Most programs seem to not use null move pruning in PV nodes. Some also do not try it on expected "all" nodes, so only try null move in expected "cut" nodes. What say you? Any tests showing what node types to allow null indicate it is better than other sets?

Mark

[bob]

Most programs seem to not use null move pruning in PV nodes. Some also do not try it on expected "all" nodes, so only try null move in expected "cut" nodes. What say you? Any tests showing what node types to allow null indicate it is better than other sets?

Mark

I ran this test last year. I found it better to try null move at _every_ node. Bruce Moreland had reported this back when he was active and I have always done it this way. But I tried a cluster test and reducing the number of null-move searches dropped the Elo each and every time.

[hgm]

Could this be because it acts like implicit IID? If a branch contains a null move for both sides, (e.g. null - move - move2 - null) it effectively does a searched with depth N-2R-2 on the position that will later be reached in the full-dept search after move2 - move1, and needs to be searched to N-2 ply.

[bob]

Could this be because it acts like implicit IID? If a branch contains a null move for both sides, (e.g. null - move - move2 - null) it effectively does a searched with depth N-2R-2 on the position that will later be reached in the full-dept search after move2 - move1, and needs to be searched to N-2 ply.

This is one of those things I never tried to analyze, just tested. I suspect it is a result of the best move at the root not changing that frequently, but moves below that move are less stable. I do not think you would want to do a NM search on the _real_ PV, anywhere along it. But knowing what the real PV is, prior to searching, is impossible. NM on non-PV moves is a time-saver. Whether this is a "sorta-IID" search or not is anyone's guess. I don't even use IID any longer in Crafty.

[diep]

Could this be because it acts like implicit IID? If a branch contains a null move for both sides, (e.g. null - move - move2 - null) it effectively does a searched with depth N-2R-2 on the position that will later be reached in the full-dept search after move2 - move1, and needs to be searched to N-2 ply.

Can you generate some statistics on in how many % of the cases you can see it as an IID in your opinion?

Vincent