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
some UCI protocol issues/questions
Moderators: hgm, Rebel, chrisw
-
- Posts: 4367
- Joined: Fri Mar 10, 2006 5:23 am
- Location: http://www.arasanchess.org
-
- Posts: 2272
- Joined: Mon Sep 29, 2008 1:50 am
Re: some UCI protocol issues/questions
I assume you meanjdart wrote: Now, the UI can send an "option multipv <n>" command during the search.
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>
I guess you mean stop sending info pv.... Yes this appears to be the case.the engine should stop sending the regular "info" commands and start sending "info multipv 1" , "info multipv 2",
This is a clear protocol violation.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
Code: Select all
* infinite
search until the "stop" command. Do not exit the search without being told so in this mode!
Multipv is a way of presenting search output. Protocol wise it is orthogonalAlthough, in multipv mode, I'm not 100% clear what the "bestmove" should be.
to the bestmove command.
-
- Posts: 1243
- Joined: Sat Dec 13, 2008 7:00 pm
Re: some UCI protocol issues/questions
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.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.
(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.")
Specification says: "One string will be sent for each parameter and this will only be sent when the engine is waiting."They seem to ignore "option MultiPV" until the engine is manually
stopped and then restarted
So they are right. Arena is buggy (and IIRC, so is all ChessBase stuff)
Clear violation of the specification: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"
"* 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"
Uh? The best move! MultiPV won't change that.Although, in multipv mode, I'm not 100% clear what the "bestmove"
should be.
-
- Posts: 4367
- Joined: Fri Mar 10, 2006 5:23 am
- Location: http://www.arasanchess.org
Re: some UCI protocol issues/questions
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.Michel wrote:
I assume you mean
setoption name multipv value <n>
...
I guess you mean stop sending info pv....
-
- Posts: 4367
- Joined: Fri Mar 10, 2006 5:23 am
- Location: http://www.arasanchess.org
Re: some UCI protocol issues/questions
Well, still, we poor engine authors are expected to work with these UIs, buggy or not.Gian-Carlo Pascutto wrote: 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)
--Jon
-
- Posts: 4367
- Joined: Fri Mar 10, 2006 5:23 am
- Location: http://www.arasanchess.org
Re: some UCI protocol issues/questions
Then not just Fruit, but a lot of Fruit variants, are broken in analysis mode. Unless I misread the source.Michel wrote:This is a clear protocol violation.jdart wrote: 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
--Jon
-
- Posts: 2272
- Joined: Mon Sep 29, 2008 1:50 am
Re: some UCI protocol issues/questions
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).Then not just Fruit, but a lot of Fruit variants, are broken in analysis mode. Unless I misread the source.
--Jon
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.
-
- Posts: 27809
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: some UCI protocol issues/questions
Not really...jdart wrote: Well, still, we poor engine authors are expected to work with these UIs, buggy or not.
--Jon
-
- Posts: 20943
- Joined: Mon Feb 27, 2006 7:30 pm
- Location: Birmingham, AL
Re: some UCI protocol issues/questions
Now THERE is a wonderful specification. use what you understand, ignore what you don't, and if the results are worthless, who knows?Gian-Carlo Pascutto wrote: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.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.
(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.")
Specification says: "One string will be sent for each parameter and this will only be sent when the engine is waiting."They seem to ignore "option MultiPV" until the engine is manually
stopped and then restarted
So they are right. Arena is buggy (and IIRC, so is all ChessBase stuff)
Clear violation of the specification: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"
"* 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"
Uh? The best move! MultiPV won't change that.Although, in multipv mode, I'm not 100% clear what the "bestmove"
should be.
-
- Posts: 4367
- Joined: Fri Mar 10, 2006 5:23 am
- Location: http://www.arasanchess.org
Re: some UCI protocol issues/questions
But then after stop - it should do nothing?