UCI nullmove

[Sven]

Extending your reasoning we could also say that in mate position the engine can send also "bestmove a2a4" or "bestmove d2d8" and the effect is the same.

I don't think so, unless the GUI would detect by itself that these moves are actually illegal. In the normal case, since the UCI spec does not talk about illegal moves, an UCI GUI would have to forward these moves to the opponent which would obviously break something. On the other hand the GUI should not forward "0000" to the opponent, knowing that the null move would always be illegal.

But nevertheless although the final effect is the same I think is more appropriate to _not_ send a random move (also 0000 is a move) that, given the current position, turns out to be illegal and so discarded. I think is more appropriate to send something that could not be interpreted as a move and so is discarded early on, on a pure semantic level, without requiring a validation against the current position's state.

The reason why I prefer to explicitly state that no move is possible through the use of a string like, for instance, "bestmove (none)" is because it is more clear and less ambiguous especially in the eye of the casual reader. If you read the posts of this thread you can easily spot how "bestmove 0000" could lead to misunderstandings on _why_ the GUI reacts in the correct way (but for the wrong reason) and for many people it is difficult to grasp the difference between a pseudolegal move that turns out to be illegal and a string that is not a pseudolegal move like "(none)", and they incorrectly conclude that "bestmove 0000" is the _correct_ way for the engine to answerer the GUI in case of stalemate.

As I already wrote, I can agree on your preferences here, even though I don't quite believe that anyone could see "0000" as a pseudolegal move.

Sven

[Sven]

which is valid. So a parser should wait for the next line of input to see if there is a valid move on it, because that will be the move it should process. In practice, this next line will of course never come...

NO !

Please read better the specs:

Code: Select all

* all command strings the engine receives will end with '\n',
  also all commands the GUI receives should end with '\n'

So in case of you example:

Code: Select all

bestmove (none)
e2e4

What a correct GUI should parse is:

Code: Select all

bestmove (none) '\n'   -->  bestmove --> command received with missing argument, do nothing.

e2e4 '\n' -->  unknown command, do nothing.

Fully agreed, except for the "do nothing" in case of "bestmove (none)": the "bestmove" command itself must be recognized as being present even if it has no valid argument, so that the reply to "go" is found. The only two things that will be ignored are unknown command keywords and unknown parameter tokens.

Sven

[hgm]

Code: Select all

* all command strings the engine receives will end with '\n',
  also all commands the GUI receives should end with '\n'

Unfortunately this does not solve anything. Because it does NOT say that a command cannot contain internal linefeeds. It only says that each command ends with '\n'. That is NOT the same as that every '\n' ends a command.

Like has already been pointed out by several others, the UCI specs simply suck in the extreme.

[Sven]

Code: Select all

* all command strings the engine receives will end with '\n',
  also all commands the GUI receives should end with '\n'

Unfortunately this does not solve anything. Because it does NOT say that a command cannot contain internal linefeeds. It only says that each command ends with '\n'. That is NOT the same as that every '\n' ends a command.

Like has already been pointed out by several others, the UCI specs simply suck in the extreme.

This is wrong. "all commands ... end with '\n' ..." also means that a '\n' definitely terminates a command. If you don't assume this then no command line oriented protocol would be possible since the receiver would never know whether he has received all parts of a command. '\n' is the command termination symbol (technically possible as '\n' character, '\r\n' sequence, or similar, as UCI specifies), and you can't discuss this away.

Harm-Geert, you know well that I prefer the WinBoard protocol over UCI, too, for various reasons. But I propose that you give up to say that "UCI sucks". It is simply a different protocol that has its advantages and disadvantages, and some of the disadvantages may be the inability for engines to resign, claim draws, claim illegal moves, and have other options for controlling the game. It is a different philosophy behind the protocol: the GUI has full control, and the engine is the "calculating slave" that is given calculation (search) jobs with the "position ..." and "go ..." commands. You may dislike that - I agree, I dislike it, too, and I continue to be a WinBoarder. But the definition of the UCI protocol, based on that philosophy, seems very consistent to me, including the (obviously intended) lack of explicit ways for an engine to deal with end-of-game situations at the interface level.

