UCI Win/Draw/Loss reporting

[Ras]

A programmer can display any data he wants in good visual forms without waiting for chess GUI developers to add them.

That's not an advantage, that's a disadvantage. A GUI is supposed to look the same no matter which engine is running underneath. Consistency is an important part of usability.

Also, the engine should totally not be concerned with how the data look like, this is just a horrible idea.

[phhnguyen]

A programmer can display any data he wants in good visual forms without waiting for chess GUI developers to add them.

That's not an advantage, that's a disadvantage. A GUI is supposed to look the same no matter which engine is running underneath. Consistency is an important part of usability.

What do you mean "look the same"?

Simply It can't, IMHO. At this moment engines have been different from engines already. Some engines print out strings, messages but others don't. Comparing with WB engines, UCI ones may have some extra info such as hash full, table hits... You are talking on a topic about reporting WDL stats that older engines don't have. Look like you are not aware of the needs of new engine types such as Lc0 which its output is quite different from others. E.g., Lc0 does not have "typical" scores but they are actually probabilities. Lc0 also wants to show many stats to users/developers which normal way can't help.

I did not mention anything bigger, just how to communicate between engines-GUIs to transmit that stats (WDL stats) as well as further ones. Based on data, its attributes and settings GUIs will decide how to display them to users.

Frankly speaking, I get bored if all engines-GUIs are looked totally the same both inside and outside from ones of the 1990s.

Also, the engine should totally not be concerned with how the data look like, this is just a horrible idea.

Why not? Any wrong? Having a voice is better than being completely passive. Please think out of the box.

I have noted your opinion/idea as a vote down, but let try it and let the majority decide if that data format (JSON-self-explaining data) is useful or not. Let them a chance to try new ways. If someone doesn't like it, he can ignore it by not turning on (let UCI_JSONExtension be false).

[Twipply]

I may add, uci protocol encourages clear key names, example,
info depth, the word depth is fully spelled out.
info score, the word score is fully spelled out too.
info multipv and others.

wdl is not clear, is it probability? is it a counter of something?
winprob is more clearer to denote win probability.
Or even better is winprobpct to denote win probability in percent.

"seldepth" is not fully spelt out, what's that?
"score cp" what's that?
"score mate" ply? moves?

"wtime" is not clear, is it seconds? Centiseconds? Milliseconds?
"hashfull" is not clear, is it hundredths? Thousandths? A boolean?

There's lots of questions you can ask if all you do is look at the output, but as programmers following a specification we should be able to and be expected to actually read it. Regular engine users should not be expected to read or understand UCI output. I don't see what's wrong with "wld" or "wdl", I think it's succinct.

[hgm]

Well, what is most wrong about 'wdl' as proposed is that it is partly redundant: the three values must sum up to 100. It would be more elegant to have the expected score (winprob + drawprob/2) as a new score mode (as alternative to 'mate' and 'cp'), and add a new info 'drawprob' with a single value. But it is more difficult to make that backward compatible.

I still think the most versatile extension is through a string option UCI_pvinfos, that can communicate a (space-separated) list of non-standard info names that the GUI will treat as keywords for infos it can present to the user. Engines can then refrain from sending the corresponding infos for items the GUI would not recognize. The recommended mode of presentation is as additional columns in the Engine Output display that shows the engine's PVs.

To add flexibility a 'wild-card' info can be defined, e.g. 'any'. If a GUI sets the value of UCI_pvinfos to 'any', the engine can include items with names of its own making in the PV info. The parsing of the info commands will then consider any alphabetic token that is not recognized as a keyword to be the name of an engine-defined info, and assumes the token following it to be its value. It will then create a column with that name in its Engine Output display to present the values of that item. (An alternative would be to consider all tokens following it up to the next identifier to be its value, but frankly speaking I see very little value of allowing multiple numeric infos in a single column; that is just a recipe for messing up the formatting.)

This seems to a large extent 'future proof'. It gives people the opportunity to argue about which infos are useful and which not, and whether they should have standardized names, without having to worry about how the protocol would treat them.

[abulmo2]

Well, what is most wrong about 'wdl' as proposed is that it is partly redundant: the three values must sum up to 100. It would be more elegant to have the expected score (winprob + drawprob/2) as a new score mode (as alternative to 'mate' and 'cp'), and add a new info 'drawprob' with a single value.

Personally, I would appreciate do distinguish between moves with wdl 20% 80% 0% and wdl 40% 40% 20%.
Otherwise it is quite easy to convert w + d/2 into cp.

[hgm]

This is why you need drawprob as a new info, next to score.

[Gian-Carlo Pascutto]

Well, what is most wrong about 'wdl' as proposed is that it is partly redundant: the three values must sum up to 100. It would be more elegant to have the expected score (winprob + drawprob/2) as a new score mode (as alternative to 'mate' and 'cp'), and add a new info 'drawprob' with a single value. But it is more difficult to make that backward compatible.

