UCI engine authors: Please add support for 'searchmoves'

[Gian-Carlo Pascutto]

Now is UCI a stateless protocol?
Certainly not! No where near! Not by a long shot!

The whole point of the "position" command is to inject a position into the internal state of the engine.
A "go" command only makes sense, if a previous "position" command was received. And so on and so forth!

It's a bit a matter of the protocol definition, but if the UCI spec would have made it explicit that "position" and "go" commands are sent in pairs, this criticism wouldn't hold, would it? (Then there's still the matter of setoption...)

[Michel]

What tables an engine does or does not want to preserve has absolutely nothing to do with the protocol being stateless or not. The protocol doesn't care how your engine works and it's none of its business, which is why it doesn't say anything about it.

Ok fair enough!

UCI engines are stateful but the protocol is stateless. I had failed to see the distinction.

[jesper_nielsen]

Now is UCI a stateless protocol?
Certainly not! No where near! Not by a long shot!

The whole point of the "position" command is to inject a position into the internal state of the engine.
A "go" command only makes sense, if a previous "position" command was received. And so on and so forth!

It's a bit a matter of the protocol definition, but if the UCI spec would have made it explicit that "position" and "go" commands are sent in pairs, this criticism wouldn't hold, would it? (Then there's still the matter of setoption...)

Well ... In my opinion, no ...

By splitting the "position" and the "go" command into two seperate commands, they force a state into the engine. After the "position" command the internal state changes to expect a "go" command.

So a step in the stateless direction would be to combine the "position" and the "go" command.

To be stateless is to be able to process a request based purely on the contents of that specific request.

Also just to point out that stateless is not better. Just different.

Kind regards,
Jesper

EDIT: Removed stupid edit:

[Michel]

So to be completely stateless, the command should say something like: "search this position with these options and with this clock information and with this hashtable and with

You seem to be specifying a stateless engine here. Do we still agree that there is a distinction between a stateless protocol and a stateless engine? It seems a gray area.

We need a definition of a stateless protocol.

Let's try. In my opinion a stateless protocol would be one where the legality of a command does not depend on any prior communication. But the result may.

In that sense even the split between position and go would not make the protocol stateful.

Of course some state remains in the protocol. Such as the fact that you have to start the protocol by sending "uci".

[Gian-Carlo Pascutto]

It's a bit a matter of the protocol definition, but if the UCI spec would have made it explicit that "position" and "go" commands are sent in pairs, this criticism wouldn't hold, would it? (Then there's still the matter of setoption...)

So a step in the stateless direction would be to combine the "position" and the "go" command.

What's the difference from enforcing to send them in pairs? The newline?

[Gian-Carlo Pascutto]

So to be completely stateless, the command should say something like: "search this position with these options and with this clock information and with this hashtable and with

You seem to be specifying a stateless engine here.

No, he's not. The engines have nothing whatsoever to do with this.

Let's try. In my opinion a stateless protocol would be one where the legality of a command does not depend on any prior communication. But the result may.

Nothing can depend on prior communication - that's the definition of stateless, i.e. nothing can be remembered. So you shouldn't get a different result.

Of course some state remains in the protocol. Such as the fact that you have start the protocol by sending "uci".

This could be considered part of establishing the protocol, not the protocol itself.

[jesper_nielsen]

So to be completely stateless, the command should say something like: "search this position with these options and with this clock information and with this hashtable and with

You seem to be specifying a stateless engine here. Do we still agree that there is a distinction between a stateless protocol and a stateless engine? It seems a gray area.

We need a definition of a stateless protocol.

Let's try. In my opinion a stateless protocol would be one where the legality of a command does not depend on any prior communication. But the result may.

In that sense even the split between position and go would not make the protocol stateful.

Of course some state remains in the protocol. Such as the fact that you have start the protocol by sending "uci".

I disagree. But only slightly.

You have a very good point about stateless engine vs stateless protocol!

Stateless protocol:
There is an expectation attached to the "go" command. The GUI expects the "go" command to start searching the position previously received in a "position" command.

So the gray area becomes what is a correct handling of a command?

You say that the result may wary based upon prior communication. And I agree that the "bestmove" returned by the search may well differ, but the actual position searched cannot.

The context of the "go" command is the "position" command. And the engine must not break that context. That context is the "state" of the protocol.

Kind regards,
Jesper

Edited to clear a few points.

[Michel]

No, he's not. Again, the engines have nothing whatsoever to do with this.

He did specify the content of the hash table which I guess should be considered engine state.

So you shouldn't get a different result.

But you might because the content of the hash table might be different. So if you do a search and then repeat it, the second time the search might go deeper (because of the filled hash table) and may yield a different resultt.

The point is that engine state definitely influences the result of commands. So command results cannot be used to define a "stateless protocol" (if you want to make a distinction between the engine and the protocol).

[Gian-Carlo Pascutto]

No, he's not. Again, the engines have nothing whatsoever to do with this.

He did specify the content of the hash table which I guess should be considered engine state.

He didn't talk about the content. The GUI needs to set the *size*. This is needed because this part of the protocol currently is clearly not stateless (setoption blah has to remembered). This was pointed out several times above.

So you shouldn't get a different result.

But you might because the content of the hash table might be different. So if you do a search and then repeat it, the second time the search might go deeper (because of the filled hash table) and may yield a different resultt.

The point is that engine state definitely influences the result of commands. So command results cannot be used to define a "stateless protocol" (if you want to make a distinction between the engine and the protocol).

Ah yes, now I understand you. The "result" in terms of the protocol is what the engine does as a result of receiving the commands. Not the move and score. Putting requirements on the latter invariably means that you're defining the engine too, which should be outside the scope of the communication protocol.

[hgm]

UCI is not stateless within lines.
Only after receiving a full line with a complete command it gets back into the same state. What is on the first half of the line might effect the result on what is on the second half very much.