Wrong draw claim by Naum 4.2 ?

[Houdini]

You mean that the game result should be a draw, even if the engine loses on time by not playing on ?

Exact, for all practical purposes the N v B position is a draw (like Naum claimed).
Are you sure Naum refuses to play on in this position?

Robert

[Matthias Gemuh]

You mean that the game result should be a draw, even if the engine loses on time by not playing on ?

Exact, for all practical purposes the N v B position is a draw (like Naum claimed).
Are you sure Naum refuses to play on in this position?

Robert

"for all practical purposes" is not a criterion for a GUI to end a game as draw where a mate is possible.

Note that the GUI could have used tablebases to adjudicate as draw, but the tournament organizer has his rules and rightfully so.

ChessGUI cannot know whether EngineX can play on or not after posting an end-of-game claim. Don't limit it to Naum. ChessGUI knows no Naum.


Matthias.

[Tord Romstad]

Of course another question is if the engine should be penalized for protocol violation, even if the claim had been correct (e.g. third repetition). In WB this issue does not come up, as it never deals directly with UCI engines. But from what Tord says I guess that a protocol violation cn only manifest itself in a time loss.

Not necessarily. It could also manifest itself in a crash, or something like "bestmove 0000" instead of a real move, or "bestmove a3a4" where a3a4 is not a legal move. But because of the line from the protocol definition I quoted in my first post in this thread, the GUI has no right to penalize the engine for anything it sends that isn't a UCI command. The engine can print draw claims, resignations, or debug output. It can even yell insults at the opponent, the GUI, or people trolling on the CCC. The poor GUI, if it wants to adhere to the protocol, has to silently endure all this without complaining.

[Tord Romstad]

You mean that the game result should be a draw, even if the engine loses on time by not playing on ?

Exact, for all practical purposes the N v B position is a draw (like Naum claimed).
Are you sure Naum refuses to play on in this position?

Robert

"for all practical purposes" is not a criterion for a GUI to end a game as draw where a mate is possible.

My position here is somewhere between yours and Robert's. Just accepting a "draw claim" (I put it in quotes because it technically isn't a draw claim, but just some output which is not part of the protocol) would not be correct, in general. The GUI should ignore the claim, decide for itself whether the position is drawn, and instruct the engine to play on if it isn't a draw. If the engine now refuses to make a move, it should lose the game.

Given the rules in this particular tournament, however, it seems strange not to adjudicate KN vs KB as an instant draw, regardless of what the engines say. After all, games are adjudicated as drawn if both engines display scores with absolute value less than 0.05 for N consecutive moves after move 60. The probability that such games will end in one side getting mated is several orders of magnitude greater than the probability that someone will get mated in a KN vs KB endgame.

[hgm]

Indeed. My previous answer was based on the assumption that the engine claimed a draw in a compliant way. I do not agree that UCI does not support draw claims. 'bestmove 0000' is a compliant way to express impossibility or unwillingness to play on. In combination with an 'info score 0 cp' this should be taken as a draw claim (e.g. when the engine is stalemated). This is how I treat it in UCI2WB. In combination with negative scores it should be taken as a resignation.

[Thomas Mayer]

Therefore, if we follow the protocol strictly, the string "1/2-1/2 {Insufficient material}" from the engine should therefore be ignored by the GUI.

I agree, the GUI should simply ignore the claim.
And by all means the game result should be a draw.

Robert

You mean that the game result should be a draw, even if the engine loses on time by not playing on ?

Hi Matthias,

I think that the GUI should ignore here the draw claim because Naum is loaded as UCI Engine and therefor this is just a protocol violation. But if Naum loses this on time it should be a loss, definitely. After all it's a bug and you should be treated for a bug. If Naum would act here as a WinBoard engine this would be a wrong result claim and therefor imediately lost. I don't think that GUIs should try to interpret output that isn't part of the protocol.

Greets, Thomas

[Matthias Gemuh]

Of course another question is if the engine should be penalized for protocol violation, even if the claim had been correct (e.g. third repetition). In WB this issue does not come up, as it never deals directly with UCI engines. But from what Tord says I guess that a protocol violation cn only manifest itself in a time loss.

Not necessarily. It could also manifest itself in a crash, or something like "bestmove 0000" instead of a real move, or "bestmove a3a4" where a3a4 is not a legal move. But because of the line from the protocol definition I quoted in my first post in this thread, the GUI has no right to penalize the engine for anything it sends that isn't a UCI command. The engine can print draw claims, resignations, or debug output. It can even yell insults at the opponent, the GUI, or people trolling on the CCC. The poor GUI, if it wants to adhere to the protocol, has to silently endure all this without complaining.

"if it wants to adhere to the protocol" is a key issue.
At least 10% of all WB/UCI would stop working.

[Roman Hartmann]

An UCI-engine cannot claim draw and the GUI should therefore just ignore the draw claim. I don't have Naum and can't test it but I guess it won't crash if the game goes on after this draw claim so the game should either be a draw or just go on. But of course the adjucated loss is ok if Naum indeed crashes after this draw claim (but as stated before I don't think it will crash if the game goes on).

Roman

[Matthias Gemuh]

Given the rules in this particular tournament, however, it seems strange not to adjudicate KN vs KB as an instant draw, regardless of what the engines say. After all, games are adjudicated as drawn if both engines display scores with absolute value less than 0.05 for N consecutive moves after move 60. The probability that such games will end in one side getting mated is several orders of magnitude greater than the probability that someone will get mated in a KN vs KB endgame.

Remember that a capture resets the counter and GUI is not allowed to adjudicate with tablebases.

[Maharadja]

I don't know how to insert a diagram, but i was wondering if naum sees in this study by herbstmann a draw or a win

8/8/7q/8/1Q2Nk2/5p2/8/3bK1b1 w - - 0 0

the solution of the study is:
1Nd6+ Kg3 2Nf5+ Kg2 3Qg4+ Kh1 4Nxh6 f2+ 5Kf1 Bxg4 6Nxg4 Bh2 7Nxf2#