The "specification" that UCI obviously provides for "end of game" is: in a real-game situation a GUI should not assign a search job to an engine in and end-of-game position; if it does so then it is not a real game; therefore the end-of-game scenario needs no artificial specification and can be handled by the "default rule" that says that the GUI will ignore any unknown response, or unknown part of it, by the engine. That is dumb but helps to keep the protocol as simple as it is.

This is my view of it, YMMV.

Sven

[hgm]

This is wrong. "all commands ... end with '\n' ..." also means that a '\n' definitely terminates a command. If you don't assume this...

You contradict yourself from the very beginning. If itreally means this, there is no reason to assume anything.

So you know very well that it does NOT mean this, as anyone who understands English would know.

But this just proves my point: the UCI 'specs' are in fact completely useless when taken literally. The only way to give them any value is use common sense to fill in the (many) gaps, using interpretations like "it says A, but it obviously cannot mean that, because that is ridiculous and would not work, so it probably means B in stead, because it only slightly contradicts it, and would work great".

And that of course opens Pandora's box of creative interpretations...

If that is the game now, it is indeed obvious to me that it is meant that '\n' is a command terminator, but equally obvious that 'null move' just means 'not doing a move where one was expected'.

With a 'common-sense approach' rather than a 'lawyers approach', allowing everyone to invent and use their own keywords for situations not explicitly addressed in the 'specs' must surely be considered bad, as it makes very little sense at all.

N.B.: I did NOT say UCI sucks, I said the specs of it suck. They just do not unambiguously specify a protocol. Which is why we can have silly discussions like this one...

[hgm]

... then no command line oriented protocol would be possible since the receiver would never know whether he has received all parts of a command. '\n'

I also don't agree with this, btw: Commands could be perfectly defined in a way that each command starts with a keyword has a known number of arguments, so that it is always clear when a command is complete. Only commands with optional parts or a list of undetermined length would suffer from the problem you mention, and even then extra linefeeds would only be fatal in some positions, not all.

In fact extra linefeeds would hardly effect UCI anywhere. Even when you would split the list of moves, the parser could simply think "Hey, this line starts with a move. Apparently the list of moves was not complete, let's add some more to the position we already set up". Because the position/moves command does not require a response, so the parser must wait for the next command anyway. Only within the go command it can get tricky, and excess linefeeds could cause you to miss an inc value, because you start searching too early.

WB protocol has a similar clause that guarantees commands end in a linefeed, but there it is just a service to the low-level input routine, so it can safely read upto a linefeed without having toknow what you read, and without running the risk the input will block because there is nothing to read. In fact WB protocol does have some multi-line commands. (E.g. the reply to the bk command.)

[Sven]

This is wrong. "all commands ... end with '\n' ..." also means that a '\n' definitely terminates a command. If you don't assume this...

You contradict yourself from the very beginning. If itreally means this, there is no reason to assume anything.

So you know very well that it does NOT mean this, as anyone who understands English would know.

But this just proves my point: the UCI 'specs' are in fact completely useless when taken literally. The only way to give them any value is use common sense to fill in the (many) gaps, using interpretations like "it says A, but it obviously cannot mean that, because that is ridiculous and would not work, so it probably means B in stead, because it only slightly contradicts it, and would work great".

And that of course opens Pandora's box of creative interpretations...

If that is the game now, it is indeed obvious to me that it is meant that '\n' is a command terminator, but equally obvious that 'null move' just means 'not doing a move where one was expected'.

With a 'common-sense approach' rather than a 'lawyers approach', allowing everyone to invent and use their own keywords for situations not explicitly addressed in the 'specs' must surely be considered bad, as it makes very little sense at all.

N.B.: I did NOT say UCI sucks, I said the specs of it suck. They just do not unambiguously specify a protocol. Which is why we can have silly discussions like this one...

I can't help you, sorry.

