Difficult ending for Stockfish

[Jouni]

[D]8/8/8/5pp1/8/1K6/2pp1Q2/2k5 w - - 0 1 bm Qe3;
[D]4k2r/2K2p2/6P1/2R2P2/8/8/7B/b7 w k - 0 1 bm Be5;
[D]rk6/p2p4/KPRp4/8/3P4/8/8/8 w - - 0 1 bm Rc8+;

These are not solved by 8.2. SF in 5 minutes, when 3.2. only takes seconds.

[Michel]

Verified! Thanks.

[Joerg Oster]

[D]8/3Pb1p1/8/3P2P1/5P2/7k/4K3/8 w - - 0 1

Analysis by Stockfish 040114 64 1cpu:

1.d6 Bd8 2.Kf3 g6 3.Ke4 Kg4 4.Ke5
+- (1.89) Depth: 7/7 00:00:00 2kN
1.d6 Bd8 2.Kf3 g6 3.Ke4 Kg4 4.Ke5 Bb6
+- (1.83) Depth: 8/8 00:00:00 3kN
.
.
1.Kf3 Kh4 2.Ke4 Kg4 3.g6 Bf6 4.d6 Bd8 5.Ke5 Bf6+ 6.Ke4
= (0.00) Depth: 42/24 00:00:43 101mN
1.Kf3 Kh4 2.Ke4 Kg4 3.g6 Bf6 4.d6 Bd8 5.Ke5 Bf6+ 6.Ke4
= (0.00) Depth: 43/24 00:00:55 129mN
1.Kf3 Kh4 2.Ke4 Kg4 3.g6 Bf6 4.d6 Bd8 5.Ke5 Bf6+ 6.Ke4
= (0.00) Depth: 44/24 00:01:07 160mN
1.Kf3 Kh4 2.Ke4 Kg4 3.g6 Bf6 4.d6 Bd8 5.Ke5 Bf6+ 6.Ke4
= (0.00) Depth: 45/24 00:01:31 219mN.
.
.
1.Kd3 Kg4 2.Ke4 Bd8 3.Ke5 g6 4.d6 Kh4 5.Ke6 Kg4 6.f5 gxf5 7.g6 Bb6 8.g7
+/= (0.28 ++) Depth: 49/57 00:07:15 1136mN

Other engines solve instantly with 10-20 plies!

No problem for SF with my wrong_bishop_fix.

Code: Select all

