UCI pondering done right

[hgm]

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.

[lucasart]

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

[hgm]

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

* lucasart is a troll

[noobpwnftw]

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.

[hgm]

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]

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

[hgm]

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]

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.

[Ras]

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.

[Michel]

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...