Did SF like your move after you disabled nullmove?
Or do you just blame any perceived shortcoming of SF on nullmove?
I did not test stockfish without null move and I suspect that it cannot find the right move here in a reasonable time with null move pruning or without null move pruning but I have the feeling that stockfish can find things faster without null move pruning from understanding how null move pruning works.
If the only threat of a move is a long plan then stockfish may need depth 1000 to see it with null move pruning and depth 60 to see it without null move pruning that means that stockfish may need 100000 years to find it without null move pruning(assuming you increase the maximal depth to be bigger than 120 and only 1 month to find it with null move pruning.
The time lengths here and the depth are only to express an idea and it is not that I calculated them.
I strongly believe that it is possible to find a more convincing example when stockfish can practically play better move without null move because it does not prune a long plan that is not so long that even avoiding null move pruning does not practically help and I will try to find later a better example.
Obviously nullmove pruning does not stop engines from finding long plans. Just look at actual games.
Nullmove only prunes moves that seem so bad that immediately doing a second move without letting the opponent move still does not result in a good position. Most moves of long plans that are any good won't be pruned (i.e. will not add another say 3 ply to the depth required for finding it).
If the long plans involve a series of sacrifices, there might be a problem. But these are very rare and modern engines don't seem to suffer from blindness to long series of sacrifices.
Modern engines without nullmove search a lot less deep and therefore miss many plans that nullmoves allows them to find. (Please do not again come up with your infinite time argument.)
xmas79 wrote:what if we disable null move at different drafts? The idea is simple: suppose you disable nulls at draft 1, so the last ply Y=X-1 of depth X doesn't get nulls. That means if this node is an all node, then the DONT_TRY_NULL_MOVE flag will be stored in the hash. In the next iteration we will retrieve this information and at ply Z-2 where Z=X+1 we will skip null. The idea is let iteration framework build this table iteratively. I don't have any cluster to test seriously this idea (if it's worth!). See which draft (suppose 2 4 8 16) performs better.
Natale.
This has been done a dozen different ways. The adaptive null-move idea is to reduce the R value near the tips. However, when I added checks to Crafty's q-search, the primary benefit I found was that doing nulls all the way to the frontier became better...
syzygy wrote:Obviously nullmove pruning does not stop engines from finding long plans. Just look at actual games.
Nullmove only prunes moves that seem so bad that immediately doing a second move without letting the opponent move still does not result in a good position. Most moves of long plans that are any good won't be pruned (i.e. will not add another say 3 ply to the depth required for finding it).
If the long plans involve a series of sacrifices, there might be a problem. But these are very rare and modern engines don't seem to suffer from blindness to long series of sacrifices.
Modern engines without nullmove search a lot less deep and therefore miss many plans that nullmoves allows them to find. (Please do not again come up with your infinite time argument.)
I would bet any shortcoming in this game is a result of aggressive LMR rather than null-move.
syzygy wrote:Obviously nullmove pruning does not stop engines from finding long plans. Just look at actual games.
Nullmove only prunes moves that seem so bad that immediately doing a second move without letting the opponent move still does not result in a good position. Most moves of long plans that are any good won't be pruned (i.e. will not add another say 3 ply to the depth required for finding it).
If the long plans involve a series of sacrifices, there might be a problem. But these are very rare and modern engines don't seem to suffer from blindness to long series of sacrifices.
Modern engines without nullmove search a lot less deep and therefore miss many plans that nullmoves allows them to find. (Please do not again come up with your infinite time argument.)
I think that one sacrifice is enough for programs to prune long plans because many quiet moves after it have no threat.