UCI engine authors: Please add support for 'searchmoves'

[Michel]

You're confusing the protocol with the engine. The result from the protocol commands (the engine starts searching on a given position) should be the same. The result from the engine (bestmove and score) could be anything, and certainly isn't defined by the communication protocol.

Well I just want to understand your definition..

If only the syntactic form of the reply is relevant why do you say that setoption commands constitute a deviation of statelessness?

EDIT: Just read your last post

and it's clear that this includes respecting the setoption commands, but provides no guarantee for reproducible output or for any specific implementation of finding the best move (such as return movelist[random() % num_moves]) Smile

"It is clear" has no place in a definition....


But I guess I understand what you are trying to say. The protocol description should include a description of engine state and how the protocol manipulates it. But the engine is free to maintain other state which is not part of the protocol.

Whether a command is legal or not is independent of the state of the engine or prior history.

The protocol should also specify certain formats for the engine reply leaving certain parts free for the engine to fill in (but imposing certain requirements such as legality).

[Gian-Carlo Pascutto]

If only the syntactic form of the reply is relevant why do you say that setoption commands constitute a deviation of statelessness?

Because if you arrive at this syntactically valid reply while ignoring the setoptions commands, you won't do what the GUI intended. Setoption specifically says it will affect engine internals. At that point, they are no longer solely the engine's business.

(In practice, you might not even get to the part where you can reply if you ignored what the GUI told you, such as, don't use more than xMb of memory).

[Michel]

Well I understand what you are trying to say but making it formal seems tricky.

Obviously one cannot talk about things like "the engine's business" or the "GUI's business".

Mathematically setoption commands just manipulate key/value pairs in the engine.
So they do not affect the statelessness of the protocol.

[jesper_nielsen]

Setoption specifically says it will affect engine internals. At that point, they are no longer solely the engine's business.

Now I am not following you again. Setoption commands only affect the engine state. So according to your POV they do not affect the statelelessness of the protocol....

Sorry for nitpicking but it would really be nice to get this straight.

Here is the way I see it:
UCI is not stateless. It is statefull because the "go" command relies on a number of previous commands. Most notably the "position" command but also any "setoption" commands.

The options are basically promises the engine makes to the GUI.
"If you set this option to this or that, then I will change my behaviour accordingly."

What the "go" command asks the engine to do is basically this:
"Given the options previously set, and the position previously set, please find what you believe to be the best move using the time you find appropriate given these time levels."

The GUI expects the engine to use the position provided and to respect the options set.

So the protocol is more than just the actual reply and command structures. It is a number of promises about behaviour.
And of course there are no guarantees that the engine will "do as it is told".


So to spin completely out of control:

One of the basic differences between the xboard and the UCI protocols, is that the UCI protocol splits the action of playing a game of chess up into a number of positions for the engine to search.

This splitting up also means that the concept of "playing a game of chess" is missing! This means that stuff like learning becomes a problem. There is no room in the protocol to "reflect on the game just played and learn from it.".

The engine is bound by the protocol!

If the engine does any of this, it is breaking the protocol.

It is of course possible for the engine to try and do it anyway. But then the results are not clear. The GUI is free to jump between games, roll back as many moves as it will, force the engine to play a bad position, etc.

Just for the record: I love UCI for its simplicity.

When I started writing my first chess engine, UCI was a blessing! basically I had to support two commands, and the engine was up and running in Arena! Brilliant!

Is UCI specified so there is no doubt about how to implement it? No!
It is simple enough to make stuff work. The rest of the details are worked out between the implementors of the engines and the implementors of the GUIs.

Kind regards,
Jesper

[hgm]

When I started writing my first chess engine, UCI was a blessing! basically I had to support two commands, and the engine was up and running in Arena! Brilliant!

With only four commands you could also have a WinBoard engine running (level, go, time, and a move) . The only difference is that they would be _simple_ commands, not cheating you by presenting new + any number of moves or go + time like it was a single command...

For any amount of functionality it would be _far_ simpler to implement it in WB protocol than in UCI, both in terms of the amount of code you need and how often that code has to be executed.

[Gian-Carlo Pascutto]

and it's clear that this includes respecting the setoption commands, but provides no guarantee for reproducible output or for any specific implementation of finding the best move (such as return movelist[random() % num_moves]) Smile

"It is clear" has no place in a definition....

Where do you see a definition? I'm explaining you that if the engine, via the protocol, provides for a way to set certain engine options, and the GUI sets them, then the engine should respect them. Because it's the only thing which can possibly make any sense. [1]

Respecting them implies keeping state.

[1] If you think this isn't clear, then I'll gladly admit that indeed the UCI protocol doesn't explicitly state, that if an engine offers the GUI the possibility to change a parameter, and the GUI does that, that the engine should actually change the parameter and not just simply ignore the command. Clearly a gross oversight in the specification.

[Gian-Carlo Pascutto]

Well I understand what you are trying to say but making it formal seems tricky.

Obviously one cannot talk about things like "the engine's business" or the "GUI's business".

We can talk about GUI-visible-state or engine-visible-state but I don't think it will make anything more clear.

Mathematically setoption commands just manipulate key/value pairs in the engine.
So they do not affect the statelessness of the protocol.

For sure they do. These key/value pairs affect how the engine works internally, and the specification says that the user is allowed to change this via the protocol if the engine offers so.

Once the offer is made and the user changes them, they become part of the GUI-visible-state of the engine. And this state needs to be kept explicitly by the engine, because it's not included in each UCI command and the engine is expected to keep respecting them anyways.

So UCI has state.

[Gian-Carlo Pascutto]

Is UCI specified so there is no doubt about how to implement it? No!

What parts are in your opinion ambiguous?

[Gian-Carlo Pascutto]

With only four commands you could also have a WinBoard engine running (level, go, time, and a move) . The only difference is that they would be _simple_ commands, not cheating you by presenting new + any number of moves or go + time like it was a single command...

Unfortunately, a useful engine will need undo, force, go, clock keeping, board setup, ping, analyze mode (urgh!) etc, and I do think all of those things are far simpler in UCI, not to mention functionality which isn't even specified in the xboard protocol...

For any amount of functionality it would be _far_ simpler to implement it in WB protocol than in UCI, both in terms of the amount of code you need and how often that code has to be executed.

Uh, I don't think so.

[Michel]

Once the offer is made and the user changes them, they become part of the GUI-visible-state of the engine. And this state needs to be kept explicitly by the engine, because it's not included in each UCI command and the engine is expected to keep respecting them anyways.

You mean that if there was some way to query a UCI engine for the value of its options then the requirement that the value of the options corresponds to prior setoption commands constitute protocol state. That makes sense. One cannot officially query UCI engines for their options but many options can be determined in other ways (such as Hash size).

The position command adds real state to the protocol through the requirement that the result of the next go command (bestmove/pv etc...) should be legal for the given position.

There is some more real state in the UCI protocol (although not explicitly specified). If the GUI starts a search then probably the GUI should not send any commands except stop or ponderhit until a bestmove is received.

How about the following test? To determine the state contained in the protocol and not in the GUI or engine one should have a third program that observes all communication. The state that this program has to maintain to verify compliance of both engine and GUI is the state contained in the protocol. For the WB protocol this seems to be the entire game state. For the UCI protocol it is much less.

EDIT: Changed engine state to game state.