mmt Vs. Ovyron (G4 D5 BG2)

[zullil]

Thanks, Zenmastur! (How do you do it?)
(The final position is DTZ 63, which sounds relatively "good", but maybe just means in the last 29 moves of SF's pV, its Black moves were worse than its White moves.)

I took a PGN header with a FEN line like this one:

Code: Select all

[Event "?"]
[Site "?"]
[Date "????.??.??"]
[Round "?"]
[White "?"]
[Black "?"]
[Result "*"]
[FEN "5B2/1n6/1k6/3K4/B7/8/8/8 w - - 0 1"]

Then I appended the moves "as is" from Zullil's post and saved it as a pgn file. I then loaded it into a chess program. Easy peasy!

If should be noted that it's a COMPLETE waste of time to try to analyze this with ANY engine that enforces the 50-move-rule. Since the mate is longer than 50 moves the program will simply start making what appears to be "random" moves once it reaches the 50-move limit without finding anything of note. The 50-move-rule in effect will make the engine look like a fool. To do a "proper" search and find the best line of play requires that the code that enforces the 50-move-rule be removed or at least turned off.

Unfortunately, none of the major engines allow this, at least that I'm aware of.

The problem is that a mate when it's first found is likely to be very long, MUCH longer than the minimum length mate. Then, with additional searching, the mate gets shortened when the engine finds better lines of play. This can NEVER happen if the 50-move-rule is enforced and the first mate found is over 50 moves long.

So, even if the mate is a mate in 49 AND the engine first finds a mate in 73 (for instance), instead of refining the line of play to achieve a shorter mate the engine will disregard the line of play because its over 50 moves long. If it ever finds the mate in 49, it will be by pure luck.

It would be nice if they would put an option to disable the 50-move rule for analysis. But, I'm not holding my breath! So, in the mean time, it's a waste of time to try to analyze positions like this. It's not that Stockfish can't solve it, it's prevented from solving it because of the 50-move-rule.

I wonder how many people have tried this and never realized you can't get there from here!

I know of at least one!

Regards,

Zenmastur

I was simply seeing if Stockfish could find a line leading to the capture of the knight, which can be achieved within 50 moves.

[Zenmastur]

Thanks, Zenmastur! (How do you do it?)
(The final position is DTZ 63, which sounds relatively "good", but maybe just means in the last 29 moves of SF's pV, its Black moves were worse than its White moves.)

I took a PGN header with a FEN line like this one:

Code: Select all

[Event "?"]
[Site "?"]
[Date "????.??.??"]
[Round "?"]
[White "?"]
[Black "?"]
[Result "*"]
[FEN "5B2/1n6/1k6/3K4/B7/8/8/8 w - - 0 1"]

Then I appended the moves "as is" from Zullil's post and saved it as a pgn file. I then loaded it into a chess program. Easy peasy!

If should be noted that it's a COMPLETE waste of time to try to analyze this with ANY engine that enforces the 50-move-rule. Since the mate is longer than 50 moves the program will simply start making what appears to be "random" moves once it reaches the 50-move limit without finding anything of note. The 50-move-rule in effect will make the engine look like a fool. To do a "proper" search and find the best line of play requires that the code that enforces the 50-move-rule be removed or at least turned off.

Unfortunately, none of the major engines allow this, at least that I'm aware of.

The problem is that a mate when it's first found is likely to be very long, MUCH longer than the minimum length mate. Then, with additional searching, the mate gets shortened when the engine finds better lines of play. This can NEVER happen if the 50-move-rule is enforced and the first mate found is over 50 moves long.

So, even if the mate is a mate in 49 AND the engine first finds a mate in 73 (for instance), instead of refining the line of play to achieve a shorter mate the engine will disregard the line of play because its over 50 moves long. If it ever finds the mate in 49, it will be by pure luck.

It would be nice if they would put an option to disable the 50-move rule for analysis. But, I'm not holding my breath! So, in the mean time, it's a waste of time to try to analyze positions like this. It's not that Stockfish can't solve it, it's prevented from solving it because of the 50-move-rule.

I wonder how many people have tried this and never realized you can't get there from here!

I know of at least one!

Regards,

Zenmastur

I was simply seeing if Stockfish could find a line leading to the capture of the knight, which can be achieved within 50 moves.

It's technically possible since this CAN happen as early as move 41, BUT you run into the same problem as a mate. It will be found in a line much longer than the 50-move-rule allows so it WILL NOT be pursued further UNLESS, it finds it before move 50. If you disable the 50-move rule I think you will find SF suddenly finds a brain cell or two and will find the night capture.

This is a MAJOR problem for CC type analysis. Especially since high power systems have become MUCH more affordable. Maybe we should ask someone to address the issue as it's only going to get worse with more powerful systems. Maybe IIvec who maintains Corchess can add the appropriate code.

Regards,

Zenmastur

[zullil]

Thanks, Zenmastur! (How do you do it?)
(The final position is DTZ 63, which sounds relatively "good", but maybe just means in the last 29 moves of SF's pV, its Black moves were worse than its White moves.)

I took a PGN header with a FEN line like this one:

Code: Select all

[Event "?"]
[Site "?"]
[Date "????.??.??"]
[Round "?"]
[White "?"]
[Black "?"]
[Result "*"]
[FEN "5B2/1n6/1k6/3K4/B7/8/8/8 w - - 0 1"]

Then I appended the moves "as is" from Zullil's post and saved it as a pgn file. I then loaded it into a chess program. Easy peasy!

If should be noted that it's a COMPLETE waste of time to try to analyze this with ANY engine that enforces the 50-move-rule. Since the mate is longer than 50 moves the program will simply start making what appears to be "random" moves once it reaches the 50-move limit without finding anything of note. The 50-move-rule in effect will make the engine look like a fool. To do a "proper" search and find the best line of play requires that the code that enforces the 50-move-rule be removed or at least turned off.

Unfortunately, none of the major engines allow this, at least that I'm aware of.

The problem is that a mate when it's first found is likely to be very long, MUCH longer than the minimum length mate. Then, with additional searching, the mate gets shortened when the engine finds better lines of play. This can NEVER happen if the 50-move-rule is enforced and the first mate found is over 50 moves long.

So, even if the mate is a mate in 49 AND the engine first finds a mate in 73 (for instance), instead of refining the line of play to achieve a shorter mate the engine will disregard the line of play because its over 50 moves long. If it ever finds the mate in 49, it will be by pure luck.

It would be nice if they would put an option to disable the 50-move rule for analysis. But, I'm not holding my breath! So, in the mean time, it's a waste of time to try to analyze positions like this. It's not that Stockfish can't solve it, it's prevented from solving it because of the 50-move-rule.

I wonder how many people have tried this and never realized you can't get there from here!

I know of at least one!

Regards,

Zenmastur

I was simply seeing if Stockfish could find a line leading to the capture of the knight, which can be achieved within 50 moves.

It's technically possible since this CAN happen as early as move 41, BUT you run into the same problem as a mate. It will be found in a line much longer than the 50-move-rule allows so it WILL NOT be pursued further UNLESS, it finds it before move 50. If you disable the 50-move rule I think you will find SF suddenly finds a brain cell or two and will find the night capture.

This is a MAJOR problem for CC type analysis. Especially since high power systems have become MUCH more affordable. Maybe we should ask someone to address the issue as it's only going to get worse with more powerful systems. Maybe IIvec who maintains Corchess can add the appropriate code.

Regards,

Zenmastur

I guess I'm missing something. Because White is ahead (root eval +3), an engine that is aware of the 50-move rule should have as its only objective forcing a capture in less than 50 moves. Anything else will evaluate as 0. So why would I want to disable 50-move awareness?

[Zenmastur]

I guess I'm missing something. Because White is ahead (root eval +3), an engine that is aware of the 50-move rule should have as its only objective forcing a capture in less than 50 moves. Anything else will evaluate as 0. So why would I want to disable 50-move awareness?

Because when the night capture is first found it will likely be at a depth much greater than 50 moves. If this happens, the engine will ignore the line and score it as 0.00. What you want it to do is treat it like any other line and move it to the PV and begin the process of improving the line until the night capture happens BEFORE the 50 move rule. It won't do this with the 50-move-rule enforced. You wouldn't want the 50-move-rule disabled during games, just for analysis when you know your going to be too close to the limit.

[Ovyron]

"But I can check the TB" is completely irrelevant.

It's not, because... I can check the TB.

With all due respect, this is a really stupid response.

It's not stupid if you assume it's linked to the subject we were discussing. If as jp says it's actually not, then my answer is stupid but the discussion is off-topic and it has nothing to do with this game thread (where... I can check the TB so don't expect mmt to be able to draw this game by leading it to a cursed win where my lack of TBs doesn't let me find the single winning line), and I request you to create a new thread for it and leave this thread alone (if you were discussing this subject in another thread I wouldn't even have participated).

[drewdrew]

I doubt that Stockfish would fail to win from this position in a game. Here's one quick test of default Stockfish-dev self-playing. Haven't looked to see where suboptimal moves occurred.

Thanks, but maybe that's just clueless play as both attacker and defender and it's attacking self just then stumbles into mate.

Can you see whether SFdev makes any headway just analysing from the start position?

Already in progress (for too many hours).

Finally something has happened that brings a glimmer of hope ...

info depth 87 seldepth 101 multipv 1 score cp 348 nodes 241019304319 nps 68485537 hashfull 131 tbhits 0 time 3519273 pv f8e7 b6c7 a4e8 b7a5 e7c5 a5b7 c5b4 c7d8 e8b5 d8c7 b5c4 c7b6 b4f8 b6c7 f8h6 b7a5 h6f4 c7b7 c4d3 b7b6 f4e3 b6c7 d3a6 a5b7 e3f4 c7b6 a6e2 b7a5 f4e3 b6c7 d5c5 a5b7 c5b4 b7d8 b4b5 d8e6 e2d3 c7d6 d3c4 e6c7 b5a4 c7d5 e3f2 d6c6 c4b5 c6d6 a4b3 d5f4 f2b6 f4d5 b6d4 d5c7 b5c4 d6c6 d4c3 c6c5 c3f6 c7b5 c4d3 c5c6 d3e4 c6d6 b3b4 b5c7 f6d4 c7d5 b4b5 d5c7 b5b6 c7d5 b6a7 d5c7 a7b8 c7e6 d4b2 d6c5 b8b7 c5c4 e4h7 e6d4 b7b6 d4e2 b2g7 c4d5 b6a7 d5e6 g7b2 e6d7 h7d3 e2f4 d3a6 d7d6 a7b8 f4g6 b2a3 d6d5 a6b7 d5c4
info depth 88 currmove f8e7 currmovenumber 1
info depth 88 seldepth 110 multipv 1 score cp 359 lowerbound nodes 1863627803823 nps 52943145 hashfull 208 tbhits 0 time 35200549 pv f8e7
info depth 87 currmove f8e7 currmovenumber 1

[d]5B2/1n6/1k6/3K4/B7/8/8/8 w - - 0 1

I've terminated the search after 6332175484277 nodes and 36 hours. Stockfish-dev has failed to demonstrate a solution. The interested reader is welcome to analyze Stockfish's final PV for correctness ...

info depth 90 seldepth 102 multipv 1 score cp 359 nodes 4955083557701 nps 50083826 hashfull 281 tbhits 0 time 98935803 pv f8e7 b6c7 a4e8 c7b6 e7f6 b6c7 f6e5 c7b6 e8a4 b7d8 e5c3 d8b7 c3d4 b6c7 a4b5 b7d8 b5e8 d8b7 d5e6 b7d8 e6f6 c7d6 d4e5 d6d5 e5c7 d8b7 f6g6 b7c5 c7b6 c5b7 e8f7 d5d6 b6d4 b7c5 g6h7 c5e6 d4f6 e6f8 h7h6 f8d7 f6h8 d6c6 f7e6 d7c5 e6c4 c5e4 h8e5 e4d2 c4e6 c6c5 e6f5 c5b4 e5f6 b4c5 f5g6 c5b4 g6d3 b4b3 d3f5 d2f3 f6h8 f3d2 h8d4 d2f3 f5e6 b3c2 d4h8 f3e1 h6h7 e1g2 e6d7 g2e3 d7a4 c2d2 a4c6 d2e2 h7h6 e3c2 c6b5 e2d1 b5c4 c2e3 c4e6 d1d2 e6g8 e3f5 h6g5 f5e7 g8a2 d2c2 a2e6 c2d2 h8f6 e7c6 e6d7 c6b4 f6h8 b4a6
info depth 91 currmove f8e7 currmovenumber 1
stop
info depth 91 seldepth 102 multipv 1 score cp 359 nodes 6332175484277 nps 47617940 hashfull 300 tbhits 0 time 132978776 pv f8e7 b6c7 a4e8 c7b6 e7f6 b6c7 f6e5 c7b6 e8a4 b7d8 e5c3 d8b7 c3d4 b6c7 a4b5 b7d8 b5e8 d8b7 d5e6 b7d8 e6f6 c7d6 d4e5 d6d5 e5c7 d8b7 f6g6 b7c5 c7b6 c5b7 e8f7 d5d6 b6d4 b7c5 g6h7 c5e6 d4f6 e6f8 h7h6 f8d7 f6h8 d6c6 f7e6 d7c5 e6c4 c5e4 h8e5 e4d2 c4e6 c6c5 e6f5 c5b4 e5f6 b4c5 f5g6 c5b4 g6d3 b4b3 d3f5 d2f3 f6h8 f3d2 h8d4 d2f3 f5e6 b3c2 d4h8 f3e1 h6h7 e1g2 e6d7 g2e3 d7a4 c2d2 a4c6 d2e2 h7h6 e3c2 c6b5 e2d1 b5c4 c2e3 c4e6 d1d2 e6g8 e3f5 h6g5 f5e7 g8a2 d2c2 a2e6 c2d2 h8f6 e7c6 e6d7 c6b4 f6h8 b4a6
info depth 90 seldepth 111 multipv 1 score cp 369 nodes 6332175484277 nps 47617940 hashfull 300 tbhits 0 time 132978776 pv f8b4
bestmove f8b4 ponder b7d8

Stockfish-dev seems to be doing a bit better here - my apologies for the raw UCI output; if anybody knows of an easy way of converting this to more friendly notation, let me know -:

info depth 83 seldepth 90 multipv 1 score cp 362 nodes 1364870560954 nps 544585671 hashfull 37 tbhits 0 time 2506255 pv f8e7 b6c7 e7f6 c7b6 a4d1 b6c7 f6e5 c7b6 e5g3 b7d8 d1e2 d8b7 e2c4 b7a5 g3f2 b6b7 c4b5 b7c7 f2e3 a5b7 d5e6 b7d8 e6e7 d8c6 e7f6 c7d6 e3f4 d6c5 b5a4 c5b6 f6g5 c6d8 f4e3 b6c7 a4b3 d8c6 e3f4 c7c8 b3g8 c8b7 g8d5 b7b6 f4d6 b6b5 d6c7 c6d4 c7f4 b5c5 d5f7 d4c6 f7e6 c6d8 e6g8 d8c6 g8f7 c6d8 f4e3 c5d6 f7c4 d8e6 g5f6 e6c7 f6g6 c7e6 c4b3 d6e5 e3b6 e5d6 g6f5 e6g7 f5f4 g7e6 f4e3 d6c6 b6a5 c6d7 b3a4 d7e7 a4b5 e7d6 a5b4 d6e5 b5d7 e5f6 e3e4 f6f7 d7b5 e6g7 b4e1 f7e7 e1h4 e7f7
info depth 84 currmove f8e7 currmovenumber 1
info depth 84 currmove f8b4 currmovenumber 2
info depth 84 seldepth 94 multipv 1 score cp 373 lowerbound nodes 1644989869345 nps 541007243 hashfull 38 tbhits 0 time 3040606 pv f8b4
info depth 83 currmove f8b4 currmovenumber 1
info depth 84 seldepth 105 multipv 1 score cp 384 lowerbound nodes 3249535864761 nps 530268606 hashfull 40 tbhits 0 time 6128094 pv f8b4
info depth 82 currmove f8b4 currmovenumber 1
info depth 84 seldepth 105 multipv 1 score cp 401 lowerbound nodes 4313370410643 nps 522580418 hashfull 44 tbhits 0 time 8253984 pv f8b4
info depth 81 currmove f8b4 currmovenumber 1
info depth 84 seldepth 105 multipv 1 score cp 423 lowerbound nodes 10562576327290 nps 493531585 hashfull 51 tbhits 0 time 21402027 pv f8b4
info depth 80 currmove f8b4 currmovenumber 1
info depth 84 seldepth 105 multipv 1 score cp 454 lowerbound nodes 10566506077297 nps 493511382 hashfull 51 tbhits 0 time 21410866 pv f8b4
info depth 79 currmove f8b4 currmovenumber 1
info depth 84 seldepth 105 multipv 1 score cp 494 lowerbound nodes 11116742883384 nps 491382544 hashfull 52 tbhits 0 time 22623398 pv f8b4
info depth 78 currmove f8b4 currmovenumber 1
info depth 84 seldepth 105 multipv 1 score cp 547 lowerbound nodes 12100668063192 nps 490138534 hashfull 54 tbhits 0 time 24688261 pv f8b4
(snip)
info depth 84 seldepth 105 multipv 1 score cp 547 nodes 12623729511469 nps 488573392 hashfull 55 tbhits 0 time 25837939 pv f8b4 b6c7 a4b5 c7b6 b5e2 b6c7 e2d3 c7d7 d3f5 d7c7 b4d2 c7b6 d2e3 b6c7 e3g5 c7b6 g5e7 b6b5 f5d7 b5b6 e7f8 b6c7 d7e8 b7a5 f8d6 c7b6 e8a4 a5b7 d6a3 b6c7 a3b4 c7b6 b4c3 b7d8 c3e5 b6a5 a4c2 a5b6 c2f5 d8b7 f5d7 b7a5 d7e6 a5b7 e5d4 b6c7 d5c4 b7d8 e6d5 c7d6 d5g2 d6c7 d4e3 d8b7 e3f4 c7b6 g2e4 b7a5 c4c3 a5b7 f4e3 b6c7 c3d4 b7a5 d4d5 a5b7 e4f3 b7d8 f3e2 d8b7 e3f4 c7b6 e2g4 b7a5 f4e3 b6c7 g4e6 a5b7 e3g5 b7d8 g5f4 c7b6 e6g4 d8b7 f4e3 b6c7 g4e2 b7a5 e3f4 c7b6 d5e5 b6c6 e2f3 c6b6 f4e3 b6c7

It then kept on failing high up to +8.96 when I stopped the search.

[mmt]

1. g4 d5 2. Bg2 Bxg4 3. c4 c6 4. Qb3 e6 5. Qxb7 Nd7 6. Nc3 Ne7 7. cxd5 exd5 8. d4 Rb8 9. Qa6 Rb6 10. Qd3 Ng6 11. h3 Be6 12. Nf3 Bd6 13. h4 h5 14. b3 Nf6 15. Bg5 O-O 16. e3 Re8 17. Kf1 Bg4 18. Ne1 Bb4 19. Na4 Rb8 20. Nc2 Be7 21. f3 Be6 22. Nc5 Bc8 23. Kf2 Nd7 24. Ne6 Qa5 25. Bxe7 Rxe7 26. b4 Qb6 27. Ng5 Ba6 28. Qa3 Rbe8 29. Bf1 Bxf1 30. Raxf1 Qc7 31. Qd3 a5 32. a3 axb4 33. axb4 Qd6 34. Rfg1 Nb6 35. Qf5 Nf8 36. Re1 Nc4 37. Nh3 Ra7 38. Qxh5 Ra2 39. Re2 Qe7 40. e4

[d]4rnk1/4qpp1/2p5/3p3Q/1PnPP2P/5P1N/r1N1RK2/7R b - - 0 1
LC0 at -3.01, SF at -5.82.

[jp]

If should be noted that it's a COMPLETE waste of time to try to analyze this with ANY engine that enforces the 50-move-rule. Since the mate is longer than 50 moves the program will simply start making what appears to be "random" moves once it reaches the 50-move limit without finding anything of note. The 50-move-rule in effect will make the engine look like a fool. To do a "proper" search and find the best line of play requires that the code that enforces the 50-move-rule be removed or at least turned off.

Unfortunately, none of the major engines allow this, at least that I'm aware of.

I was simply seeing if Stockfish could find a line leading to the capture of the knight, which can be achieved within 50 moves.

Yes, as Louis said, this position is not a cursed win. DTZ is easily within the 50-move rule.
So this is not a good excuse for SFdev to fail.

Because when the night capture is first found it will likely be at a depth much greater than 50 moves. If this happens, the engine will ignore the line and score it as 0.00. What you want it to do is treat it like any other line and move it to the PV and begin the process of improving the line until the night capture happens BEFORE the 50 move rule.

But why would SFdev be more likely to find a N capture in say 80 moves and improve it to 49 than simply to find it directly in 49? Would it normally try to improve a line like that, or are you saying you'd want to add extra code to make it look for a shortening of an existing line that's too long?


And this may relate to something I wrote quickly last page:

"The PV is 49 moves long. I guess SFdev "knows" the 50-move rule and therefore "refuses" to give a line with 50 moves, because it still "believes" it's +3.59. I guess that's also why it's "only" depth 91, seldepth 102. I assume normally 6.3 trillion nodes would be far greater depth than that (for only 5 pieces), and SFdev just widened its search instead of its normal deepening, for the same reason. Can someone confirm this?"

It seems to me it is widening the search, so I don't know why that should not help it find the direct <=49-move N capture. Why would that be "random" or "improper" search?


But it would be nice to be able to turn off the 50-move rule in SF's code, as you want, so that we can look at longer mates. (To me, the 50-move rule is just an arbitrary practical thing.) Surely there must be a way to hack the code, right??

[mmt]

If dxe4 then fxe4.

[Ovyron]

jp, Zenmastur, et al, can you move your 50-move rule discussion (or whatever it is) to a different thread please? It's holds no relation to the game at hand.