hgm wrote:Not after the game. No draw as offered during the game. It is also not possible for non-players to offer draw on behalf of a player. Not even during the game.
In a sense, it was.
Think of it like an "instant replay" in tennis or football, where a call/adjudication is often corrected upon reviewing more detailed information.
So that confirms what I stated earlier: the game was a dead draw under any rule, and Houdini did not care whether it would do moves that would keep the draw without 50-move rule as long as it would keep the draw with 50-move rule. So not paying any attention to it, it happened to do a move that would be losing without 50-move rule. Had the game continued, Stockfish could equally easily have played a move that would again 'blunder away' the win without 50-move rule, as it would not pay any attention to it either.
zenpawn wrote: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...
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.
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.
syzygy wrote:(...) 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.
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.
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