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 ?
UCI pondering or infinite search
Moderators: hgm, Rebel, chrisw
-
- Posts: 3232
- Joined: Mon May 31, 2010 1:29 pm
- Full name: lucasart
UCI pondering or infinite search
Theory and practice sometimes clash. And when that happens, theory loses. Every single time.
-
- Posts: 931
- Joined: Tue Mar 09, 2010 3:46 pm
- Location: New York
- Full name: Álvaro Begué (RuyDos)
Re: UCI pondering or infinite search
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.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 ?
-
- Posts: 4833
- Joined: Sun Aug 10, 2008 3:15 pm
- Location: Philippines
Re: UCI pondering or infinite search
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
Code: Select all
info string "I am done, this is just mate in 1, my bestmove is ...."
Code: Select all
bestmove ....
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
-
- Posts: 12542
- Joined: Wed Mar 08, 2006 8:57 pm
- Location: Redmond, WA USA
Re: UCI pondering or infinite search
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."
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.
But sharing ideas is an even greater virtue. We have another word for this. It is called teaching.
-
- Posts: 27825
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: UCI pondering or infinite search
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.lucasart wrote:I mean a good reason beyond the "it's written in the UCI protocol".
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'?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 ?
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.)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[*].
-
- Posts: 2272
- Joined: Mon Sep 29, 2008 1:50 am
Re: UCI pondering or infinite search
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).When you cannot search anymore, it makes no sense to keep searching.
Ideas=science. Simplification=engineering.
Without ideas there is nothing to simplify.
Without ideas there is nothing to simplify.
-
- Posts: 127
- Joined: Sat Jan 22, 2011 7:14 pm
- Location: Lille, France
Re: UCI pondering or infinite search
No, 100% design flaw. I feel pain every time I have to cater for it.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 ?
-
- Posts: 855
- Joined: Sun May 23, 2010 1:32 pm
Re: UCI pondering or infinite search
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?
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?
-
- Posts: 27825
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: UCI pondering or infinite search
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...
-
- Posts: 855
- Joined: Sun May 23, 2010 1:32 pm
Re: UCI pondering or infinite search
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.