UCCI2WB

[Evert]

Besides that, there are users who want to see an engine to play, say, Elephant's gambit, and it is better if they have to learn one solution per GUI than one solution per engine.

The decision to handle book moves in the engine or the GUI has very little to do with what protocol is used to communicate between the two, even if the default assumption in UCI is that the GUI handles the book and the default assumption in CECP is that the engine does. In UCI you have the option "OwnBook" that lets the engine use its own opening book, in CECP you have force mode to set up an initial position. This is very much an implementation detail that the end user of a GUI should never have to worry about. A GUI should work exactly the same whatever the underlying communication protocol.

[hgm]

Indeed, UCI leaves the possibility for engines to handle their own book completely open. The name of the standard option (Has Own Book) is a bit misleading, as it really means 'Should not use GUI Book'.

I wouldn't even go so far as to say that there are default assumptions. In CECP it was just a default of the XBoard implementation of it that the engine was responsible for handling its own book, because XBoard did not support a GUI book. But it was not something that was encouraged in any way by the protocol, anymore that you could say CECP discourages using engines to play white, just because the 'new' command sets it to play black rather than to force mode.

I am not sure whether Marcel's dissatisfaction with the 'option system' refers specifically to the option feature, or to the feature command in general. The option feature has a bit of an awkward syntax in order to wrap it as something that is backward compatible with the existing protocol. Of the standard features there are a lot that seem superfluous, or even a bad idea. E.g. what is the point in suppressing sending of the 'white' and 'black' command (colors=0)? If an engine doesn't need those, it can just ignore them! And allowing the engine to request the moves to be sent as SAN (san=1) was a very bad idea. (What would engines do if the GUI rejects that feature? Exit immediately? It is just a recipe for creating incompatibilities...) That almost every engine needs to send sigint=0 sigtem=0 is more because this sending of SIGINT and SIGTERM with moves or quit commands is a crazy feature of the protocol in the first place.

It would have been a lot better if some of the defaults had been defined opposite to what they are in v1, so that sending of a single 'feature' command to indicate the engine is v2 would have made the GUI assume automatically that the engine supports the features that made v2 necessary (ping=1, setboard=1, colors=0, sigint=0, sigterm=0).

[syzygy]

For myself, my own programs are never dumb calculators. They're designed so you can play them fairly easily in console mode. As such, CECP is a (much) better match to how they work than UCI is, and I personally prefer CECP for that reason.

There's not really any reason why an engine could not both be usable in console mode and support UCI, even though it seems most UCI engines are unusable in console mode. UCI is very easy to add to any engine.

Do you think the UI could handle time management for the engine? You say it's "somewhat surprising" that this is up to the engine, suggesting that you think it could or should. I'm not sure I believe that.

It's surprising as it goes against the design of UCI. I have said nothing on what it could or should do. Maybe surprisingly, I don't like UCI myself. But I can be objective about it instead of calling it broken or worse (not that you did that). It is quite evident that UCI filled a need and has been an enormous succes as chess engine protocols go.

People say that UCI is a "stateless" protocol where the engine just gets told what to do and does not have to remember anything in between. This is certainly not entirely true in practice (leaving aside the question of whether it really is meant to be or not) because in order for it to be people would have to clear out their transposition tables and killer tables before each "go" command - which would generally not be a very good idea.

I'd say that leaves it stateless but nondeterministic. An UCI engine needs no logic to keep track of what happened before.

UCI certainly was designed to be stateless.

[hgm]

Funny... I cannot be objective and call it not broken at the same time!

I'd say that leaves it stateless but nondeterministic. An UCI engine needs no logic to keep track of what happened before.

UCI certainly was designed to be stateless.

And then 'ucinewgame' was added to destroy all that.

[Evert]

There's not really any reason why an engine could not both be usable in console mode and support UCI, even though it seems most UCI engines are unusable in console mode. UCI is very easy to add to any engine.

Sure. Jazz can be switched to either CECP and UCI modes. However, its CECP mode is just its normal mode minus some goodies like a prompt, a board and SAN moves.

It's surprising as it goes against the design of UCI. I have said nothing on what it could or should do. Maybe surprisingly, I don't like UCI myself. But I can be objective about it instead of calling it broken or worse (not that you did that). It is quite evident that UCI filled a need and has been an enormous succes as chess engine protocols go.

There very clearly has to be a line between what the GUI can do and what it has to let an engine do - otherwise the GUI could just play the entire game (which I guess would just make the engine an integrated part of the GUI). Evidently time-management fell to the engine side of the protocol, while table-base management did not, but I wonder how that line could be drawn differently, since there is very clearly a grey area here.
Evidently UCI fills a niche, since people use it (and honestly - it's good if there's more than one option) and in facto use it for things it was not originally designed for. Which gets us back to UCI dialects and chess variants.

I'd say that leaves it stateless but nondeterministic. An UCI engine needs no logic to keep track of what happened before.

