Cursed win at TCEC

[Evert]

I always thought it very unjust when I am two Pawns ahead in an end-game with unlike Bishops, and cannot make any progress towards a win because the opponent is blocking my Pawns on the other color than my Bishop. It is really unfair that I am not allowed to put my Bishop on the other color. An advantage of two Pawns obviously is enough to make it a totally won position, and this artificial rule that constrains my Bishop to one color spoils it. If we organize an engine tourney we should certainly adjudicate such positions as a win for the side with more Pawns, if it could be won by stepping the Bishop to teh other color!

Why go through all that effort? Just adjudicate the position as a win when the score reaches +2.
I'm not sure that both engines need to score it as +2 either. I think only the winning engine has to show the winning score. After all, it's possible that the other engine just lacks this knowledge.

Now excuse me while I go and add a "score multiplier" to all of my engines.

[hgm]

Actually I seriously considered doing the opposite: use a 10-fold score divider for negative scored. When I learned that CCRL habitually adjudicates dead draws as losses just because your engine prints too negative a score, I figured this could bring in some cheap Elo.

[syzygy]

5) rule is simple to implement and without detriment to the overall game development; you split the rule into 2 portions, one concerning the general 50-moves rule for the standard game situation, not to make the game too long, and a second one providing for the specific case of pawnless endgames, where the 50-moves rule will be adjusted to 100-move rule or higher, to accomodate the won endgames. Very simple.

So you get dozens of rules for specific endgames that change as more TBs are being generated and as more specific endgame positions are being solved by Freezer- and Finalgen-like programs. Nobody will be able to keep track of that, but never mind. Simple yes, but only if you prefer to be very naive.

6) Rules change with progress. Until we knew there are tbs wins longer than 50 moves, the 50-move rule was adequate, now, when we know there are such longer wins, the 50-move rule becomes outdated and should be changed.

So FIDE has done that already and came to regret it for the obvious reasons already stated. They therefore reverted to the exceptionless 50-move rule, which just works and is fair and predictable.

[syzygy]

The game was already a white win: SF had been showing 105cps from the early mg, Houdini some 80cps. That is a win, however you would like to look at it.

So evaluating a position at +0.80 constitutes a win? This is new to me.
I for one don't think this is a rule that should be adopted.

SF quickly reached +1.05 and got stuck there:
[D]2r1r3/p2b1kbQ/1p1ppqp1/6P1/P2N4/1P2BP2/2P5/1K1R3R b - - 0 24
8 moves later H5 reached +0.77, which was the worst score it showed throughout the game:
[D]6r1/p4kbQ/1p4R1/3p1bP1/P7/1P6/K1r5/3R4 w - - 2 32

If +1.05 / +0.77 "proves" a win, then this proof was based on the 50-move rule being fully in force:
- the tree search of both engines know about the 50-move rule;
- the TBs they probe know about the 50-move rule.

So very clearly the scores shown by the engine are not at all proof of a win for white. Neither engine could possibly have known that a drawn 5-piece position was going to be adjudicated as win. They both knew very well that that 5-piece position was in fact a draw by the 50-move rule. Yet the game ended up in that position (with both engines correctly showing 0.00).

It is still possible that the position at, say, move 32 was a win for white when ignoring the 50-move rule, but the engine could not see that. 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.

Code: Select all

info depth 54 seldepth 116 multipv 1 score cp 114 nodes 32395314823 nps 23356138 hashfull 999 tbhits 116729831 time 1387015 pv a2a3 f5g6 d1f1 f7e7 h7g8 g7b2 a3b4 b2c3 b4b5 g6d3 b5c6 c3e5 c6b7 c2c7 b7a8 d3f1 g8d5 e5d6 g5g6 f1a6 g6g7 a6b7 d5b7 c7b7 g7g8q b7c7 g8g7 e7e6 g7d4 e6e7 d4e4 e7d7 e4d5 d7e7 d5g5 e7e6 g5g6 e6e7 g6g8 a7a5 g8d5 e7d7 d5f5 d7e7 f5b5 d6c5 a8b8 c5d6 b5e2 e7d7 e2g4 d7e7 g4e4 e7d7 e4h7 d7e6 h7h3 e6f6 h3f3 f6e6 f3e3 e6d7 e3h3 d7c6 h3g2 c6c5 g2f2 c5c6 f2f3 c6d7 f3f7 d7c6 f7e8 c6d5 e8g8 d5e5 g8g3 e5e6 g3e1 e6d7 b8a8 d7c6 e1h1 c6d7 h1d5 d7e7 d5f5 d6c5 f5e5 e7d7 e5f6 c5d6 f6f7 d7c6 f7c4 c6d7 c4b5 d7e7 b5e2 e7d7 e2g4 d7e7 g4g6 d6c5 g6g3 c5d6 g3e1 e7d7 e1e4 d6c5 e4e5

Even if white did have a winning position when ignoring the 50-move rule, the 50-move rule was in place and black made use of it, so black simply deserved to draw.

I wonder if without the adjudication, anyone would have considered the 50-move draw that would have been played out on the board to be unfair. (Actually, it would not have been played out as the TCEC draw rule would have kicked in long before.) To be honest, I do not wonder about this because I am sure that nobody would have seen anything unfair in it.

[zenpawn]

Is there agreement among the Stockfish devs that it should have been a draw? If so, perhaps they could write the TCEC organizers and express their desire to have it scored the way both engines saw it.

[hgm]

Why would it be relevant what the Stockfish devs think, or what the engines see? Since when is the score earned by a Chess game determined by what the players think, rather than what happens on the board?

[zenpawn]

Why would it be relevant what the Stockfish devs think, or what the engines see? Since when is the score earned by a Chess game determined by what the players think, rather than what happens on the board?

LOL. Never heard of a draw by agreement?

[hgm]

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.

[syzygy]

The position reached at move 59 was a complete draw with and without the 50-move rule:
[D]4r3/K7/1P6/P2Q3b/7k/4b3/8/8 b - - 0 59
At move 64, black played Kg3 which is fine when using the 50-move rule, but which on my PC lets the eval rise to +0.88 when Syzygy50MoveRule is set to false. Probably still a draw, though.

At move 65, black "loses" the game with 65...Re5:
[D]K5Q1/4r3/1P6/P7/5bb1/6k1/8/8 b - - 12 65
With 65...Re6 the eval would have remained stuck at +0.88.

H5 played 65...Re5 only because it knew it would draw.

[zenpawn]

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.