I agree that EV + drawscore is actually more useful than WDL. At least that's how I prefer to think about the game! And it's what Stoofvlees actually computes internally...I suspect it's the same for lc0.

I still think the most versatile extension is through a string option UCI_pvinfos, that can communicate a (space-separated) list of non-standard info names that the GUI will treat as keywords for infos it can present to the user. Engines can then refrain from sending the corresponding infos for items the GUI would not recognize. The recommended mode of presentation is as additional columns in the Engine Output display that shows the engine's PVs.

This gives you a way to give info on the PV only. But an MCTS engine can reasonably dump its entire search tree, if wanted (and it could be useful)

Personally that's why, even though I'm no fan of JSON, the JSON proposal seems appealing to me: it makes it very natural to send the same infos *in a tree structure*. You proposed using PGN variations but those are way harder to parse than JSON (ever tried to get ChessBase to understand RAV?).

To add flexibility a 'wild-card' info can be defined, e.g. 'any'. If a GUI sets the value of UCI_pvinfos to 'any', the engine can include items with names of its own making in the PV info. The parsing of the info commands will then consider any alphabetic token that is not recognized as a keyword to be the name of an engine-defined info, and assumes the token following it to be its value. It will then create a column with that name in its Engine Output display to present the values of that item. (An alternative would be to consider all tokens following it up to the next identifier to be its value, but frankly speaking I see very little value of allowing multiple numeric infos in a single column; that is just a recipe for messing up the formatting.)
This seems to a large extent 'future proof'. It gives people the opportunity to argue about which infos are useful and which not, and whether they should have standardized names, without having to worry about how the protocol would treat them.

Again, this applies to the PV only. And your concerns about messing up the formatting: exactly why JSON makes sense!

[Ferdy]

I may add, uci protocol encourages clear key names, example,
info depth, the word depth is fully spelled out.
info score, the word score is fully spelled out too.
info multipv and others.

wdl is not clear, is it probability? is it a counter of something?
winprob is more clearer to denote win probability.
Or even better is winprobpct to denote win probability in percent.

"seldepth" is not fully spelt out, what's that?
"score cp" what's that?
"score mate" ply? moves?

"wtime" is not clear, is it seconds? Centiseconds? Milliseconds?
"hashfull" is not clear, is it hundredths? Thousandths? A boolean?

There's lots of questions you can ask if all you do is look at the output, but as programmers following a specification we should be able to and be expected to actually read it. Regular engine users should not be expected to read or understand UCI output. I don't see what's wrong with "wld" or "wdl", I think it's succinct.

That is why I use the word "encourages". If someone wants another key name info, it must be something easily understood. Try to avoid sending a user/programmer to a documentation.

[hgm]

Again, this applies to the PV only. And your concerns about messing up the formatting: exactly why JSON makes sense!

Indeed, this is for PV info only. That is the only info for which I would be prepared to accept 'engine-defined' info. I don't think it is desirable (or feasible) to send complex data structures to a GUI that has no clue to what they represent, and have the GUI figure out a way to present it to the user. Note that presenting a move tree to the user as a table or a tree widget would still be parctically useless if the moves were in coordinate notation. The user would want them to be presented as SAN. Which the GUI could not do if it doesn't know that the data represents moves, or what the positions are from which these moves are supposed to be made. For doing that kind of thing there really must be a well-defined protocol both parties are aware of in advance.

Parsing data grouped by (nested) parentheses is completely trivial. I don't see any advantage of JSON above that. Unless the addition of tons of redundant commas, quotes, semicolons, unused tag names to make the output pretty much unreadable would count as an advantage. Which in UCI it of course arguably could be the case.

[Ras]

What do you mean "look the same"?

That it must not matter which engine the GUI loads, it must look the same. That some parameters like hashfull are optional in UCI is a completely different story from sending tabular data and as you suggested even with colour formatting, arrows and whatnot.

ou are talking on a topic about reporting WDL stats that older engines don't have.

That's no reason to start putting the engine in control of how the UI looks like, and especially not with UCI where the GUI is in control, not the engine. Adding WDL is of course fine, but absolutely no argument for sending tabular data with coloured arrows and such nonsense.

Frankly speaking, I get bored if all engines-GUIs are looked totally the same both inside and outside from ones of the 1990s.

Then make a completely different GUI. But as I already pointed out, consistency is an important part of usability, and that you are bored is no reason to suddenly put the engine in control so that the data display suddenly looks completely different with each engine. Users do NOT want this.

Why not? Any wrong?

Because it's obviously awful software design, that's why. MVC anyone? Decades of established software design practice? Layered architecture? Why do we even have the engine/GUI separation instead of as in the 90s where GUIs and egines were usually a single program?

It's like building a car where the tyre manufacturer comes up with the idea that the tyres should do the route planning.