Cursed win at TCEC

[hgm]

Think of it like an "instant replay" in tennis or football, where a call/adjudication is often corrected upon reviewing more detailed information.

I was not aware the players or the audiece determined the outcome of such a review. I thought they had video referees for that...

[zenpawn]

Not really interested in joining the debate. I had legit questions. Sure, they implicitly revealed my opinion, but that's as much as I'd intended to say on the matter. Carry on.

[Norm Pollock]

It is hard to believe that the 5-man gaviota tbs saw something that the 6-man syzygy tbs could not see. So it appears the gaviota tbs were not constrained by the 50-move rule while the syzygy 6-man tbs were.

So since the gui's tbs (gaviota-5man) are not constrained by the 50-move rule, the engine tbs should also not be constrained. But otoh, syzygy does not find the shortest mates and therefore could miss out on a mate that could be executed within 50 moves.

The other alternative is for the gui's tbs to also be constrained by the 50-move rule. That is the best solution going forward.

[whereagles]

(...) The best we can do is run the position through SF with Syzygy50MoveRule set to false, which switches to the ICCF rule.

So I did that and the score gets stuck at +1.14. This suggests that since black cannot escape to a QvBB draw, it has to allow white slightly more space or something. But white still seems unable to make progress. (...)

This is interesting. It suggests the game would have been a draw even if engines were using Syzygy50MoveRule = FALSE.

At this moment the case for manually adjust to draw is very strong.

Next season should definitely either use adjudication TBs with 50 move rule, or allow explicitly for cursed wins and inform developers.

[Evert]

So I did that and the score gets stuck at +1.14. This suggests that since black cannot escape to a QvBB draw, it has to allow white slightly more space or something. But white still seems unable to make progress.

Interesting. It certainly looks that way.
However, I have seen a few cases where the computer is unable to see progress during analysis, but then if you let it play the position against itself, it still manages to win.

[syzygy]

So I did that and the score gets stuck at +1.14. This suggests that since black cannot escape to a QvBB draw, it has to allow white slightly more space or something. But white still seems unable to make progress.

Interesting. It certainly looks that way.
However, I have seen a few cases where the computer is unable to see progress during analysis, but then if you let it play the position against itself, it still manages to win.

It is certainly possible that at move 32 white did have a win when ignoring the 50-move rule or even under the 50-move rule. My point is mainly that the stagnant +1.05/+1.14 evaluations are no proof of that.

In particular, the statement that the 50-move rule "stole" SF's win is really without any basis. If the position was won at move 32 but for the 50-move rule, then the +1.04 cannot possible be evidence of that since it was based on the 50-move rule being in force. And lifting the 50-move rule at that point only increases SF's eval marginally, so does not show anything either.

That H5 at some point definitely had a draw both with and without 50-move rule is proven by the position at move 59.

[Rochester]

I guess the best solution would be this: a side that has a win can request a larger number of moves than 50 in order to achieve it. But if he does so, and doesn't manage to win (e.g. because the game converts to insufficient material, or runs into a repetition), he will be declared loser. That should be enough to discourage frivolous use, and limit extension requests for cases where the player indeed sees a certain win.

My clock better? Then now claim the mate in 100000.

[MikeB]

Have a look:

http://tcec.chessdom.com/archive.php?se=9&sf&ga=17

Engines showing 0.00 due to 50-move rule, but position was auto-adjudicated as an M72 TB win

Discuss

Not much discussion possible.
Both engines know that it's a draw (0.00) and play accordingly.
Suddenly the GUI decides otherwise and is clearly not following the rules of chess as implemented in the engines.
It's kinda ridiculous, but not very important.

Agreed, it should be a draw. As I posted in the TCEC chat, the adjudication should match the result if the engines had played the position out. In this game, it was a 50 move draw.

