some UCI protocol issues/questions

[jdart]

I'm having some trouble understanding how analysis mode is supposed to work in UCI, especially when combined with multipv mode.

In fact it looks like various engines and interfaces do not do this quite the same way.

If I start analyzing and am not in multipv mode, the engine gets a "position" command and then "go infinite" and it starts outputting info statements. This part is consistent across engines.

Now, the UI can send an "option multipv <n>" command during the search. What I'd expect is, the engine should stop sending the regular "info" commands and start sending "info multipv 1" , "info multipv 2", etc. But a couple I tried (AnMon, Shredder) don't do this. They seem to ignore "option MultiPV" until the engine is manually stopped and then restarted. (By the way, Arena 2.0.1 doesn't seem to realize this - it tries to show multiple variations but it isn't getting any, so the display is a bit messed up).

Arasan tries to change mode mid-search but this doesn't work in the current released version (12.2). The engine appears to hang. Shredder's UI waits a while for it and then terminates/restarts the process, which works but is a bit drastic (ChessBase and Arena do not do this). I'm working on a fix.

Another puzzle: Looking at the Fruit sources it appears that engine does not send a "bestmove" command if a search has been started with "go infinite" but AnMon at least does this - "bestmove" is usually the signal to the UI that the GUI has received and processed the "stop" command. So lacking that I'm not clear how the GUI knows. Although, in multipv mode, I'm not 100% clear what the "bestmove" should be.


--Jon

[Michel]

Now, the UI can send an "option multipv <n>" command during the search.

I assume you mean

setoption name multipv value <n>

Of course the engine should first have sent an appropriate option command

option multipv type spin default 1 min 1 max <n>

the engine should stop sending the regular "info" commands and start sending "info multipv 1" , "info multipv 2",

I guess you mean stop sending info pv.... Yes this appears to be the case.

Looking at the Fruit sources it appears that engine does not send a "bestmove" command if a search has been started with "go infinite" but AnMon at least does this

This is a clear protocol violation.

Code: Select all

	* infinite

		search until the "stop" command. Do not exit the search without being told so in this mode!

Although, in multipv mode, I'm not 100% clear what the "bestmove" should be.

Multipv is a way of presenting search output. Protocol wise it is orthogonal
to the bestmove command.

[Gian-Carlo Pascutto]

Now, the UI can send an "option multipv <n>" command during the
search. What I'd expect is, the engine should stop sending the regular
"info" commands and start sending "info multipv 1" , "info multipv 2",
etc.

The spec says: "for the best move/pv add "multipv 1" in the string when you send the pv.". So you are right that multipv 1 should be added for sending *lines*. But sending regular info commands that don't want to send a new line (for example to update nodes searched), it should not be needed.

(Deep Sjeng *always* adds the multipv 1 even when not in multipv mode. This is essentially guaranteed to work because of: "* if the engine or the GUI receives an unknown command or token it should just ignore it and try to parse the rest of the string.")

They seem to ignore "option MultiPV" until the engine is manually
stopped and then restarted

Specification says: "One string will be sent for each parameter and this will only be sent when the engine is waiting."

So they are right. Arena is buggy (and IIRC, so is all ChessBase stuff)

Another puzzle: Looking at the Fruit sources it appears that engine does
not send a "bestmove" command if a search has been started with "go
infinite"

Clear violation of the specification:

"* infinite: search until the "stop" command."

"* stop
stop calculating as soon as possible,
don't forget the "bestmove" and possibly the "ponder" token when finishing the search"

Although, in multipv mode, I'm not 100% clear what the "bestmove"
should be.

Uh? The best move! MultiPV won't change that.

[jdart]

I assume you mean

setoption name multipv value <n>
...
I guess you mean stop sending info pv....

Thanks for the corrections .. yes, that is what I meant. And I understand, per GCP, that info statements like "hashfull" can still be sent and don't need multipv.

[jdart]

Specification says: "One string will be sent for each parameter and this will only be sent when the engine is waiting."

So they are right. Arena is buggy (and IIRC, so is all ChessBase stuff)

Well, still, we poor engine authors are expected to work with these UIs, buggy or not.

--Jon

[jdart]

Looking at the Fruit sources it appears that engine does not send a "bestmove" command if a search has been started with "go infinite" but AnMon at least does this

This is a clear protocol violation.

Then not just Fruit, but a lot of Fruit variants, are broken in analysis mode. Unless I misread the source.

--Jon

[Michel]

Then not just Fruit, but a lot of Fruit variants, are broken in analysis mode. Unless I misread the source.

--Jon

Sorry there is a misunderstanding. Sending a "bestmove" is infinite analysis mode is a protocol violation. As far as I know Fruit handles this correctly (i.e. it does NOT send a bestmove).

Even if the engine detects a mate in one it should not return from the search but instead go into some kind of delay loop until "stop" is received.

[hgm]

Well, still, we poor engine authors are expected to work with these UIs, buggy or not.

--Jon

Not really...

[bob]

Now, the UI can send an "option multipv <n>" command during the
search. What I'd expect is, the engine should stop sending the regular
"info" commands and start sending "info multipv 1" , "info multipv 2",
etc.

The spec says: "for the best move/pv add "multipv 1" in the string when you send the pv.". So you are right that multipv 1 should be added for sending *lines*. But sending regular info commands that don't want to send a new line (for example to update nodes searched), it should not be needed.

(Deep Sjeng *always* adds the multipv 1 even when not in multipv mode. This is essentially guaranteed to work because of: "* if the engine or the GUI receives an unknown command or token it should just ignore it and try to parse the rest of the string.")

Now THERE is a wonderful specification. use what you understand, ignore what you don't, and if the results are worthless, who knows?

They seem to ignore "option MultiPV" until the engine is manually
stopped and then restarted

Specification says: "One string will be sent for each parameter and this will only be sent when the engine is waiting."

So they are right. Arena is buggy (and IIRC, so is all ChessBase stuff)

Another puzzle: Looking at the Fruit sources it appears that engine does
not send a "bestmove" command if a search has been started with "go
infinite"

Clear violation of the specification:

"* infinite: search until the "stop" command."

"* stop
stop calculating as soon as possible,
don't forget the "bestmove" and possibly the "ponder" token when finishing the search"

Although, in multipv mode, I'm not 100% clear what the "bestmove"
should be.

Uh? The best move! MultiPV won't change that.

[jdart]

But then after stop - it should do nothing?