<< bestmove g3g6
Takeback the last move in internal board
<<<<<<
string received: stop
>> stop
Deuterium is no longer searching, and bestmove was already sent
<< bestmove 0000
This is a bad violation of UCI protocol. An engine should NEVER produce more than one 'bestmove' command in response to a 'go' command. (And also never fewer than one, btw.)
* bestmove <move1> [ ponder <move2> ]
the engine has stopped searching and found the move <move> best in this position.
the engine can send the move it likes to ponder on. The engine must not start pondering automatically.
this command must always be sent if the engine stops searching, also in pondering mode if there is a
"stop" command, so for every "go" command a "bestmove" command is needed!
Directly before that the engine should send a final "info" command with the final search information,
the the GUI has the complete statistics about the last search.
There was no such thing as "should NEVER produce more than one bestmove".
Also Deuterium was provoked to send bestmove 0000 because it received two stop commands, it does not send bestmove zzzz, bestmove yyyy without a command from GUI.
But of course I can ignore the second stop command. But in the protocol
it does not say that I am not allowed not to ignore, I still have the choice not to ignore.
That would mean that the GUI should have full control of the situation, such as not sending a second stop command when the engine had already sent its bestmove.
* 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.
Ferdy wrote:There was no such thing as "should NEVER produce more than one bestmove".
Also Deuterium was provoked to send best move 0000 because it received two stop commands, it does not send best move zzzz, best move yyyy without a command from GUI.
'go' and 'bestmove' go in pairs (as brackets). In general a UCI GUI can send 'stop' during time searches (not infinite), and there is never a guarantee that the engine will still be searching when processing it. So the only solution is to ignore 'stop' when not searching. Another way of seing it is that 'go' eventually requires an answer, while 'stop' doesn't.
Ferdy wrote:There was no such thing as "should NEVER produce more than one bestmove".
Also Deuterium was provoked to send best move 0000 because it received two stop commands, it does not send best move zzzz, best move yyyy without a command from GUI.
'go' and 'bestmove' go in pairs (as brackets).
Correct.
Xann wrote: In general a UCI GUI can send 'stop' during time searches (not infinite),
Matthias Gemuh wrote:...
1) Solving testsuites
- Some UCI engines treat "go infinite" in a strange manner, so solving
testsuites fails for them (Fire4, Gull3, etc).
...
The conflict was about how to handle "stop" when not searching.
Engine that ignored it worked fine. Engines that felt compelled to act,
choked.
The delibrate "stop" before a new FEN was meant to stop any engine that may be searching "out of sync". As it instead causes some engines to choke, I have taken it out.
BTW, there are some more fixes (unrelated to testsuites) because I ugraded my compiler.
* 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.
Well, that is what I said, and is seems not in any way ambiguous. It specifies the engine should ignore 'stop' when not searching. That does not mean ignoring it is optional, and that you can also elect to send a 'bestmove 0000' command in reply to it.
It is not possible for the GUI to know if the 'bestmove' is a reply to the next search it orders. They could have crossed.
Matthias Gemuh wrote:The delibrate "stop" before a new FEN was meant to stop any engine that may be searching "out of sync".
You do wait for 'bestmove' before ordering a new search? Are there really engines that still search on after emitting a 'bestmove', and choke on altering the position? (If so, I don't think there is any reason to believe repeating 'stop' would help.)
I know there are engines that cannot handle commands received after 'stop', but before they printed 'bestmove'. Apparently they do not queue such commands while busy. This is why Polyglot has the SyncStop option, and in UCI2WB I always use that mode.
Matthias Gemuh wrote:...
1) Solving testsuites
- Some UCI engines treat "go infinite" in a strange manner, so solving
testsuites fails for them (Fire4, Gull3, etc).
...
The conflict was about how to handle "stop" when not searching.
Engine that ignored it worked fine. Engines that felt compelled to act,
choked.
The delibrate "stop" before a new FEN was meant to stop any engine that may be searching "out of sync". As it instead causes some engines to choke, I have taken it out.
It was the GUI that has choked, because the GUI is fully aware that it sent its first stop command, and the engine replied with bestmove to that, so the GUI knew that the engine has replied with bestmove from GUI's first stop command. So why the GUI sends again the stop command? (they are in sync after the engine sent its first bestmove reply after the first stop command). If the GUI received the second bestmove 0000, it should have ignored this move, because the GUI knew that it was just testing the engine using the second stop command.
Also in the protocol it does not say "do not reply anything to the stop command when you are no longer searching and has already sent the bestmove".
That would mean that if the GUI sent stop command 10x, the engine has the option to reply bestmove 10x too. The GUI should adjust in this situation because it sent stop command 10x in the first place.
