UCI pondering done right

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
hgm
Posts: 23605
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: UCI pondering done right

Post by hgm » Thu Dec 20, 2018 9:41 pm

NOT AT ALL. I said that "go time ... inc ..." would be uniform command handling, while "go wtime ... btime ... winc ... binc ..." would require non-uniform command handling, because which time you have to pay attention to now depends on the color that is on move, which requires an extra if-then-else on that color. YOU are the one that advocates sending redundant data just to need extra if-then-else and recognizing more different keywords to process.

BTW, the designer of UCCI protocol apparently agrees with me on this, as there the command is "go time ... opptime ... increment ... oppincrement", so that you can unconditionally ignore the opponent parameters if your engine is not interested in them. Of course CECP also has this uniform command handling, where the time to think is always given by 'time'. Even UCI has this, in fixed-time-per-move mode: you just send "go movetime ...", and not "go wmovetime ... bmovetime ..." to satisfy your silly and counterproductive preference.

User avatar
lucasart
Posts: 3037
Joined: Mon May 31, 2010 11:29 am
Full name: lucasart
Contact:

Re: UCI pondering done right

Post by lucasart » Fri Dec 21, 2018 4:31 am

So, what have we learnt after 5 pages of this thread?
* UCI pondering is not perfect, but close enough, and there are no shortcuts without shortcomings.
* UCI is easily better than the pile of manure called CECP
* Arguing with HGM is not a good use of one's time
Theory and practice sometimes clash. And when that happens, theory loses. Every single time.

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

Re: UCI pondering done right

Post by hgm » Fri Dec 21, 2018 7:40 am

You forgot an important one. Or perhaps you thought that it should be obvious from your latest post:

* lucasart is a troll

noobpwnftw
Posts: 338
Joined: Sun Nov 08, 2015 10:10 pm

Re: UCI pondering done right

Post by noobpwnftw » Fri Dec 21, 2018 8:28 am

Someone has to decide who is "wtime" and who is "btime", the logic exists one way or the other, or the other GUI authors may complain. :D

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

Re: UCI pondering done right

Post by hgm » Fri Dec 21, 2018 9:09 am

It is not so much about that you have to do it, but about what would be the best place to do it. The point of these protocols is usually that you want to keep the engine side as simple as possible, (because there are far more engines than GUIs) so that it is better to make the mapping of the white and black clock onto commands on the GUI side rather than to burden the engine with this extra task. (Which to some here apparently is a very big deal...) That would make the 'time'/'oppotime' system (as used in CECP and UCCI) preferable over the 'wtime'/'btime' system (as used in UCI and USI).

Of course if there is no need to send both, because one of the two would be completely useless, it makes no sense to have two separate commands for this at all. So with fixed time per move (where the engine is not supposed to make any timing decisions other than just use the specified time) UCI simply uses 'movetime', without diversifying into white and black times.

It is kind of interesting that none of the qualifiers to a 'go' command are mandatory, according to the specs. It would be perfectly allowed to only send wtime or only btime. I don't expect there to be any GUI that does that, though, and consequently there are probably many engines that would choke on a missing wtime or btime. I suppose that a completely bare 'go' should default to go-infinite.

elcabesa
Posts: 806
Joined: Sun May 23, 2010 11:32 am
Contact:

Re: UCI pondering done right

Post by elcabesa » Fri Dec 21, 2018 10:11 am

hgm wrote:
Fri Dec 21, 2018 9:09 am
I suppose that a completely bare 'go' should default to go-infinite.
I think it's an undefined behaviour. Vajolet implemented an empty go command as go infinite. But it was because I'm lazy. Stockfish for example do a very very short search

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

Re: UCI pondering done right

Post by hgm » Fri Dec 21, 2018 10:30 am

Well, the specs say:
If one command is not send its value should be interpreted as it would not influence the search.
So I supposed that if you do not specify any time restriction, the search should not stop after any specific time, just as when you omit 'nodes' it should not stop after some number of nodes, or when you omit 'depth' it should not stop after reaching a certain depth.
The distinction between go-infinite and go-ponder seems to be purely this "can do whatever it wants" in the ponder case. So if you do the normal thing there would be no reason for the engine to distinguish the two.

Ras
Posts: 1140
Joined: Tue Aug 30, 2016 6:19 pm
Contact:

Re: UCI pondering done right

Post by Ras » Fri Dec 21, 2018 10:59 am

hgm wrote:
Fri Dec 21, 2018 9:09 am
It would be perfectly allowed to only send wtime or only btime. I don't expect there to be any GUI that does that, though, and consequently there are probably many engines that would choke on a missing wtime or btime.
If only one of wtime/btime is given, my parser will evaluate the other to 0, which doesn't matter because I don't use it anyway. It's just to avoid undefined behaviour with regard to uninitialised variables.
I suppose that a completely bare 'go' should default to go-infinite.
Everything except a crash is OK; I default to 5 seconds.
So I supposed that if you do not specify any time restriction, the search should not stop after any specific time, just as when you omit 'nodes' it should not stop after some number of nodes, or when you omit 'depth' it should not stop after reaching a certain depth.
That's actually a valid argument for consistent behaviour.

Btw., there is an interesting corner case if wtime/btime are given after searchmoves like in

Code: Select all

go searchmoves e2e4 d2d4 wtime 1000 btime 1000 movestogo 2
A lot of engines will fail to parse this properly. Although the UCI spec does not say that the searchmoves list must be the last parameter, every GUI I know does this, and most engines rely on this unspecified behaviour. The correct way to evaluate searchmoves is to stop parsing it until either the string end has been reached, or the next token is not a move of the form e2e4 with optional promotion parameter.
Rasmus Althoff
https://www.ct800.net

Ras
Posts: 1140
Joined: Tue Aug 30, 2016 6:19 pm
Contact:

Re: UCI pondering done right

Post by Ras » Fri Dec 21, 2018 12:21 pm

Btw., "go infinite" as default isn't quite consistent either because that also obliges the engine never to stop on its own even if it reaches mate or maximum depth, but an empty go does not impose such an obligation. A big default time, for all practical purposes infinite, but without the "don't ever stop" meaning of "go infinite" seems to be more logical.
Rasmus Althoff
https://www.ct800.net

Michel
Posts: 2038
Joined: Sun Sep 28, 2008 11:50 pm

Re: UCI pondering done right

Post by Michel » Sat Dec 22, 2018 3:09 pm

Ras wrote:
Fri Dec 21, 2018 10:59 am

Everything except a crash is OK; I default to 5 seconds.
Funny that you say this. The SF maintainers will argue that a crash is a perfectly valid and even desirable reaction to an illegal command since otherwise writing an UCI parser is too complicated...
Ideas=science. Simplification=engineering.
Without ideas there is nothing to simplify.

Post Reply