Null-move pruning and mate detection

[eduherminio]

While experimenting with null-move pruning in my engine, I noticed one of my tests failing:

Code: Select all

position fen 5B2/3Q4/8/7p/6N1/6k1/8/5K2 w - - 0 1
go depth 5

With null-pruning enabled, that mate in 3 isn't found at depth 5 any more.

I understand this must be normal, since other engines I've tested suffer the same behavior, specially 'stronger' ones (those ones which have null-move pruning implemented, I guess).

Anyway, the mate is found when searching deeper (depth between 7 and 11 in the ones I've tested, including my implementation in Lynx).

My questions are:

• Does this situation entail any kind of concern at all?

• Is the mate in 5 missed due to the enormous advantage white has, or could it happen in other kind of positions where it might be more worrying?

• Any example of OSS engine out there with null-move pruning implemented that still find that mate at depth 5?

BTW I don't want to bring endgame tablebases to the table, that's not the point plus the position could be altered with a few pawns to avoid being 'solvable'.

Thanks

[amanjpro]

While experimenting with null-move pruning in my engine, I noticed one of my tests failing:

Code: Select all

position fen 5B2/3Q4/8/7p/6N1/6k1/8/5K2 w - - 0 1
go depth 5

With null-pruning enabled, that mate in 3 isn't found at depth 5 any more.

I understand this must be normal, since other engines I've tested suffer the same behavior, specially 'stronger' ones (those ones which have null-move pruning implemented, I guess).

Anyway, the mate is found when searching deeper (depth between 7 and 11 in the ones I've tested, including my implementation in Lynx).

My questions are:

• Does this situation entail any kind of concern at all?

• Is the mate in 5 missed due to the enormous advantage white has, or could it happen in other kind of positions where it might be more worrying?

• Any example of OSS engine out there with null-move pruning implemented that still find that mate at depth 5?

BTW I don't want to bring endgame tablebases to the table, that's not the point plus the position could be altered with a few pawns to avoid being 'solvable'.

Thanks

I wouldn't concern myself that much with this. After all as soon as you implement any form of pruning/reduction/extension your reported depth becomes nothing but a beautiful lie. Zahak here needs depth 15 to find the mate, but also only 60 milliseconds. And to find the optimal mate, it needs depth 16 and 992 milliseconds:

Code: Select all

go
info depth 1 seldepth 2 hashfull 0 tbhits 0 nodes 95 nps 269208 score cp 3462 time 0 pv f8d6 g3f3
info depth 2 seldepth 3 hashfull 0 tbhits 0 nodes 829 nps 475297 score cp 3785 time 1 pv f8d6 g3h4 g4e3
info depth 3 seldepth 4 hashfull 0 tbhits 0 nodes 4600 nps 598316 score cp 3913 time 7 pv f8d6 g3h4 g4e3 h4g5
info depth 4 seldepth 6 hashfull 0 tbhits 0 nodes 4709 nps 594958 score cp 3978 time 7 pv f8d6 g3h4 g4e3 h4g5 d7d8 g5g6
info depth 5 seldepth 7 hashfull 0 tbhits 0 nodes 4838 nps 592480 score cp 3893 time 8 pv f8d6 g3h4 g4e3 h4g5 d7d8 g5g6 e3d5
info depth 6 seldepth 9 hashfull 0 tbhits 0 nodes 4949 nps 586973 score cp 4576 time 8 pv f8d6 g3h4 g4e3 h4g5 d7f5 g5h6 d6f4 h6g7 f5h5
info depth 7 seldepth 10 hashfull 0 tbhits 0 nodes 5132 nps 588968 score cp 4531 time 8 pv f8d6 g3h4 g4e3 h4g5 d7f5 g5h6 d6f4 h6g7 f5h5 g7f6
info depth 8 seldepth 10 hashfull 0 tbhits 0 nodes 5235 nps 584025 score cp 4531 time 8 pv f8d6 g3h4 g4e3 h4g5 d7f5 g5h6 d6f4 h6g7 f5h5 g7f6
info depth 9 seldepth 10 hashfull 0 tbhits 0 nodes 5384 nps 583333 score cp 4531 time 9 pv f8d6 g3h4 g4e3 h4g5 d7f5 g5h6 d6f4 h6g7 f5h5 g7f6
info depth 10 seldepth 10 hashfull 0 tbhits 0 nodes 5531 nps 588190 score cp 4531 time 9 pv f8d6 g3h4 g4e3 h4g5 d7f5 g5h6 d6f4 h6g7 f5h5 g7f6
info depth 11 seldepth 12 hashfull 0 tbhits 0 nodes 5719 nps 592230 score cp 4588 time 9 pv f8d6 g3h4 g4e3 h4g5 d7f5 g5h6 d6f4 h6g7 f5h5 g7f6 h5f5 f6e7
info depth 12 seldepth 12 hashfull 0 tbhits 0 nodes 6024 nps 598230 score cp 4588 time 10 pv f8d6 g3h4 g4e3 h4g5 d7f5 g5h6 d6f4 h6g7 f5h5 g7f6 h5f5 f6e7
info depth 13 seldepth 12 hashfull 0 tbhits 0 nodes 6548 nps 601939 score cp 4728 time 10 pv f8d6 g3h4 g4e3 h4g5 d7f5 g5h6 d6f4 h6g7 f5h5 g7f6 h5f5 f6e7
info depth 14 seldepth 15 hashfull 0 tbhits 0 nodes 7919 nps 584978 score cp 4826 time 13 pv f8d6 g3h4 g4e3 h4g5 d7f5 g5h6 d6f4 h6g7 f5h5 g7f6 h5f5 f6e7 f5d3 e7f7 f1e2
info depth 15 seldepth 7 hashfull 0 tbhits 0 nodes 31498 nps 519733 score mate +4 time 60 pv f8d6 g3h4 g4e3 h4g5 d7f5 g5h6 d6f8
info depth 16 seldepth 5 hashfull 9 tbhits 0 nodes 1223340 nps 1233704 score mate +3 time 991 pv f8h6 h5g4 d7h7 g3h2 h6f4
info depth 17 seldepth 5 hashfull 14 tbhits 0 nodes 1993920 nps 1272376 score mate +3 time 1567 pv f8h6 h5g4 d7h7 g3h2 h6f4
info depth 18 seldepth 5 hashfull 26 tbhits 0 nodes 3458071 nps 1275155 score mate +3 time 2711 pv f8h6 h5g4 d7h7 g3h2 h6f4
info depth 19 seldepth 5 hashfull 39 tbhits 0 nodes 5962665 nps 1278013 score mate +3 time 4665 pv f8h6 h5g4 d7h7 g3h2 h6f4
info depth 20 seldepth 5 hashfull 82 tbhits 0 nodes 12372995 nps 1284478 score mate +3 time 9632 pv f8h6 h5g4 d7h7 g3h2 h6f4
info depth 21 seldepth 5 hashfull 133 tbhits 0 nodes 21826662 nps 1286855 score mate +3 time 16961 pv f8h6 h5g4 d7h7 g3h2 h6f4

What mattered here is the time it needs to find the mate, not the reported depth

[Chessnut1071]

While experimenting with null-move pruning in my engine, I noticed one of my tests failing:

Code: Select all

position fen 5B2/3Q4/8/7p/6N1/6k1/8/5K2 w - - 0 1
go depth 5

With null-pruning enabled, that mate in 3 isn't found at depth 5 any more.

I understand this must be normal, since other engines I've tested suffer the same behavior, specially 'stronger' ones (those ones which have null-move pruning implemented, I guess).

Anyway, the mate is found when searching deeper (depth between 7 and 11 in the ones I've tested, including my implementation in Lynx).

My questions are:

• Does this situation entail any kind of concern at all?

• Is the mate in 5 missed due to the enormous advantage white has, or could it happen in other kind of positions where it might be more worrying?

• Any example of OSS engine out there with null-move pruning implemented that still find that mate at depth 5?

BTW I don't want to bring endgame tablebases to the table, that's not the point plus the position could be altered with a few pawns to avoid being 'solvable'.

Thanks

mate in x problems point out the weakness in pruning, especially if your engine has issues. If you test without pruning you should find every one; otherwise, you may have major flaws that aren't readily found. The mate in x problems is more for perfecting your engine prior to pruning. Relax your pruning option and if there are no issues, you should find every mate. If it doesn't find the correct mate that information can be used to correct your engine. Warning, when I thought I had a solid engine and tried the 170 puzzle mates I recently posted, I found 1,071 structural and program logic errors, and those are only the ones I found.