Cursed win at TCEC

Discussion of anything and everything relating to chess playing software and machines.

Moderators: hgm, Harvey Williamson, bob

syzygy
Posts: 4179
Joined: Tue Feb 28, 2012 10:56 pm

Re: fortress_draw_rule

Post by syzygy » Sat Nov 19, 2016 8:56 pm

Evert wrote:
syzygy wrote: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
Posts: 55
Joined: Sat Feb 20, 2016 5:11 am

Re: fortress_draw_rule

Post by Rochester » Sat Nov 19, 2016 10:11 pm

hgm wrote: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.

User avatar
MikeB
Posts: 2505
Joined: Thu Mar 09, 2006 5:34 am
Location: Pen Argyl, Pennsylvania

Re: Cursed win at TCEC

Post by MikeB » Sun Nov 20, 2016 5:35 am

Lyudmil Tsvetkov wrote:
gladius wrote:
Houdini wrote:
whereagles wrote: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 :D

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
Posts: 609
Joined: Fri Mar 10, 2006 3:29 pm
Location: Germany

Re: Cursed win at TCEC

Post by Joerg Oster » Sun Nov 20, 2016 9:09 am

MikeB wrote:
Lyudmil Tsvetkov wrote:
gladius wrote:
Houdini wrote:
whereagles wrote: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 :D

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!
Jörg Oster

Lyudmil Tsvetkov
Posts: 6031
Joined: Tue Jun 12, 2012 10:41 am

Re: fortress_draw_rule

Post by Lyudmil Tsvetkov » Sun Nov 20, 2016 9:18 am

syzygy wrote:
Evert wrote:
syzygy wrote: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?

User avatar
hgm
Posts: 22083
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Contact:

Re: fortress_draw_rule

Post by hgm » Sun Nov 20, 2016 9:42 am

The point is that the 'objective outcome of the position' depends on the rules of the game. Take again the following position:
[d]7q/8/5k2/8/8/4K3/8/8 w
This position can either be an 'objective win' for white, an objective win for black, or an objective draw. So there actually isn't very much 'objective' about this.

Usually one is interested only in the outcome of the position under the rules that currently apply.
Last edited by hgm on Sun Nov 20, 2016 9:45 am, edited 1 time in total.

Lyudmil Tsvetkov
Posts: 6031
Joined: Tue Jun 12, 2012 10:41 am

Re: fortress_draw_rule

Post by Lyudmil Tsvetkov » Sun Nov 20, 2016 9:44 am

btw., just to do the game justice, as too many people are pushing for a draw, games 17 (the current game) & game 18 (return game, H playing white) wre the only book position played so far won by both engines with white. I guess the starting position is simply won for white, so the Dragon system might be altogether a bust, unlike other kingside fianchettoe lines.

H played better than SF though, pushing g5 instead of Nd5:

[d]3qr1k1/1prbppbp/p2p1np1/6P1/P2NP3/1PN1BP2/2PQ4/1K1R3R b - - 0 19

this is obviously won

so, if we have to talk objectivity, the game was won for white rigth after the opening

User avatar
hgm
Posts: 22083
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Contact:

Re: fortress_draw_rule

Post by hgm » Sun Nov 20, 2016 9:51 am

We could save a lot of time by never playing any moves in any chess game at all, because objectively all games start in a draw position. :lol:

Unfortunately (for you), the result of a game is determined at the end, not at the start or in the middle. It is a remarkable fact that only losers feel the need to point out they had a won position somewhere halfway the game. Like bungling a won position would somehow give them some credit.

Ralph Stoesser
Posts: 408
Joined: Sat Mar 06, 2010 8:28 am

Re: fortress_draw_rule

Post by Ralph Stoesser » Sun Nov 20, 2016 12:04 pm

"FIDE rule 4.1
Each move must be made with one hand only."

Happy coding... ;)

syzygy
Posts: 4179
Joined: Tue Feb 28, 2012 10:56 pm

Re: Cursed win at TCEC

Post by syzygy » Sun Nov 20, 2016 1:09 pm

MikeB wrote: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.
But then you get the problem that 50-move rule draws that happen with 6 pieces still on the board are thought by the engine to be a win. But these 6-piece positions are not TB-adjudicated by TCEC, so they have to be won over the board and that will not work (even with the 50-move rule disabled the losing engine will make sure to keep the draw).

So what TCEC would need are 5-piece tables that ignore the 50-move rule, and custom-built 6-piece tables that do take into account the 50-move rule as long as the 50 moves happen before a conversion to a 5-piece position. This is not a very satisfactory situation.

The same applies to ICCF but with 5 replaced by 6: they need 6-piece tables that ignore the 50-move rule and custom-built 7-piece tables that take into account the 50-move rule as long as the 50 moves happen before a conversion to a 6-piece position.

Post Reply