UCI pondering or infinite search

[lucasart]

Is there a good reason why the engine can't print bestmove upon completion of the ID loop (eg. depth=127 completed) ?

I mean a good reason beyond the "it's written in the UCI protocol".

This seems to me like a design flaw of UCI, forcing engine programmers to add hacks and convoluted code for no reason. Am I missing something ?

[AlvaroBegue]

Is there a good reason why the engine can't print bestmove upon completion of the ID loop (eg. depth=127 completed) ?

I mean a good reason beyond the "it's written in the UCI protocol".

This seems to me like a design flaw of UCI, forcing engine programmers to add hacks and convoluted code for no reason. Am I missing something ?

Well, it's not your turn, so you shouldn't move. If you interpret sending "bestmove" as the UCI equivalent of playing a move on the board, I think the convention makes sense.

[Ferdy]

Is there a good reason why the engine can't print bestmove upon completion of the ID loop (eg. depth=127 completed) ?

I mean a good reason beyond the "it's written in the UCI protocol".

This seems to me like a design flaw of UCI, forcing engine programmers to add hacks and convoluted code for no reason. Am I missing something ?

Code: Select all

	* infinite
		search until the "stop" command. Do not exit the search without being told so in this mode!
    
* stop
	stop calculating as soon as possible,
	don't forget the "bestmove" and possibly the "ponder" token when finishing the search

Regarding infinite, this is understandable, infinite has no limits on depth and time etc, if you don't want to search anymore, then just send say,

Code: Select all

info string "I am done, this is just mate in 1, my bestmove is ...."

But when you receive stop command, better send your bestmove

Code: Select all

bestmove ....

This way you still comply generally with the protocol by sending your bestmove after the stop command.

There is a story telling behind this. The user is the boss, not the engine. If you sent info string "I am done ..." the boss would be glad that he is informed and the boss now would stop the infinite search.

Code: Select all

// tell the engine to search infinite from the start position after 1.e4 e5
position startpos moves e2e4 e7e5
go infinite

// the engine starts sending infos about the search to the GUI
// (only some examples are given)


		info depth 1 seldepth 0
		info score cp 13  depth 1 nodes 13 time 15 pv f1b5 
		info depth 2 seldepth 2
		info nps 15937
		info score cp 14  depth 2 nodes 255 time 15 pv f1c4 f8c5 
		info depth 2 seldepth 7 nodes 255
		info depth 3 seldepth 7
		info nps 26437
		info score cp 20  depth 3 nodes 423 time 15 pv f1c4 g8f6 b1c3 
		info nps 41562
		....


// here the user has seen enough and asks to stop the searching
stop

// the engine has finished searching and is sending the bestmove command
// which is needed for every "go" command sent to tell the GUI
// that the engine is ready again
		bestmove g1f3 ponder d8f6

[Dann Corbit]

When you cannot search anymore, it makes no sense to keep searching.

There are engines which will return an answer. I like that a lot.

It makes sense in several scenarios, including:

TB solution that cannot be improved. I gave you an hour to think. You have an answer in one millisecond and you know you can't improve it.

Suppose further that I have found a mate in 4. I have exhaustively determined that there is no mate in 3. Just return the answer. Sitting there mute for ages is just plain stupid.

If the UCI specification does not let you answer with your move, then (in this instance) the UCI specification is an ass[*].


[*] "If the law supposes that," said Mr. Bumble, squeezing his hat emphatically in both hands, "the law is a ass — a idiot. If that's the eye of the law, the law is a bachelor; and the worst I wish the law is, that his eye may be opened by experience — by experience."

[hgm]

I mean a good reason beyond the "it's written in the UCI protocol".

Isn't that by definition the only reason? Of course you can alter any protocol in any way you want, if you are going to alter it.

This seems to me like a design flaw of UCI, forcing engine programmers to add hacks and convoluted code for no reason. Am I missing something ?

Seems UCI has worse design flaws than using one command or another to communicate the best move of an iteration. It is already sending the best move of each iteration as part of the 'info pv' command. Why would it be less flawed to send it twice, with a command that has different meaing after 'go infinite' then after any orther 'go'?

If the UCI specification does not let you answer with your move, then (in this instance) the UCI specification is an ass[*].

You can stop searching, but you cannot print 'bestmove'. For that the specs require you to wait for 'ponderhit' or 'stop', in a non-timed search. The 'bestmove' command in UCI is used as a confirmation the engine has stopped searching, and is ready to receive other commands (like 'setoption'). Therefore it is needed even in cases where the move is of no interest at all. (E.g. after a ponder miss.)

[Michel]

When you cannot search anymore, it makes no sense to keep searching.

I don't see the "design flaw" here. The protocol does not say that the engine should keep searching (bitcoins?). It says it should not output a bestmove until told by the GUI. "go infinite" really means "go infinite", until revoked by the GUI. This is completely logical within the context of the UCI protocol (the GUI is in charge).

[Xann]

This seems to me like a design flaw of UCI, forcing engine programmers to add hacks and convoluted code for no reason. Am I missing something ?

No, 100% design flaw. I feel pain every time I have to cater for it.

[elcabesa]

I agree with Michel, I don't see any design flaw. From a protocol point of wiew the UCI protocol is simple and consistent.

If he ask you infinite search, do an infinite search and give back bestmove only after stop command.
If he ask you to ponder, don't give back a bestmove.... because it's not your turn.
If he ask you some time/node/depth bounded search return bestmove ad soon as you hit the limit or after a stop command.
If it ask you to act like a player playing a game, the engine can manage the time by himself and reply with bestmove when he want. Before or after time expiration.

Where is the flaw?

[hgm]

Well, it should be clear that UCI is of course a design flaw to start with. But within that context having to send a 'bestmove' command when you stop thinking isn't any worse than the rest. Particularly bad is that you have to send the time on the opponent's clock with the go-ponder command (apparently predicting how long the opponent is going to think?!). And of course lack of standardized error messages, no provision for making draw offers...

[elcabesa]

I agree with you about draw offer and so on. But if you implement an uci engine and accept the fact that the gui is in command, then the design of go infinite, ponder, stop and bestmove make sense.