I would not agree here with Gary.
A tablebase win is a tablebase win. The position is simply won for white, so why declare it a draw? If both engines assume it is 0.0, that is only their fault they still have not implemented the much more relevant 100-move draw rule instead of the well-outdated 50-move rule. (or, what is the longest tb win without captures/promotions/pawn move?)

I am not certain what FIDE says about the 50-move/100-move draw rule, but why should engines follow FIDE? Engines are at the cutting edge of progress and progress says abovementioned position is simply a win for the stronger side. It is simply time to implement longer draw rule than 50-moves.

That should be specified in some protocol though, I agree it was not quite fair to both Houdini and SF in terms of their lack of knowledge, but a win is a win.

Actually Stockfish has that knowledge, all its need is that little check box to be unchecked to false. If the operator knew the 50 move rule was not going to follow FIDE 50 move rule, the setting should, have been false. So either way , it is operator error.

option name Syzygy50MoveRule type check default true

[d]K5Q1/8/8/8/5bb1/6k1/8/8 b - - 0 1

Code: Select all

info depth 52 seldepth 81 multipv 1 score cp -12851 nodes 795536006 nps 43396029 hashfull 232 tbhits 15 time 18332 pv f4e5 a8b7 g3f3 g8d5 f3f4 d5c4 f4f5 b7c6 g4f3 c6b6 f3g4 b6c5 g4f3 c4f7 f5e4 f7g6 e4f4 g6h6 f4e4 h6h7 e4e3 h7h3 e3e4 h3d7 e4e3 d7d8 e3e4 d8d2 e4f5 d2f2 f5e4 f2h4 e4f5 c5c4 f3e2 c4d5 e2f3 d5c5 f3e4 h4f2 f5g5 f2e3 g5f5 e3e2 e5f6 e2h5 f5e6 h5h6 e6e5 h6h2 e5e6 h2d6 e6f5 d6d7 f5e5 d7f7 e4f3 f7c7 e5f5 c7d7 f5f4 d7d2 f4f5 d2h2 f6e7 c5c4 e7f6 h2g3 f3e4 g3h3 f5e5 h3h5 e5d6 h5b5 d6e6 c4c5 e6e5

[Joerg Oster]

Have a look:

http://tcec.chessdom.com/archive.php?se=9&sf&ga=17

Engines showing 0.00 due to 50-move rule, but position was auto-adjudicated as an M72 TB win

Discuss

Not much discussion possible.
Both engines know that it's a draw (0.00) and play accordingly.
Suddenly the GUI decides otherwise and is clearly not following the rules of chess as implemented in the engines.
It's kinda ridiculous, but not very important.

Agreed, it should be a draw. As I posted in the TCEC chat, the adjudication should match the result if the engines had played the position out. In this game, it was a 50 move draw.

I would not agree here with Gary.
A tablebase win is a tablebase win. The position is simply won for white, so why declare it a draw? If both engines assume it is 0.0, that is only their fault they still have not implemented the much more relevant 100-move draw rule instead of the well-outdated 50-move rule. (or, what is the longest tb win without captures/promotions/pawn move?)

I am not certain what FIDE says about the 50-move/100-move draw rule, but why should engines follow FIDE? Engines are at the cutting edge of progress and progress says abovementioned position is simply a win for the stronger side. It is simply time to implement longer draw rule than 50-moves.

That should be specified in some protocol though, I agree it was not quite fair to both Houdini and SF in terms of their lack of knowledge, but a win is a win.

Actually Stockfish has that knowledge, all its need is that little check box to be unchecked to false. If the operator knew the 50 move rule was not going to follow FIDE 50 move rule, the setting should, have been false. So either way , it is operator error.

option name Syzygy50MoveRule type check default true

[d]K5Q1/8/8/8/5bb1/6k1/8/8 b - - 0 1

Code: Select all