A Dutch and a German should not involve each other in a fight about their different understanding of English language, so I have to leave you alone with your interpretation of words like "means", "assume", etc. If you want to read things in my post which I did not write then more power to you.

Also you will never know very well what I know very well

On the other hand I know very well that your "common sense" is not "common".

Sven

[wgarvin]

N.B.: I did NOT say UCI sucks, I said the specs of it suck. They just do not unambiguously specify a protocol. Which is why we can have silly discussions like this one...

I also think that the UCI spec sucks, but if we are being fair, clear and unambiguous specification of communication protocols takes a lot of effort. I think SMK was busy writing a chess engine and a GUI and needed them to talk to each other, and so he came up with something that worked for him and then later tried to describe it in a document. I don't think he sat down with the idea to rigorously define a good protocol for everybody to use. [Edit: The winboard protocol has a similar history of having evolved from one particular engine's use, into something more general, and still being saddled with various historical quirks from engines that made different choices about unclear areas of the protocol, etc.] Even if he had originally written a clear unambiguous document with a detailed description of the expected behaviour for every possible corner case, I expect that some chess engine authors would still get some of the corner cases wrong anyway in their implementations.

Real-world GUIs (using either protocol) have to deal with any potential little differences in engine behaviour. If they receive something unexpected, they have to cope with it as best as they can. And the same goes for engines, since there are multiple GUIs for each protocol and they don't all behave exactly the same way.

In principle, it should be possible to write a clear and unambiguous spec for UCI that documents existing practice, provides examples of how corner cases should (and shouldn't) be handled, etc. You could even write a program that unit-tests an engine by sending it various sequences of commands and testing all of the protocol functions one at a time, and verifying that it can understand them and give responses that comply with the spec. In practice, I wonder if anybody has the motivation to do it. Maybe GUI developers who want to see more uniformity in future engine implementations of the protocol..

[hgm]

I can't help you, sorry.

A Dutch and a German should not involve each other in a fight about their different understanding of English language, so I have to leave you alone with your interpretation of words like "means", "assume", etc. If you want to read things in my post which I did not write then more power to you.

Also you will never know very well what I know very well

On the other hand I know very well that your "common sense" is not "common".

Well, leaving that as it may be, WB protocol is still the perfect counter example to what you were claiming, wouldn't you say? Like UCI, it does specify that every command ends in a linefeed, and yet it has commands that contain internal linefeeds, so that a linefeed is not an unconditional terminator of commands. (Did you know that engines can spread out their PV over several lines,in their thinking output?) It is just not the same. Claiming the linefeed is a command terminator is just making up your own protocol. It is not UCI, and in no way is implied by the specs.

[Sven]

I can't help you, sorry.

A Dutch and a German should not involve each other in a fight about their different understanding of English language, so I have to leave you alone with your interpretation of words like "means", "assume", etc. If you want to read things in my post which I did not write then more power to you.

Also you will never know very well what I know very well

On the other hand I know very well that your "common sense" is not "common".

Well, leaving that as it may be, WB protocol is still the perfect counter example to what you were claiming, wouldn't you say? Like UCI, it does specify that every command ends in a linefeed, and yet it has commands that contain internal linefeeds, so that a linefeed is not an unconditional terminator of commands. (Did you know that engines can spread out their PV over several lines,in their thinking output?) It is just not the same. Claiming the linefeed is a command terminator is just making up your own protocol. It is not UCI, and in no way is implied by the specs.

Your attempt to be nitpicking fails miserably ...

You are talking about multiline output. But show me a (WB or UCI) multiline command starting with a keyword defined by the protocol and spanning an arbitrary number of lines, and show me the way how the receiving side has to handle that. You won't be able to. Show me even an example of multiline output in UCI. AFAIK UCI does not have it, all informational output of the engine must start with "info". WB has multiline PV output, I know that, but that is not a "multiline command". A multiline command would need an explicit end-of-command marker, and only in that case you could talk of "internal linefeeds".

Give it up

Sven