UCI pondering or infinite search

Discussion of chess software programming and technical issues.

Moderators: hgm, Harvey Williamson, bob

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
User avatar
lucasart
Posts: 2957
Joined: Mon May 31, 2010 11:29 am
Contact:

UCI pondering or infinite search

Post by lucasart » Fri Nov 10, 2017 2:07 am

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 ?
Theory and practice sometimes clash. And when that happens, theory loses. Every single time.

AlvaroBegue
Posts: 884
Joined: Tue Mar 09, 2010 2:46 pm
Location: New York

Re: UCI pondering or infinite search

Post by AlvaroBegue » Fri Nov 10, 2017 2:30 am

lucasart wrote: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
Posts: 3607
Joined: Sun Aug 10, 2008 1:15 pm
Location: Philippines

Re: UCI pondering or infinite search

Post by Ferdy » Fri Nov 10, 2017 5:00 am

lucasart wrote: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
Posts: 8680
Joined: Wed Mar 08, 2006 7:57 pm
Location: Redmond, WA USA
Contact:

Re: UCI pondering or infinite search

Post by Dann Corbit » Fri Nov 10, 2017 6:17 am

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."
Taking ideas is not a vice, it is a virtue. We have another word for this. It is called learning.
But sharing ideas is an even greater virtue. We have another word for this. It is called teaching.

User avatar
hgm
Posts: 22338
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: UCI pondering or infinite search

Post by hgm » Fri Nov 10, 2017 6:50 am

lucasart wrote: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'?
Dann Corbit wrote: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
Posts: 1961
Joined: Sun Sep 28, 2008 11:50 pm

Re: UCI pondering or infinite search

Post by Michel » Fri Nov 10, 2017 9:30 am

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).
Ideas=science. Simplification=engineering.
Without ideas there is nothing to simplify.

Xann
Posts: 125
Joined: Sat Jan 22, 2011 6:14 pm
Location: Lille, France

Re: UCI pondering or infinite search

Post by Xann » Fri Nov 10, 2017 11:26 am

lucasart wrote: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
Posts: 679
Joined: Sun May 23, 2010 11:32 am
Contact:

Re: UCI pondering or infinite search

Post by elcabesa » Fri Nov 10, 2017 11:27 am

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?

User avatar
hgm
Posts: 22338
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: UCI pondering or infinite search

Post by hgm » Fri Nov 10, 2017 11:32 am

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
Posts: 679
Joined: Sun May 23, 2010 11:32 am
Contact:

Re: UCI pondering or infinite search

Post by elcabesa » Fri Nov 10, 2017 11:42 am

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.

Post Reply