This won't work for reasons already outlined in my post. The engine has no idea how much detail the GUI wants. And you can send enough info the make the GUI crawl...
HGM's idea seems fine.
Moderators: hgm, Rebel, chrisw
This won't work for reasons already outlined in my post. The engine has no idea how much detail the GUI wants. And you can send enough info the make the GUI crawl...
How do you feel about using JSON (as crem suggested) over UCI-style tag info?hgm wrote: ↑Wed Oct 23, 2019 2:22 pm This tells the engine what extra infos it can put in an 'info' command that the GUI knows how to display. If the GUI says it understands 'wdl', the engine can put wdl info with its PV, otherwise it will refrain from doing so. (Or it will find some backward-compatible way to display the info, like 'info string'). It is up to the community to negociate what infos they want GUIs to display, and what keyword to define for the ability to do so.
I suggest instead of focusing on WDL only, we may design a kind of self-explain data, in which engines can tell chess GUIs how to display their data.Gian-Carlo Pascutto wrote: ↑Wed Oct 23, 2019 1:16 pm Let me put it differently: with some more work (i.e. thinking about enable/disable info issue) it might be possible to specify a way to send more info inside UCI that could contain WDL and also serve as a well-designed vehicle for transmitting more information (which still has to be specified, because JSON by itself doesn't solve that).
Code: Select all
uci json {"table": ["W": 60, "D": 20, "L": 20]}
Code: Select all
uci json {"arrows": [{cells: "a1c3", "color": 0xff00}, {cells: "d7c3", "color": 0x00ff00}}
Code: Select all
uci json {"bubbles": [{cell: "a1", "color": 0xff00, "values": [3, 5]}}
For me, a chess-hobby programmer, "a good carrot" is that my freeware will be useful for many people. More challenge is actually more interest. If you think that is useful for the long term, go ahead, we will sooner or later support you.Gian-Carlo Pascutto wrote: ↑Wed Oct 23, 2019 1:16 pm But introducing JSON seems like a large barrier for just getting WDL info. So I'm not sure this is a good carrot to get GUI people to implement something.
That is why I agreed with your suggestion:Gian-Carlo Pascutto wrote: ↑Wed Oct 23, 2019 3:01 pmThis won't work for reasons already outlined in my post. The engine has no idea how much detail the GUI wants. And you can send enough info the make the GUI crawl...
HGM's idea seems fine.
Code: Select all
option name UCI_JSONExtension type check default false
Perhaps simpler and more uci way of communicating is by key value pair. Example,Gian-Carlo Pascutto wrote: ↑Tue Oct 22, 2019 11:22 am Someone pointed me a while ago (I forgot where, might've been TCEC chat) to this: https://github.com/DanielUranga/lc0/com ... 0df2f06db2
Which is allegedly how Fat Fritz does WDL reporting?
I have no idea if this is accurate, but in general I feel it would be useful to standardize some format if we want to report this information to interfaces. Based on the above patch, I suggest:
option name UCI_ShowWDL type check default false
If this is toggled to enabled, the engine will include wdl info in the info updates. Making it optional prevents interfaces from breaking, even though UCI does say the interface should ignore stuff it doesn't understand. But depending on the option seems safer as UCI is widely deployed and currmove etc use the same technique. GUIs which don't know about the option (and can't show wdl anyway) won't show it, if they're correctly implemented (UCI spec says UCI_ options shouldn't be displayed to the user).
For the wdl reporting itself I will use the format from the above patch, i.e.:
info depth 16 seldepth 62 time 11780 nodes 65546 tbhits 0 score cp 25 wdl 210 608 181 nps 5564 hashfull 201 multipv 1 pv d2d4 g8f6 c2c4 e7e6 g1f3 d7d5 b1c3 f8b4 c1g5 h7h6 g5f6 d8f6 d1a4 b8c6 e2e3 e8g8 f1e2 c8d7 a4b3 d5c4 b3c4 f6e7 e1g1 b4d6 c3e4 e6e5 d4d5 c6d8
So
wdl win_probability_in_permille draw_probability_in_permille loss_probability_in_permille
In the above example, win probability = 21.0%, draw probability = 60.8% and loss probability = 18.1%. Note that due to rounding they might not sum to 100% exactly.
Engines that don't have an explicitly draw probability calculation can still obtain a good estimate from looking at the absolute score (i.e. say 65% at eval = 0 and 1% at eval = +300 with interpolation, to give a random example) so using this format shouldn't block them. (And really, draw probabilities are very useful to users I think...)
Unless there's a very compelling reason to not use this format, I'll go ahead and use this in Stoofvlees, and would encourage others to do the same.
Code: Select all
winprob 20 drawprob 60 lossprob 20
Code: Select all
score winprob 20 score drawprob 60 score lossprob 20
Code: Select all
info string winprob 20 drawprob 60 lossprob 20
Code: Select all
info string I don't like your bishop location currently pointing to my king, will terminate it in 3 moves.
I don't see the benefit of having extra tags. We don't send a pv either with pv e4e4 pv e7e5 pv g1f3. I also don't see how it is simpler, looks the opposite to me.Ferdy wrote: ↑Wed Oct 23, 2019 4:09 pm Perhaps simpler and more uci way of communicating is by key value pair. Example,values like 20, 60 and 20 are in percent.Code: Select all
winprob 20 drawprob 60 lossprob 20
This puts the burden of inventing something meaningful there to the GUI, which seems bad.On winning position one may just send winprob 99 and ignore draw and loss prob.
If position is drawish,
drawprob 100 and skip sending winprob and lossprob.
I wondered whether it should be written as score wdl 20 50 39, because the UCI protocol has some options there, but it's not clear why the grouping around score exists. I don't think wdl is exclusive to providing cp OR mate, so I explicitly avoided saying the grouping is required.Another option is to put those under score info. Example,Code: Select all
score winprob 20 score drawprob 60 score lossprob 20
This is freeformat and engines already put freeformat stuff there so that would be a compatibility nightmare if the GUI has to go and hunt for something meaningful in there. If you agree that it only does that when some setoption is done we're basically where we are now except there's a proposal to use JSON. There's no need for backwards compat if the setoption exists, and if the setoption doesn't exist then existing GUIs will be overflowed with garbage. So not a good idea.Another method of sending those info is just to use info string format.
Who has what bug?
The only question is whether to use permill or percent. Given that hashfull and cpuload both report in permill, wdl should also use permill for consistency.* if the engine or the GUI receives an unknown command or token it should just ignore it and try to parse the rest of the string in this line.
Examples: "joho debug on\n" should switch the debug mode on given that joho is not defined, "debug joho on\n" will be undefined however.