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.
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.
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
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
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?
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 10:45 am, edited 1 time in total.
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
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.
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.
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.
