UCI engine authors: Please add support for 'searchmoves'

[hgm]

I always wondered why a command like ucinewgame would be needed in something that is supposed to be a stateless protocol...

[Gian-Carlo Pascutto]

I always wondered why a command like ucinewgame would be needed in something that is supposed to be a stateless protocol...

There is no need for it, but you can ask the protocol author why it was added, the answer will be funny

[Gian-Carlo Pascutto]

The last problem would have been solvable in a more generic manner if uci had support "go window [x,y]" of something like that. In fact, you could do many more interesting things if UCI had supported that :-/

I'm sure that Victor would be interested in hearing suggestions which would make IDeA (and other such analysis) more flexible and/or efficient, even with extensions to the UCI standard.

An obvious use for the "go window" feature would be to speed up IDeA analysis. If IDeA knows the move will only be added if it's score is at least x, it can put that as a lower bound.

However this needs engine support.

As described above it also makes searchmoves redundant.

In fact, I think that Rybka's MultiPV_cp was his idea.

Those things are useless, just like sampled search or MC analysis: the protocol is not documented so no way to implement them for other engine authors.

[Desperado]

- deosnt support ucinewgame (definitely)

ucinewgame was added to the UCI protocol a long time after the specification was published. It's perfectly OK for a GUI to not use it and still claim UCI support. You cannot write a GUI to support things which aren't even specified yet! Likewise it's never needed to support optional frills to claim protocol compliance.

An engine which needs this command to work correctly is simply broken, because you cannot depend on it being sent. A new GUI may send it for your convenience but there certainly isn't any requirement to do so.

If after reading this you think there's no point in having the command in the first place: you're right!

I always wondered why a command like ucinewgame would be needed in something that is supposed to be a stateless protocol...

There is no need for it, but you can ask the protocol author why it was added, the answer will be funny

Well, i know that ucinewgame-command was added later. Ok, this example isnt the best,
because the command doesnt belong to the standard uci-protocol.

But why not keeping implementation of the protocols up to date ?
(At least for the most commercial chessbase GUI,i would expect that,
and it s a little bit dissapointing in my eyes.
As further example, my engine was playing games online against
a club friend, and moved absolut unexpected immediatelly, after
some moves of him (nonsense moves of my eng). I figured out that my
engine was _pondering_ because the gui send the position+go command
while human was thinking, and my engine had switch off _real ponder_.
That sth like this can make trouble is easy to follow i think.)

Further it is hard to say, if some of the commands make sense
or not. There was surely a _good_ reason for adding a new command
like ucinewgame as example.

Of course my engine doesnt depend on ucinewgame, but if it
would be supported by standard, it would make some things much easier.
It (ucinewgame) can be useful for a lot of things, like cleanup operations before starting a newgame(hashtables as example),
learning algorithms and i am sure, there can be a lot more things to do.

The point is, that with standard-uci a new game is not so easy to identify as one may think at the first moment!
i'm sure that the first 3 approaches to identify a newgame position with
only having, let s say an iternal movelist(gamelist) and the position-command (fen+movelist), i will give you exceptions you didnt think of before.

But one question is left for me now, i dont know the expression
"stateless protocol", what does that mean exactly ?

cheers

[Michel]

I always wondered why a command like ucinewgame would be needed in something that is supposed to be a stateless protocol...

UCI is not entirely stateless in the sense that it is not specified what should happen to the hash table between searches (it is a good thing to preserve it).

In Toga ucinewgame just clears the hash table.

[hgm]

Even on starting a new game one could argue that it would be better to preserve the hash table. Only when you play a new variant it becomes essential to change it. (And Chess960 is not really a new variant, of course, so even there it does not hurt to keep the hash table, provided you do a true key calculation in the opening positon.)

[Gian-Carlo Pascutto]

I always wondered why a command like ucinewgame would be needed in something that is supposed to be a stateless protocol...

UCI is not entirely stateless in the sense that it is not specified what should happen to the hash table between searches (it is a good thing to preserve it).

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.

What makes uci stateless (compared to xboard) is that you get the full position, movelist and timing information each time. What makes UCI not fully stateless is that you have to remember the "setoption" settings, because you will not get them for each "go".

You can have a stateful engine working with a stateless protocol or the reverse. The wb to uci (and reverse) adapters are the proof of this.

[Gian-Carlo Pascutto]

But one question is left for me now, i dont know the expression
"stateless protocol", what does that mean exactly ?

A "stateful protocol" (the opposite of a stateless one) means that the protocol presumes your engine has some state (like the a board position, a game history, the clocks) and that it must manipulate this state. So if you there is a new move in xboard (a stateful protocol), the GUI "knows" that you already have some state (the board up to this move) and will execute the commands needed to transform into the next state (the last move). To be able to do this the GUI needs to know both its own state, but also the state of your engine.

In a "stateless protocol" the GUI doesn't have to remember the state of your engine at all. It will essentially reset the entire state for each command (in UCI via position fen moves blalba). This does mean it needs to transmit the state for each command.

The disadvantage of a stateless protocol is that it is more verbose. The main advantage is that it's easier to work with (the state transitions can get quite tricky, and it's hard to recover if you miss once).

[Desperado]

But one question is left for me now, i dont know the expression
"stateless protocol", what does that mean exactly ?

A "stateful protocol" (the opposite of a stateless one) means that the protocol presumes your engine has some state (like the a board position, a game history, the clocks) and that it must manipulate this state. So if you there is a new move in xboard (a stateful protocol), the GUI "knows" that you already have some state (the board up to this move) and will execute the commands needed to transform into the next state (the last move). To be able to do this the GUI needs to know both its own state, but also the state of your engine.

In a "stateless protocol" the GUI doesn't have to remember the state of your engine at all. It will essentially reset the entire state for each command (in UCI via position fen moves blalba). This does mean it needs to transmit the state for each command.

The disadvantage of a stateless protocol is that it is more verbose. The main advantage is that it's easier to work with (the state transitions can get quite tricky, and it's hard to recover if you miss once).

Thx for explanation

[jesper_nielsen]

... <snip> ...

But one question is left for me now, i dont know the expression
"stateless protocol", what does that mean exactly ?

cheers

A stateless protocol is one where requests are handled completely independent of each other.

A simple example is most webservers I guess?! Each request is handled completly independent from one another.

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!

But the basic idea of the UCI protocol smells a bit like something stateless:
The engines are fed positions and they return a best move. And that is it!
The engines do not "need to know" anything about the relation of the positions to one another. So the concept of a game is removed from the engine and given to the GUI.

So the engine becomes kinda stateless, in the sense that the way it treats each position is always the same.

Note to non UCI people: A position can and often will contain game state information about the game it is currently in through the data in the "position startpos moves <game moves here>" command.

A bit of a longish reply to a very simple question! Sorry!

Kind regards,
Jesper

EDIT:
Doh! Damn my slow fingers and brain!