ponder engine-gui interaction

[brtzsnr]

I'm thinking to add pondering to my UCI engine. Can anybody post the interaction between her/his engine and the GUI (xboard is possible)?

The protocol description at http://wbec-ridderkerk.nl/html/UCIProtocol.html is not very clear about this.

[jdart]

Feel free to look at my implementation here:

https://github.com/jdart1/arasan-chess/ ... rasanx.cpp

The key bits are around lines 220 and 1739 (including the processCmdInWaitState function).

It is important that you handle the case where a ponder search terminates early, for example due to a forced mate. In that case you have to go into a "wait state" and not proceed until you have received "stop".

--Jon

[brtzsnr]

Does the 'bestmove' have to happen after 'stop' always? Can I do

> go ponder
< bestmove a1a2
> stop

?

[jdart]

Does the 'bestmove' have to happen after 'stop' always?

Yes! The "bestmove" signals the GUI that it has received the "stop" command.

Btw. if you use Arena (http://www.playwitharena.com) as the GUI it has a log feature that will let you look at all GUI/engine interactions and compare them with a UCI engine that is known to work.

--Jon

[Ferdy]

Can I do

> go ponder
< bestmove a1a2
> stop

?

No you are not allowed to send bestmove in that sequence, you need to wait for ponderhit command or stop command before you send your bestmove.

Code: Select all

* go
	start calculating on the current position set up with the "position" command.
	There are a number of commands that can follow this command, all will be sent in the same string.
	If one command is not sent its value should be interpreted as it would not influence the search.
	* searchmoves <move1> .... <movei>
		restrict search to this moves only
		Example: After "position startpos" and "go infinite searchmoves e2e4 d2d4"
		the engine should only search the two moves e2e4 and d2d4 in the initial position.
	* ponder
		start searching in pondering mode.
		Do not exit the search in ponder mode, even if it's mate!
		This means that the last move sent in in the position string is the ponder move.
		The engine can do what it wants to do, but after a "ponderhit" command
		it should execute the suggested move to ponder on. This means that the ponder move sent by
		the GUI can be interpreted as a recommendation about which move to ponder. However, if the
		engine decides to ponder on a different move, it should not display any mainlines as they are
		likely to be misinterpreted by the GUI because the GUI expects the engine to ponder
	   on the suggested move.

[...]

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

* ponderhit
	the user has played the expected move. This will be sent if the engine was told to ponder on the same move
	the user has played. The engine should continue searching but switch from pondering to normal search.

[hgm]

In UCI any search that terminates will have to send a bestmove command (even when no legal move exists; just send 0000 in that case). The reason for termination is immaterial. So it both holds for timeout or reception of a 'stop' command. So the UCI 'stop' command is basically a 'move now' command.

To make a UCI engine ponder the GUI sends the position over which it has to ponder to the engine, followed by a 'go ponder' command (which also contains the usual timing information). The search can then be turned in a normal one (i.e. obeying the timing specs) by sending 'ponderhit', or aborted by sending 'stop'. In addition the GUI will set the 'ponder' option to true, to indicate the engine is playing a ponder-on game, and handle its time management accordingly.

Note that after 'go ponder' or 'go infinite' the engine should NEVER send a 'bestmove' spontaeously, even if there is nothing more to search (e.g. when it sees a mate in one). Even in those cases it should wait sending 'bestmove' until after it receives the 'stop' command.