UCI engine authors: Please add support for 'searchmoves'

[hgm]

This is getting less and less clear to me. If there are different commands from the GUI, which each should be answered in a different way hy the engine... Like 'go' should be answered by "bestmove' and 'isready' should be answered by 'readyok'. If that does not add states to the protocol, how come that having two different commands 'ping 1' and 'ping 2' that each prescribe the specific response 'pong 1' and 'pong 2' do add states to the protocol? Both cases are two commands that require two specific different responses.

[Evert]

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?

I would think that the UCI specification is fairly clear on this:

* position [fen <fenstring> | startpos ] moves <move1> .... <movei>
set up the position described in fenstring on the internal board and
play the moves on the internal chess board.
if the game was played from the start position the string "startpos" will be sent
Note: no "new" command is needed. However, if this position is from a different game than
the last position sent to the engine, the GUI should have sent a "ucinewgame" inbetween.

* go
start calculating on the current position set up with the "position" command.

I guess this allows multiple "position" commands to be sent, but I can't think of a situation where it would be useful to do so. I also don't see why it would matter.
And yes, "go" always refers back to the last position command. No second go command should be sent.

[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?

I would think that the UCI specification is fairly clear on this:

* position [fen <fenstring> | startpos ] moves <move1> .... <movei>
set up the position described in fenstring on the internal board and
play the moves on the internal chess board.
if the game was played from the start position the string "startpos" will be sent
Note: no "new" command is needed. However, if this position is from a different game than
the last position sent to the engine, the GUI should have sent a "ucinewgame" inbetween.

* go
start calculating on the current position set up with the "position" command.

I guess this allows multiple "position" commands to be sent, but I can't think of a situation where it would be useful to do so. I also don't see why it would matter.
And yes, "go" always refers back to the last position command. No second go command should be sent.

I don't think it is all that clear.

You say "No second go command should be sent." But this is not apparent to me from the description in the protocol.

In Arena, a position and a go command always go together.

Image two scenarios:
1. GUI > Engine: position ...
2. GUI > Engine: position ...
3. GUI > Engine: go ...
4. Engine > GUI: bestmove ...

and

1. GUI > Engine: position ...
2. GUI > Engine: go ...
3. Engine > GUI: bestmove ...
4. GUI > Engine: go ...

The first scenario, from my implementation stand point, is very easy to handle, since receiving the second "position" command simply resets the internal board to the new position, and it is ready to go.

The second scenario on the other hand, is not that simple to handle.
In my engine when it decides that time is up (step 3.), it returns from the search in a disorderly fashion, leaving the internal state of the engine to some undefined state.

Now if a second "go" is received (step 4.), I have to clean up my internal state, before I can proceed to the search.

Therefore it is kinda important to know if scenario number 2 needs to be handled.

Happily Arena has never send a "go" command to my engine, without first explicitly sending a corresponding "position" command.

So the Arena implementation is very clear in its behaviour. But I don't think the UCI specification is all that clear. At least in my eyes!

Kind regards,
Jesper

[Gian-Carlo Pascutto]

This is getting less and less clear to me. If there are different commands from the GUI, which each should be answered in a different way hy the engine... Like 'go' should be answered by "bestmove' and 'isready' should be answered by 'readyok'. If that does not add states to the protocol, how come that having two different commands 'ping 1' and 'ping 2' that each prescribe the specific response 'pong 1' and 'pong 2' do add states to the protocol? Both cases are two commands that require two specific different responses.

Because your reasoning requires an infinite number of different commands.

[hgm]

Indeed, but that was exactly my objection against considering the UCI "position command" as a single command. While in fact it contains an entire chess game, which can be of arbitrary length. So there are also an infinite number of different "position commands". In fact more than there are game commands, as the ping number wraps around after a mere four billion, while the game space of Chess is far larger than that.

[Michel]

'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.

Well what happens after a protocol violation should have no influence on whether a protocol is stateless or not.

In this case the GUI got a pong 3 reply to a ping 2 command. I think it is safe to assume that the engine would not send out of order pongs (this should probably be specified in the protocol) so at that point the GUI knows there is something wrong. No need to wait for a pong 2.

[Evert]

You say "No second go command should be sent." But this is not apparent to me from the description in the protocol.

Hmm... to me

start calculating on the current position set up with the "position" command.

quite unambiguously states that the current position is set using a position command, and the go command tells the engine to start thinking on the current position. Any other reading of that text doesn't make much sense to me.

Mind you - the protocol does not define what the current position is after a go command: the original one or the new one after the move was made. On the other hand, it doesn't <i>have</i> to because "the current position [is] set up with the position command".

Admittedly, it's not a particularly technical description, but I find that's actually a good thing - it makes it easier to read.

[dadij]

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.

Yes, it does. I hope that isn't equivalent to saying that it won't be implemented? As you say it would be useful in IDeA.

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.

Of course the lack of documentation is a disappointment. However, MultiPV_cp has been documented. In the UCI standard lingo it would probably be described something like this (based on the level of documentation for other commands/options):

Code: Select all

* <id> = MultiPV_cp, type spin
  limits the number of variations returned from multi best line or k-best mode. Variations which are more than the specified number of centipawns worse than the best move are not returned. The default value is 32000.

So it's somewhat similar to your 'go window' idea. Both are nice and useful features which I would be happy to see in as many engines as possible.

It's not clear to me why you say that 'go window' makes 'searchmoves' redundant. To me it looks like it would still be useful for certain scenarios where you want to exclude specific moves (which are not necessarily the best moves) from the analysis. I have already mentioned a couple of examples (analyzing moves in/not in the tree etc.), where you may already have analyzed several moves (not necessarily just the best ones) and want to check the moves that you haven't analyzed. One more practical example is an author who is writing a book about an opening variation. He has covered a position deeply by showing both good examples of how to handle the position and typical mistakes. Before finishing he wants to see if there are some other moves that might be of interest. Searchmoves, excluding already analyzed moves, looks like a natural choice in this case (and one offered by e.g. Aquarium). I can even imagine that 'go window' in combination with 'searchmoves' could be useful. What about, for instance, when the user has manually added some moves to the IDeA tree (and had them evaluated), and now IDeA wants to add more alternatives in addition to the moves that the user added? Would your 'go window' somehow handle these examples efficiently without the need for 'searchmoves'

[Gian-Carlo Pascutto]

Yes, it does. I hope that isn't equivalent to saying that it won't be implemented? As you say it would be useful in IDeA.

I'm not going to implement this as there is no standard, no specification and no GUI for it. I'm just saying I wish UCI had forseen this.

It's not clear to me why you say that 'go window' makes 'searchmoves' redundant.

Because searchmoves is equivalent to feeding the child positions to the engine, and calling go on each one on it, with the lowerbound in the go window being the best score so far. So for analysis these are 100% redundant.

For gameplay (which you didn't mention) they are not redundant, and searchmoves could be useful, for example when we are still in book.

[hgm]

You shouldn't feel inhipbited to develop new protocol. If engine and GUI authors would wait for each other, progress would stall forever in a deadly embrace...