* <id> = UCI_AnalyseMode, type check
The engine wants to behave differently when analysing or playing a game.
For example when playing it can use some kind of learning.
This is set to false if the engine is playing a game, otherwise it is true.
So this can be used for analysing or playing a game. Second sentence says that it can be
used for learning when playing, but the last sentence implies that this is set to false when
playing a game so what is the point of 2nd sentence?
Does it mean that when user set this to true and play a game, the gui will set it to false?
What then is the specific purpose of this option if we have already go infinite command useful for analysing?
I think the GUI sets it to false while playing a game, and to true when the user is analysing. So the engine would have to do learning when the option is set to false, and refrain from it (or probing an own book) when the option is set to true.
Not really. The "go infinite" command is the equivalent of "analyze". I am not sure why UCI engines are supposed to be not smart enough that "go infinite" means they are now in analyze mode, and should behave accordingly, but instead an extra option is needed to tell it that. Perhaps it was designed to allow GUIs to play games through "go infinite" + "stop" commands, deciding itself when the engine ha thought long enough (or let the user decide that).
Something similar exists for pondering. To actually ponder you have to send "go ponder", but there also is an option Ponder to alter the behavor of the engine when searching in a ponder-on game. It cannot remember it is playing a ponder-on game after a ponder miss, because then the protocol would not be stateless. Therefore it needs to be reminded through an extra option to set the statelessness state. Or something like that....
hgm wrote:Not really. The "go infinite" command is the equivalent of "analyze". I am not sure why UCI engines are supposed to be not smart enough that "go infinite" means they are now in analyze mode, and should behave accordingly, but instead an extra option is needed to tell it that. Perhaps it was designed to allow GUIs to play games through "go infinite" + "stop" commands, deciding itself when the engine ha thought long enough (or let the user decide that).
Something similar exists for pondering. To actually ponder you have to send "go ponder", but there also is an option Ponder to alter the behavor of the engine when searching in a ponder-on game. It cannot remember it is playing a ponder-on game after a ponder miss, because then the protocol would not be stateless. Therefore it needs to be reminded through an extra option to set the statelessness state. Or something like that....
The "go infinite" command is the equivalent of "analyze". I am not sure why UCI engines are supposed to be not smart enough that "go infinite" means they are now in analyze mode,
I guess go infinite is not equivalent to analyze mode because of this.
// if the engine supports the "UCI_AnalyseMode" option and the next search is supposed to
// be an analysis, the GUI should set "UCI_AnalyseMode" to true if it is currently
// set to false with this engine
setoption name UCI_AnalyseMode value true
I guess WB "analyze" is equivalent to UCI "setoption UCI_AnalyzeMode" + "go infinite", then (for engines that support the option). I should perhap take account of that in UCI2WB. Currently I just translate "analyze" to "go infinite".