UCI engine authors: Please add support for 'searchmoves'

[jesper_nielsen]

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

What parts are in your opinion ambiguous?

The part about how the clock is managed. When does the clock start? Before/after the position command? Before/after the go command?

I prepare the search after the position command is received, for example. But how much preperation is ok to do? Is it ok to do a small search to order the root nodes? Is it ok to make the book lookup? Would that be cheating?

Now these are admittedly small issues seen from the engines point of view. But what if I wanted to implement a GUI? Can I just decide for my self?

Kind regards,
Jesper

[jesper_nielsen]

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

What parts are in your opinion ambiguous?

The part about how the clock is managed. When does the clock start? Before/after the position command? Before/after the go command?

I prepare the search after the position command is received, for example. But how much preperation is ok to do? Is it ok to do a small search to order the root nodes? Is it ok to make the book lookup? Would that be cheating?

Now these are admittedly small issues seen from the engines point of view. But what if I wanted to implement a GUI? Can I just decide for my self?

Kind regards,
Jesper

What if a second go command is received after the first search has finished? Are "position" and "go" always as a pair? Or does "go" always refer back to the latest "position" command?

Code: Select all

* if the engine receives a command which is not supposed to come, for example "stop" when the engine is
  not calculating, it should also just ignore it.

Which combination of commands are not supposed to happen?

When should "setoption" take effect?
What if a "setoption name Hash value XX" is received during search? Is it ok to ignore it? Should the hash size be adjusted after the search has terminated?

Kind regards,
Jesper

[Gian-Carlo Pascutto]

What if a second go command is received after the first search has finished? Are "position" and "go" always as a pair? Or does "go" always refer back to the latest "position" command?

These I think are very valid questions, i.e. are you allowed to destroy the current board position after you replied bestmove or not?

Code: Select all

* if the engine receives a command which is not supposed to come, for example "stop" when the engine is
  not calculating, it should also just ignore it.

Which combination of commands are not supposed to happen?

AFAIK, only stop and ponderhit when the engine is not running.

When should "setoption" take effect?

As soon as possible. If the GUI has a specific requirement, it can send "isready" and know that "readyok" implies the setting took effect.

What if a "setoption name Hash value XX" is received during search? Is it ok to ignore it? Should the hash size be adjusted after the search has terminated?

I think you're supposed to handle them during the search. At the very least, MultiPV requires this. I would agree the protocol should have been more clear here, and perhaps allowed specifying what can be changed during the search and what not.

[Gian-Carlo Pascutto]

The part about how the clock is managed. When does the clock start? Before/after the position command? Before/after the go command?

Position contains no clock info, so that cannot be it. The clock is started before the go command, and the engine loses the communication latency.

Other possibilities are just not feasible in practice.

I prepare the search after the position command is received, for example. But how much preperation is ok to do? Is it ok to do a small search to order the root nodes? Is it ok to make the book lookup? Would that be cheating?

Should be the minimal amount of work, but in practice it won't matter due to the coupling of position and go.

[hgm]

As soon as possible. If the GUI has a specific requirement, it can send "isready" and know that "readyok" implies the setting took effect.

Doesn't this add yet another state to the protocol? It seems awfully similar to WinBoard ping / pong to me. Except that the WB method of course is superior, because it actually numbers the pings and pongs.

[Gian-Carlo Pascutto]

As soon as possible. If the GUI has a specific requirement, it can send "isready" and know that "readyok" implies the setting took effect.

Doesn't this add yet another state to the protocol? It seems awfully similar to WinBoard ping / pong to me. Except that the WB method of course is superior, because it actually numbers the pings and pongs.

This doesn't add state. It would have if the pings were numbered!

[jesper_nielsen]

What if a second go command is received after the first search has finished? Are "position" and "go" always as a pair? Or does "go" always refer back to the latest "position" command?

These I think are very valid questions, i.e. are you allowed to destroy the current board position after you replied bestmove or not?

Code: Select all

* if the engine receives a command which is not supposed to come, for example "stop" when the engine is
  not calculating, it should also just ignore it.

Which combination of commands are not supposed to happen?

AFAIK, only stop and ponderhit when the engine is not running.

When should "setoption" take effect?

As soon as possible. If the GUI has a specific requirement, it can send "isready" and know that "readyok" implies the setting took effect.

What if a "setoption name Hash value XX" is received during search? Is it ok to ignore it? Should the hash size be adjusted after the search has terminated?

I think you're supposed to handle them during the search. At the very least, MultiPV requires this. I would agree the protocol should have been more clear here, and perhaps allowed specifying what can be changed during the search and what not.

And now the question becomes:
Should all these have been specified in the UCI protocol description?