info depth 20 seldepth 27 score cp 0 nodes 354763 nps 2124329 time 167 multipv 1 pv e2d3 h3g3 d5d6 e7d8 d3e3 g3g4 e3e4 d8b6 d7d8n b6d8 e4e5 g7g6 d6d7 d8c7 e5f6 c7d8 f6g6 g4f4 g6f7 d8g5 f7e6 f4g4 e6e5 g5d8 e5e4 d8b6 e4e5
info depth 21 seldepth 27 score cp 0 nodes 528660 nps 2288571 time 231 multipv 1 pv e2d3 h3g3 d5d6 e7d8 d3e3 g3g4 e3e4 g7g6 e4e5 d8a5 f4f5 g4g5 f5g6 g5g6 e5d5 g6f5 d5c6 f5e5 c6b7 e5d6 b7c8 d6e5 d7d8q a5d8
info depth 22 seldepth 34 score cp 4 nodes 704985 nps 2365721 time 298 multipv 1 pv e2d3 h3g3 d5d6 e7d8 d3e3 g3g4 e3e4 g7g6 e4e5 d8a5 f4f5 g4g5 e5e6 g6f5 e6e7 f5f4 d7d8q a5d8 e7d8 f4f3 d6d7 f3f2 d8c7 f2f1q d7d8q g5g4 d8g8 g4h4 g8h8 h4g3 h8c3 g3g4 c3g7 g4h4 g7h6 h4g3 h6g7 g3h4
info depth 23 seldepth 42 score cp 195 nodes 2333038 nps 2738307 time 852 multipv 1 pv e2d3 h3g3 d3e3 g3g4 e3e4 e7d8 e4e5 g4g3 g5g6 g3f3 f4f5 f3e3 e5e6 e3d4 d5d6 d8f6 e6f7 d4e5 f7e8 e5d6 d7d8q f6d8 e8d8
info depth 24 seldepth 42 score cp 604 nodes 4791728 nps 2871017 time 1669 multipv 1 pv e2d3 h3g3 d3e3 g3h4 e3d4 e7d8 g5g6 h4h5 f4f5 d8c7 d4c5 h5g5 c5c6 c7a5 c6b7 g5f5 b7c8 f5g6 d7d8q a5d8 c8d8 g6f6 d5d6 g7g5 d6d7 g5g4 d8c7
info depth 25 seldepth 42 score cp 610 nodes 5095120 nps 2865646 time 1778 multipv 1 pv e2d3 h3g3 d3e3 e7d8 e3e4 g3h3 e4e5 h3g4 g5g6 g4h5 f4f5 h5g5 e5e6 d8f6 e6f7 g5f5 d7d8q f6d8 f7g7 d8f6 g7f7 f6e5 d5d6 e5d6 g6g7
info depth 26 seldepth 44 score cp 877 lowerbound nodes 8832978 nps 2924827 time 3020 multipv 1 pv e2d3 h3g3 d3e3 e7d8 e3e4 g3h3 e4e5 h3g4 g5g6 g4h5 f4f5 h5g5 e5e6 d8f6 e6f7 g5f5 d7d8q f6d8 f7g7 d8f6 g7f7 f6e5 d5d6 e5d6 g6g7 d6c7 g7g8q c7f4 g8g6 f5e5 g6e6 e5d4 e6d7 d4c3 d7e7 f4d2 e7f6 c3b3 f7e6

I was looking at the position out of curiosity. Your PV looks strange, to say the least.

in particular, the move g3h3 (6th move in last pv) really looks to be "out there". Crafty thinks that loses badly and quickly. Crafty likes Kg4 and continues to hold the draw score...

But this position is a win for white! That's the point here.

And the pv I posted was taken after a 3 seconds search ... just to demonstrate, that there is an easy solution to the problem, that SF doesn't recognize the win immediately. Problem is futility pruning in qsearch, which I simply deactivate in very late endgame.

From here: https://chessprogramming.wikispaces.com/Delta+Pruning

For safety reasons, delta pruning should be switched off in the late endgame, since otherwise quiescence search would be blind to insufficient material issues and transitions into won endgames made at the expense of some material.

[syzygy]

So that's what removing verification search as "simplification" gets you...

Interesting philosophy that is being applied now. If some good patch manages to get into SF by passing all tests, it then becomes the prey of various extremists that will simply repeatedly test it until its removal is "proven" to be a safe simplification.

[Vinvin]

So that's what removing verification search as "simplification" gets you...

Interesting philosophy that is being applied now. If some good patch manages to get into SF by passing all tests, it then becomes the prey of various extremists that will simply repeatedly test it until its removal is "proven" to be a safe simplification.

It would be useful to make a small (around 20 positions) sets of positions (mainly zugzwang, difficult long winning lines and near draw endings) to make some sanity checks after optimizations.

[Uri Blass]

So that's what removing verification search as "simplification" gets you...

Interesting philosophy that is being applied now. If some good patch manages to get into SF by passing all tests, it then becomes the prey of various extremists that will simply repeatedly test it until its removal is "proven" to be a safe simplification.

The verification search was not some good patch that passed all tests so I do not see the basis for your claim.

Note that stockfish has no problems to find the right move in most
zugzwang positions because it does not use null move pruning in every position(eval>=beta is one restriction and depth>=2 plies is another restriction).

It is not that zugzwangs never happen in games but that zugzwangs that cause stockfish not to be able to find the right move do not happen often.

The main question is how often zugzwang detection can practically help in games(even if you assume that the price is zero).
If it can help only in 1 out of 1000 games or even 1 out of 500 games then it is not enough to accept them.

