UCI pondering done right

[hgm]

Joker uses opponent time. It is silly to elevate what Fairy-Max does to a standard, as it is a minimalist engine that was stripped of virtually everything. By that reasoning engines should not ponder, should have no evaluation other than material, no piece-square tables, no King safety.

None of that matters, though. Either opponent time is important, and then the GUI should supply it (at a time when it is available!), or it is not, and then the protocol should not require its sending at all. Your argument about extra if-statements is non-sensical. A protocol that would only send the time of the thinking engine would of course not have wtime and btime commands, but just a single 'time' and 'inc' parameter. There would be fewer keywords to recognize, not more, and no choice to make which time to ignore based on who has the move.

[Ras]

It is silly to elevate what Fairy-Max does to a standard, as it is a minimalist engine that was stripped of virtually everything.

When something is so important that you even claim a protocol design flaw, one would expect that you'd use it consistently, given that it can't be that complicated. Plus that kingslayer is a bit more than minimal. Can't comment on Joker of course, but I would be surprised if the usage implementation were rocket science.

Your argument about extra if-statements is non-sensical.

The problem with this general way of thinking is that it easily leads into a messy protocol ecosystem, with CECP as cautionary tale how not to do it.

A protocol that would only send the time of the thinking engine would of course not have wtime and btime commands

In which case position and go would be unnecessarily tightly coupled in this aspect.

[hgm]

When something is so important that you even claim a protocol design flaw, one would expect that you'd use it consistently, given that it can't be that complicated. Plus that kingslayer is a bit more than minimal. Can't comment on Joker of course, but I would be surprised if the usage implementation were rocket science.

Total bullshit. A protocol is supposed to support everything a user could ever want. Not only what the most minimal and intentionally crippled implementation (in order to make it minimal) happens to use.

The problem with this general way of thinking is that it easily leads into a messy protocol ecosystem, with CECP as cautionary tale how not to do it.

So you say. But even if it would have any meaning (e.g. it is totally unclear what "this general way of thinking" is supposed to mean), without any proof this could just as easily paranoia on your part.

The only "way of thinking" invoked by me so far is that:
* it is a flaw to require sending of data at a time that it cannot possibly be available
* it is a flaw to require sending of data that is irrelevant

The burden of proof that these two principles unavoidably lead to a mess is entirely on you.

In which case position and go would be unnecessarily tightly coupled in this aspect.

"Unnecessary" only in your judgement, of course. Like in: "we decided not to save this traffic victim's life, because that would have required unnecessary medical treatment". Or, closer to home: "it is a real flaw of UCI that it doesn't require keywords to be separated by at least 500 spaces, because that makes the commands unnecessary short". That kind of "unnecessary".

Designing a protocol is not a contest for weakly or tightly coupling commands. No one cares a hoot about this, especially since the position and go commands are very tightly coupled already, so much in fact that for practical purposes they can be considered a single command. What matters is how easy it is to implement, in particular from the engine side.

If you let your judgement of protocols be dominated by utterly subjective aestetic criteria, rather than by its power or ease of implementation, it is no wonder that you get to these weird conclusions. You should not be surprised, though, if I (and others) would attach zero weight to these conclusions.

[Ras]

You should not be surprised, though, if I (and others) would attach zero weight to these conclusions.

Well, it looks like we have very different opinions what makes a good protocol. Good that I ripped out existing inherited CECP support in my V1.12 in favour of UCI so that I don't have to deal with the fallout anymore.

[abulmo2]

The only "way of thinking" invoked by me so far is that:
* it is a flaw to require sending of data at a time that it cannot possibly be available
* it is a flaw to require sending of data that is irrelevant

You are right, but it is a minor detail, of which nobody cares about among the UCI engines (ie 95% of the 50 strongest programs).
Bad naming of commands, like hard/easy to means pondering on/off is a much major flaw that makes many programmers (including me) to flee away from the winboard protocol.

[Evert]

Bad naming of commands, like hard/easy to means pondering on/off is a much major flaw that makes many programmers (including me) to flee away from the winboard protocol.

Well, “hard” means “switch the engine to hard difficulty”, which implied that it would ponder, in some old version of GNU Chess. “Easy” is just the reverse of that. It’s not particularly strange.
Naturally it would have been nice if CECP protocol had “ponder on/off” as a command instead of an ambiguous GNU Chess legacy command, but is it worth breaking all existing engines and GUIs to fix that?

[hgm]

Well, personally I think that is the most silly reason I have ever heard to reject a protocol. A bit at the same level as why they did not want to use standard Pascal as a programming language in Quebec, but made their own dialect by replacing the keywords BEGIN / END by DEBUT / FIN... (Which gave a nasty surprise if you forgot to switch on the option ANGLAIS in the compiler-compiler they distributed.)

Anyway, isn't it strange that people who worship UCI in the end always feel the need to fall back on the argument that CECP sucks? Like that would have any bearing whatsoever on the quality of UCI?

CECP was not the subject of discussion here. It was just noted that UCI is very poorly designed, and it was discussed how it could have beeen designed in a much better way, where none of the proposals were even remotely CECP-like. Yet an irrational dislike for CECP is now apparently the only 'argument' left standing to fight the sacrilegial idea that things could have been better.

[Ras]

Anyway, isn't it strange that people who worship UCI in the end always feel the need to fall back on the argument that CECP sucks?

No, it's not strange because you aren't just someone independent. When someone that involved in CECP v2 development routinely bashes UCI, it's just fair to take a comparison.

[hgm]

No, it is off-topic, stalking and stupid. If only because I am just as much involved in UCI / USI / UCCI as in CECP. But mostly of course because claiming something must be perfect because you think something completely unrelated sucks just makes no sense at all.

[Ras]

But mostly of course because claiming something must be perfect because you think something completely unrelated sucks just makes no sense at all.

Perfection isn't the point, nothing is perfect. You argued that you don't see the value of uniform command handling, and that you don't see issues with unnecessary if/else code paths in protocol handlers. It's entrirely ontopic to point you to the complete mess that your way of "protocol design" has brought. UCI was largely created to get rid of the mess created by people who don't understand the value of uniformly handling things.