info depth 52 seldepth 81 multipv 1 score cp -12851 nodes 795536006 nps 43396029 hashfull 232 tbhits 15 time 18332 pv f4e5 a8b7 g3f3 g8d5 f3f4 d5c4 f4f5 b7c6 g4f3 c6b6 f3g4 b6c5 g4f3 c4f7 f5e4 f7g6 e4f4 g6h6 f4e4 h6h7 e4e3 h7h3 e3e4 h3d7 e4e3 d7d8 e3e4 d8d2 e4f5 d2f2 f5e4 f2h4 e4f5 c5c4 f3e2 c4d5 e2f3 d5c5 f3e4 h4f2 f5g5 f2e3 g5f5 e3e2 e5f6 e2h5 f5e6 h5h6 e6e5 h6h2 e5e6 h2d6 e6f5 d6d7 f5e5 d7f7 e4f3 f7c7 e5f5 c7d7 f5f4 d7d2 f4f5 d2h2 f6e7 c5c4 e7f6 h2g3 f3e4 g3h3 f5e5 h3h5 e5d6 h5b5 d6e6 c4c5 e6e5

After switching to Marco's C++ rewrite of syzygy support, you get a nice additional info after issuing the 'd' command in console/terminal mode.

Code: Select all

position fen K5Q1/8/8/8/5bb1/6k1/8/8 b - - 0 1
d

 +---+---+---+---+---+---+---+---+
 | K |   |   |   |   |   | Q |   |
 +---+---+---+---+---+---+---+---+
 |   |   |   |   |   |   |   |   |
 +---+---+---+---+---+---+---+---+
 |   |   |   |   |   |   |   |   |
 +---+---+---+---+---+---+---+---+
 |   |   |   |   |   |   |   |   |
 +---+---+---+---+---+---+---+---+
 |   |   |   |   |   | b | b |   |
 +---+---+---+---+---+---+---+---+
 |   |   |   |   |   |   | k |   |
 +---+---+---+---+---+---+---+---+
 |   |   |   |   |   |   |   |   |
 +---+---+---+---+---+---+---+---+
 |   |   |   |   |   |   |   |   |
 +---+---+---+---+---+---+---+---+

Fen: K5Q1/8/8/8/5bb1/6k1/8/8 b - - 0 1
Key: 0BAC4146F2FD04BC
Checkers: 
Tablebases WDL: Cursed loss (Success)
Tablebases DTZ: -124 (Best move zeroes DTZ)

Here you see it's a cursed loss (or is it a blessed loss?),
and the distance to zeroing is 124 plies. (I don't think negative sign makes sense here?)

Very nice. Thanks, Marco!

[Lyudmil Tsvetkov]

So I did that and the score gets stuck at +1.14. This suggests that since black cannot escape to a QvBB draw, it has to allow white slightly more space or something. But white still seems unable to make progress.

Interesting. It certainly looks that way.
However, I have seen a few cases where the computer is unable to see progress during analysis, but then if you let it play the position against itself, it still manages to win.

It is certainly possible that at move 32 white did have a win when ignoring the 50-move rule or even under the 50-move rule. My point is mainly that the stagnant +1.05/+1.14 evaluations are no proof of that.

In particular, the statement that the 50-move rule "stole" SF's win is really without any basis. If the position was won at move 32 but for the 50-move rule, then the +1.04 cannot possible be evidence of that since it was based on the 50-move rule being in force. And lifting the 50-move rule at that point only increases SF's eval marginally, so does not show anything either.

That H5 at some point definitely had a draw both with and without 50-move rule is proven by the position at move 59.

this is my last post here, as the thread gets too long and discussion too boring.

no one knows how the game would have ended, as top engine analysis is imperfect, even in relatively simple positions.

the TCEC game is just a case in point; we do not particularly care how the game should have ended, one side could have 20cps more advantage, or 20cps less advantage, making the position winnable or drawable, what really matters is the absence of a more general rule that artificially penalises an objective win as a draw.

if we are not interested in the objective outcome of a position, why play the game at all?