The way to find out may be to play many games at fixed depth between stockfish without zugzwang detection and stockfish with zugzwang detection and to see if the version with zugzwang detection can win and what is going to be the result.

Note that zugzwang detection does not mean avoid null move pruning and it only means before using null move pruning to find that there is at least one legal move that is not worse than null move based on searching to the same depth.

[bob]

[D]8/3Pb1p1/8/3P2P1/5P2/7k/4K3/8 w - - 0 1

Analysis by Stockfish 040114 64 1cpu:

1.d6 Bd8 2.Kf3 g6 3.Ke4 Kg4 4.Ke5
+- (1.89) Depth: 7/7 00:00:00 2kN
1.d6 Bd8 2.Kf3 g6 3.Ke4 Kg4 4.Ke5 Bb6
+- (1.83) Depth: 8/8 00:00:00 3kN
.
.
1.Kf3 Kh4 2.Ke4 Kg4 3.g6 Bf6 4.d6 Bd8 5.Ke5 Bf6+ 6.Ke4
= (0.00) Depth: 42/24 00:00:43 101mN
1.Kf3 Kh4 2.Ke4 Kg4 3.g6 Bf6 4.d6 Bd8 5.Ke5 Bf6+ 6.Ke4
= (0.00) Depth: 43/24 00:00:55 129mN
1.Kf3 Kh4 2.Ke4 Kg4 3.g6 Bf6 4.d6 Bd8 5.Ke5 Bf6+ 6.Ke4
= (0.00) Depth: 44/24 00:01:07 160mN
1.Kf3 Kh4 2.Ke4 Kg4 3.g6 Bf6 4.d6 Bd8 5.Ke5 Bf6+ 6.Ke4
= (0.00) Depth: 45/24 00:01:31 219mN.
.
.
1.Kd3 Kg4 2.Ke4 Bd8 3.Ke5 g6 4.d6 Kh4 5.Ke6 Kg4 6.f5 gxf5 7.g6 Bb6 8.g7
+/= (0.28 ++) Depth: 49/57 00:07:15 1136mN

Other engines solve instantly with 10-20 plies!

No problem for SF with my wrong_bishop_fix.

Code: Select all

info depth 20 seldepth 27 score cp 0 nodes 354763 nps 2124329 time 167 multipv 1 pv e2d3 h3g3 d5d6 e7d8 d3e3 g3g4 e3e4 d8b6 d7d8n b6d8 e4e5 g7g6 d6d7 d8c7 e5f6 c7d8 f6g6 g4f4 g6f7 d8g5 f7e6 f4g4 e6e5 g5d8 e5e4 d8b6 e4e5
info depth 21 seldepth 27 score cp 0 nodes 528660 nps 2288571 time 231 multipv 1 pv e2d3 h3g3 d5d6 e7d8 d3e3 g3g4 e3e4 g7g6 e4e5 d8a5 f4f5 g4g5 f5g6 g5g6 e5d5 g6f5 d5c6 f5e5 c6b7 e5d6 b7c8 d6e5 d7d8q a5d8
info depth 22 seldepth 34 score cp 4 nodes 704985 nps 2365721 time 298 multipv 1 pv e2d3 h3g3 d5d6 e7d8 d3e3 g3g4 e3e4 g7g6 e4e5 d8a5 f4f5 g4g5 e5e6 g6f5 e6e7 f5f4 d7d8q a5d8 e7d8 f4f3 d6d7 f3f2 d8c7 f2f1q d7d8q g5g4 d8g8 g4h4 g8h8 h4g3 h8c3 g3g4 c3g7 g4h4 g7h6 h4g3 h6g7 g3h4
info depth 23 seldepth 42 score cp 195 nodes 2333038 nps 2738307 time 852 multipv 1 pv e2d3 h3g3 d3e3 g3g4 e3e4 e7d8 e4e5 g4g3 g5g6 g3f3 f4f5 f3e3 e5e6 e3d4 d5d6 d8f6 e6f7 d4e5 f7e8 e5d6 d7d8q f6d8 e8d8
info depth 24 seldepth 42 score cp 604 nodes 4791728 nps 2871017 time 1669 multipv 1 pv e2d3 h3g3 d3e3 g3h4 e3d4 e7d8 g5g6 h4h5 f4f5 d8c7 d4c5 h5g5 c5c6 c7a5 c6b7 g5f5 b7c8 f5g6 d7d8q a5d8 c8d8 g6f6 d5d6 g7g5 d6d7 g5g4 d8c7
info depth 25 seldepth 42 score cp 610 nodes 5095120 nps 2865646 time 1778 multipv 1 pv e2d3 h3g3 d3e3 e7d8 e3e4 g3h3 e4e5 h3g4 g5g6 g4h5 f4f5 h5g5 e5e6 d8f6 e6f7 g5f5 d7d8q f6d8 f7g7 d8f6 g7f7 f6e5 d5d6 e5d6 g6g7
info depth 26 seldepth 44 score cp 877 lowerbound nodes 8832978 nps 2924827 time 3020 multipv 1 pv e2d3 h3g3 d3e3 e7d8 e3e4 g3h3 e4e5 h3g4 g5g6 g4h5 f4f5 h5g5 e5e6 d8f6 e6f7 g5f5 d7d8q f6d8 f7g7 d8f6 g7f7 f6e5 d5d6 e5d6 g6g7 d6c7 g7g8q c7f4 g8g6 f5e5 g6e6 e5d4 e6d7 d4c3 d7e7 f4d2 e7f6 c3b3 f7e6