Maybe. Even so, "position" and "go" are different commands, so there's still state that has to be retained between commands. I would not really call it stateless, but that's probably just semantics. It certainly expects less bookkeeping from the engine than CECP (which doesn't actually expect as much as it seems to from a first glance at the specs).

[hgm]

Actually it has to do just as much book keeping, because the 'statelessness' is only an illusion brought about by selling something as a single command that in reality is a whole bunch of commands. To claim staelessness it is already necessary to consider position, moves and go as a single command, as you remarked. But of course the moves have to be loaded one by one, and during that loading, an UCI engine has to keep track of exactly the same stuff as a WB engine would. The only difference is that in CECP the side played by the engine is persistent, rather than requiring a 'go' command for every move you want the engine to do. Which, seen from the engine, is really a very minor difference.

And of course there are many things that are persistent across moves in UCI as well. In particular has-table size, whether you are pondering, multi-PV setting, whether book is on or off etc. all have to be remembered, and are not re-send every move.

[syzygy]

The only difference is that in CECP the side played by the engine is persistent

Is there any advantage in keeping track of the side played by the engine?

I think it makes a lot of sense to have the engine at least keep track of the board and game state, so the GUI does not have to keep sending full moves lists. But not having to keep track whose move it is and just waiting for a "go" command seems a major simplification to me, and one that does not complicate the GUI at all. The GUI knows when the engine is supposed to start calculating. Having the engine decide this as well can only be a source of bugs.

The engine could still choose to keep track of which side it is playing if that is somehow necessary for game playing decisions or whatever, but it would always obey the GUI: the GUI makes/unmakes all moves and if only if the GUI says "go" it calculates and returns a best move.

[hgm]

Is there any advantage in keeping track of the side played by the engine?

Not that I know.

In fact it is the thing I find most annoying in CECP. The stand-alone version of micro-Max, and my earlier engine Usurpator, always needed an explicit command (an empty line) to move, and that simplified the logic of the interface a lot. I must admit that it was a constant source of confusion for the users, though: they type "e2e4", and the wait forever, because they somehow expect the computer to understand it is playing black now, and move spontaneously.

I just mention it because in the end it is the only thing that is truly different between UCI and CECP. That you would to keep any less state information in UCI because the entire game is reloaded on every search is an illusory difference, as during the loading you have to keep exactly the same state information. You would not really need to add any code to the protocol driver of an UCI engine to adopt the convention that 'position' can be left out, and that in that case the initial position on which the 'moves' command starts to operate would be the position left over from the previous 'moves' command. (You probably would only have to delete code to do that!) And that would already make it very CECP-like (and easily usable from the command line), except that undos would still be cumbersome. (But in fact easy for the engine, as it is how they do their undos internally anyway, but now they have to remember the game history by themselves, and fake that they receive it through the interface.)

This reminds me of the times when I was participating in OTB tournaments with the computer build in the matchbox. Of course operator errors were common, so you frequently had to perform 'undo', and with only a single 'key' on the machine, that was a problem. So I had implemented 'new game' by a >5sec press on the key, ('position statpos', as it were), which then went over into automated 2Hz counting (0 - 1 - 2 - 3 -...) in the display. By releasing the key when the right number came up, it would feed just that number of moves from the game history of the previous game to chess program, in lieu of a 'moves' command.

[Evert]

The only difference is that in CECP the side played by the engine is persistent

Is there any advantage in keeping track of the side played by the engine?

Well, yes.

I don't know about you, but I don't want to make a move and then have to tell my opponent that it's their turn.

Of course I'm making an implicit assumption here: that I'm playing a program directly. Evidently if there's an interface in between it's not necessary at all, and you could always wait for a "go" command - but XBoard (and CECP) started as a graphical front-end to GNU Chess, which obviously (and necessarily) did not wait to receive a "go" when it was on move, which is how it ended up as it did. I suspect that if one designed a protocol from scratch one would not design it this way (I certainly wouldn't).

The GUI knows when the engine is supposed to start calculating. Having the engine decide this as well can only be a source of bugs.

But the GUI does know when the engine is supposed to start calculating: if it's on move and not in force mode.

The engine could still choose to keep track of which side it is playing if that is somehow necessary for game playing decisions or whatever, but it would always obey the GUI: the GUI makes/unmakes all moves and if only if the GUI says "go" it calculates and returns a best move.

Note that in CECP the GUI can always switch the engine back into force-mode after it's played a move. That makes it behave as you suggested.

[hgm]

I don't see this 'possible source of errors' as a serious problem. No matter what system you use, you can always get the state of the engine wrong. In UCI the GUI also has to remember whether the engine is pondering, and on what move, in order to decide whether it should send 'ponderhit' or 'stop - position -moves - go'. In CECP you have to to know whether it was in force mode or not to know what to send. In both cases, if you did not get it right, it won't work.