Not necessarily I think. From a pragmatic point of view.

If they were to be added, they would "bloat" the specification, sacrificing simplicity of reading. If I were to begin implementing a chess protocol, and was faced with a HUGE document, I think I would pass.

From a pratical point of view, the answer to most of these questions was found in Arena. Start the GUI you want to work in, and observe the behaviour!

Now this would of course not be acceptable, if the protocol was for some high security / nuclear powerplant / fort knox type applications.
But this is a chess playing interface! And from my perspective it is more important to be able to get started quickly than it is to have all possible details specified in the protocol.

Compare the documentation of WB to that of UCI. (At least the ones that were around about three years ago, when I started writing my engine) And there is the reason that I chose UCI over WB.

WB might be extremely simple, but that is certainly not apparent from the protocol description. (Again, at least the ones that I found when looking for them all those years ago).

And mind you, I am not talking about the value of the protocols. WB might very well be a much better protocol than UCI. But from a pure accessibility point of view, I think UCI RulZ!

Again, just my thoughts on it! YMMW!

Pragmatic regards,
Jesper

[hgm]

I agree that the WB protocol specs is awful for a novice. When I first made my engines WB compatible, I never looked at the document. Just to the TSCP source!

I once started a simple tutorial on how to interface an engine to WinBoard, and it is actually hidden somewhere on my website:

http://home.hccnet.nl/h.g.muller/interfacing.txt

I guess it would pay to polish it up a little and distribute it with WinBoard. (And put it on the GNU website.)

Code: Select all

Minimal protocol

The full WinBoard protocol, as described in the document

http://tim-mann.org/xboard/engine-intf.html

looks quite elaborate, but to interface an 
engine to WinBoard so you can play a game against it can already be 
done with the aid of a very small subset of the protocol. The other 
commands your engine can simply ignore.

This minimal subset consists of:

Commands that your engine should understand when it 
receives them on its standard input:
level
new
force
go
<MOVE>

where <MOVE> means the move in coordinate notation (4 characters, 
or 5 when a promotion is involved). Of this, the level command is 
the only one with numerical parameters (specifying nr of moves, 
time in minutes, and time-increment per move in seconds).

'new' tells your engine to setup the board for a new game, and 
consider itself playing the side that will not move first, simply 
awaiting events idly. This means it will start searching 
and doing a move of its own after it receives an input move.

After 'force' the engine will never do any moves itself, just 
accepting moves for the side that is to move, one after the other 
(keeping track of who is to move), and performing them 
on its internal board.

'go' tells the engine to start playing for the side that now has 
the move (regardless of what it was doing before), and keep 
spontaneously generating moves for that side each thime that side 
has to move again.

All other commands are best ignored without comment: officially 
you have to print an error message if the engine receives a 
command it does not understand, but if it understands only so 
little that would just confuse the GUI. So better save that for later.

commands that your engine has to send to the GUI, 
on its standard output:
move <MOVE>

The only thing you have to send the GUI is the moves, preceeded 
by the keyword 'move'. The engine only has to do it when the 
side it is playing (as told by the most recent 'new', 'force' 
or 'go' command) has to move.

...

[Michel]

This doesn't add state. It would have if the pings were numbered!

Well there is no requirement that the pings be numbered consecutively...

The fact that a pong has to have the same number as the previous ping is similar to
the requirement that a move must be legal with respect to the last position command
which was not considered state of the protocol (assuming that go and position go together).

[Gian-Carlo Pascutto]

This doesn't add state. It would have if the pings were numbered!

Well there is no requirement that the pings be numbered consecutively...

I agree it's legal to just send "ping 1" "ping 1" "ping 1", but if you do that then hgm's argument that the pings are numbered is void.

A similar argument applies if you just send random numbers (and don't store them): you can't actually do anything with them then.

There's also the question of what numbering the pings would actually accomplish in UCI anyway. They are only in the WB protocol to avoid race conditions which UCI doesn't necessarily have.

So basically hgm's supposed advantage serves no useful purpose and would add further state to even have the possibility of doing something useful.

The fact that a pong has to have the same number as the previous ping is similar to
the requirement that a move must be legal with respect to the last position command
which was not considered state of the protocol (assuming that go and position go together).

I'm not sure. If I send a sequence of "ping 1" "ping 2" "ping 3" and get a reply "pong 1" "pong 3" "pong 4", it's a protocol violation directly from it's description in the xboard protocol. The causes of this protocol violation could be the GUI side of the communication getting stuck because it expects a "pong 2" before sending its next command, which it has the right to expect but will not come.

An illegal bestmove wouldn't disrupt the flow of communication, because it has no influence on what the next commands in the protocol can be. A missing pong does have an effect there.