I was looking at the position out of curiosity. Your PV looks strange, to say the least.

in particular, the move g3h3 (6th move in last pv) really looks to be "out there". Crafty thinks that loses badly and quickly. Crafty likes Kg4 and continues to hold the draw score...

But this position is a win for white! That's the point here.

And the pv I posted was taken after a 3 seconds search ... just to demonstrate, that there is an easy solution to the problem, that SF doesn't recognize the win immediately. Problem is futility pruning in qsearch, which I simply deactivate in very late endgame.

From here: https://chessprogramming.wikispaces.com/Delta+Pruning

For safety reasons, delta pruning should be switched off in the late endgame, since otherwise quiescence search would be blind to insufficient material issues and transitions into won endgames made at the expense of some material.

My point was that move appears to be grossly sub-optimal. There are other moves that don't seem to fall apart. I think Kg4 was one but I don't have any of the analysis in front of me..

[phenri]

Here is the simplified position of this one:
[D]8/3Pb1p1/8/3P2P1/5Pk1/3K4/8/8 w - - 0 1
Where we see the Stockfish today prefer to die with a full stomach.
[D]8/3P4/3P2p1/b3KPk1/8/8/8/8 w - - 0 1

Code: Select all

Analysis by Stockfish 100214 64 SSE4.2:
5.fxg6 Kxg6 6.d8R Bxd8 7.d7 Bb6 8.Kd5 
  =  (0.00)   Depth: 7/7   00:00:00  1kN
(...)
5.fxg6 Kxg6 6.d8R Bxd8 7.d7 Bb6 8.Kd5 Bd8 9.Kc4 Bb6 10.Kd5 
  =  (0.00)   Depth: 54/13   00:00:34  130MN
5.fxg6 Kxg6 6.d8R Bxd8 7.d7 Bb6 8.Kd5 Bd8 9.Kc4 Bb6 10.Kd5 
  =  (0.00)   Depth: 55/13   00:00:39  154MN
5.fxg6 Kxg6 6.d8R Bxd8 7.d7 Bb6 8.Kd5 Bd8 9.Kc4 Bb6 10.Kd5 
  =  (0.00)   Depth: 56/13   00:00:46  185MN

While solution seems rather simple. f6!

Code: Select all

Analysis by Stockfish 2.3.1 JA 64bit SSE4.2:
5.fxg6 Kxg6 6.Ke6 Bd8 7.Kd5 Kf7 8.Kc5 Bg5 9.d8Q Bxd8 10.Kd5 
  =  (0.00)   Depth: 7/11   00:00:00  3kN
(...)
5.fxg6 Kxg6 6.Ke6 Bd8 7.Kd5 Kf7 8.Kc5 Bg5 9.d8Q Bxd8 10.Kd5 Bg5 11.Kc5 Bd8 
  =  (0.00)   Depth: 13/15   00:00:00  32kN
5.f6 Bc3+ 6.Kd5 Bxf6 7.Ke6 Bd8 8.Kf7 Kh4 9.Ke8 Bg5 10.d8Q Bxd8 11.Kxd8 g5 12.Kc7 g4 13.d7 g3 14.d8Q+ Kh3 15.Qd7+ Kh2 16.Qd6 Kh3 17.Qe6+ Kh2 18.Qe5 Kh1 19.Qh8+ Kg2 20.Qg7 Kf2 
  +-  (10.10)   Depth: 14/35   00:00:00  271kN
(...)
5.f6 Bc3+ 6.Kd5 Bxf6 7.Ke6 Bd8 8.Kf7 Ba5 9.Ke8 Kh4 10.d8Q+ Bxd8 11.Kxd8 g5 12.Kc7 g4 13.d7 Kh3 14.d8Q g3 15.Qh8+ Kg2 16.Kc6 Kf1 17.Qa1+ Kf2 18.Qd4+ Kg2 
  +-  (#24)   Depth: 34/58   00:01:31  677MN

Code: Select all

Analysis by Stockfish 101113 64 SSE4.2:
5.fxg6 Kxg6 6.d8R Bxd8 7.d7 Bb6 8.Kd5 
  =  (0.00)   Depth: 7/7   00:00:00  1kN
(...)
5.fxg6 Kxg6 6.d8R Bxd8 7.d7 Bb6 8.Kd5 Bd8 9.Kc4 Bb6 10.Kd5 
  =  (0.00)   Depth: 22/12   00:00:00  268kN
5.f6 Bc3+ 6.Kd5 Bxf6 7.Ke6 Bd8 8.Kf7 Bb6 9.Ke8 Kf4 10.d8Q Bxd8 11.Kxd8 g5 12.d7 Kf3 13.Ke7 g4 14.d8Q g3 15.Ke6 Ke2 16.Qd4 Kf1 17.Qa1+ Kf2 18.Kf5 g2 19.Qa7+ Ke2 20.Ke4 
  +-  (12.02)   Depth: 23/37   00:00:00  1129kN
(...)
5.f6 Bc3+ 6.Kd5 Bxf6 7.Ke6 Bd8 8.Kf7 Kg4 9.Ke8 Bh4 10.d8Q g5 11.Qf6 Kh3 12.d7 g4 13.Qxh4+ Kxh4 14.d8Q+ Kh3 15.Qd1 Kg3 16.Ke7 Kf4 17.Qd2+ Kf5 18.Qd5+ Kf4 19.Kf6 g3 20.Qg2 Ke3 21.Qxg3+ Kd4 22.Ke6 Kc5 23.Qc3+ Kb5 24.Qa3 Kc4 
  +-  (89.14)   Depth: 34/40   00:00:07  18742kN

[syzygy]

So that's what removing verification search as "simplification" gets you...

Interesting philosophy that is being applied now. If some good patch manages to get into SF by passing all tests, it then becomes the prey of various extremists that will simply repeatedly test it until its removal is "proven" to be a safe simplification.

The verification search was not some good patch that passed all tests so I do not see the basis for your claim.

Maybe not in this case, but as far as I understand the test for an at some point accepted patch to not be thrown out as "simplification" is as tough as the test for a new patch to be accepted into the tree. So for a patch to stay it has to survive the original acceptance test over and over again (and by statistics it won't).

[Michel]

Verified! Thanks.