UCI Win/Draw/Loss reporting

Discussion of chess software programming and technical issues.

Moderators: hgm, Rebel, chrisw

Fulvio
Posts: 395
Joined: Fri Aug 12, 2016 8:43 pm

Re: UCI Win/Draw/Loss reporting

Post by Fulvio »

crem wrote: Thu Oct 31, 2019 11:18 am I'll probably do UCI_ShowWDL (default off)
This is probably the safest option for backward compatibility.
However, if it can be proved that almost all the GUIs will just ignore the additional wdl info, I think it would be best to not add any option at all.
Fulvio
Posts: 395
Joined: Fri Aug 12, 2016 8:43 pm

Re: UCI Win/Draw/Loss reporting

Post by Fulvio »

hgm wrote: Thu Oct 31, 2019 4:44 pm I thought UCI options were not case sensitive.
In many GUIs the options are showed to the user without modifying the case.
Also some people save the output of the engine to a txt file.
For example Stockfish almost fully respect that convention:

Code: Select all

option name Debug Log File type string default
option name Contempt type spin default 24 min -100 max 100
option name Analysis Contempt type combo default Both var Off var White var Black var Both
option name Threads type spin default 1 min 1 max 512
option name Hash type spin default 16 min 1 max 131072
option name Clear Hash type button
option name Ponder type check default false
option name MultiPV type spin default 1 min 1 max 500
option name Skill Level type spin default 20 min 0 max 20
option name Move Overhead type spin default 30 min 0 max 5000
option name Minimum Thinking Time type spin default 20 min 0 max 5000
option name Slow Mover type spin default 84 min 10 max 1000
option name nodestime type spin default 0 min 0 max 10000
option name UCI_Chess960 type check default false
option name UCI_AnalyseMode type check default false
option name SyzygyPath type string default <empty>
option name SyzygyProbeDepth type spin default 1 min 1 max 100
option name Syzygy50MoveRule type check default true
option name SyzygyProbeLimit type spin default 7 min 0 max 7
and notice how ugly is "nodestime" compared to the others.
crem
Posts: 177
Joined: Wed May 23, 2018 9:29 pm

Re: UCI Win/Draw/Loss reporting

Post by crem »

Fulvio wrote: Thu Oct 31, 2019 5:05 pm
hgm wrote: Thu Oct 31, 2019 4:44 pm I thought UCI options were not case sensitive.
In many GUIs the options are showed to the user without modifying the case.
Also some people save the output of the engine to a txt file.
For example Stockfish almost fully respect that convention:

Code: Select all

option name Debug Log File type string default
option name Contempt type spin default 24 min -100 max 100
option name Analysis Contempt type combo default Both var Off var White var Black var Both
option name Threads type spin default 1 min 1 max 512
option name Hash type spin default 16 min 1 max 131072
option name Clear Hash type button
option name Ponder type check default false
option name MultiPV type spin default 1 min 1 max 500
option name Skill Level type spin default 20 min 0 max 20
option name Move Overhead type spin default 30 min 0 max 5000
option name Minimum Thinking Time type spin default 20 min 0 max 5000
option name Slow Mover type spin default 84 min 10 max 1000
option name nodestime type spin default 0 min 0 max 10000
option name UCI_Chess960 type check default false
option name UCI_AnalyseMode type check default false
option name SyzygyPath type string default <empty>
option name SyzygyProbeDepth type spin default 1 min 1 max 100
option name Syzygy50MoveRule type check default true
option name SyzygyProbeLimit type spin default 7 min 0 max 7
and notice how ugly is "nodestime" compared to the others.
I also like the consistency in using spaces vs underscores vs camelCase for multiword params.
User avatar
hgm
Posts: 27788
Joined: Fri Mar 10, 2006 10:06 am
Location: Amsterdam
Full name: H G Muller

Re: UCI Win/Draw/Loss reporting

Post by hgm »

Fulvio wrote: Thu Oct 31, 2019 5:05 pmFor example Stockfish almost fully respect that convention:
But this becomes a decision of the engine author. No matter what we define as a standard name, the case insensitivity gives the engine author the freedom to 'style' the option name in any way he prefers.

Most likely, what he will prefer for this option would not be inconsistent with what he prefers for the other options.

As to the use of spaces: these are very nice in options intended to be shown to the user. (Although one could argue it is a bad idea to show them to the user at all, as in the end the authors almost never resist their tendency to use cryptic names. And it also defeats internationalization attempts; e.g. compare how this is handled in USI.) But standard options should never be shown, and spaces there are just a pain.
Ras
Posts: 2487
Joined: Tue Aug 30, 2016 8:19 pm
Full name: Rasmus Althoff

Re: UCI Win/Draw/Loss reporting

Post by Ras »

hgm wrote: Thu Oct 31, 2019 4:44 pmI thought UCI options were not case sensitive.
That's correct as per the UCI spec:
The name and value of the option in <id> should not be case sensitive and can inlude spaces.
But it should still fit in with the other parameters of the UCI spec - if it is even necessary, which it shouldn't be.

Fulvio wrote: Thu Oct 31, 2019 4:50 pmHowever, if it can be proved that almost all the GUIs will just ignore the additional wdl info, I think it would be best to not add any option at all.
Especially because engines like LC0 score only in terms of probability - without WDL support, there is no meaningful eval display possible. Printing the score in centipawns and expecting the user to know this is meant as win score expectation is a bad hack anyway. The other way around fails also because LC0 cannot just print the eval in centipawns instead.

Also, UCI actually requires the GUI not to stop the parsing once it encounters something unknown, but to continue with the rest of the line. So a "wdl" in the info string gets ignored, and then one or three permill numbers follow which get also ignored because they don't mean anything, and things continue with the next valid token.
Rasmus Althoff
https://www.ct800.net
User avatar
hgm
Posts: 27788
Joined: Fri Mar 10, 2006 10:06 am
Location: Amsterdam
Full name: H G Muller

Re: UCI Win/Draw/Loss reporting

Post by hgm »

In UCI2WB I just scan with strstr (or StrCaseStr) for the keywords of the standard infos, and then read the token that follows them as the corresponding value. So it would indeed just ignore the 'wdl' and its parameters.

This is not optimally efficient; it would be better to just scan through the info string once testing every token for being an info name (e.g. through a small hash table of keywords). Then you only have to traverse the info string once. But I was lazy, and just repeating the strstr on the entire string produced the simplest code.
Rémi Coulom
Posts: 438
Joined: Mon Apr 24, 2006 8:06 pm

Re: UCI Win/Draw/Loss reporting

Post by Rémi Coulom »

Ras wrote: Thu Oct 31, 2019 6:56 pm Especially because engines like LC0 score only in terms of probability - without WDL support, there is no meaningful eval display possible. Printing the score in centipawns and expecting the user to know this is meant as win score expectation is a bad hack anyway. The other way around fails also because LC0 cannot just print the eval in centipawns instead.
You can use the logit of the probability of winning, and multiply it by a constant so that it looks like centipawns. I do this for my program, and it works very well.
ernest
Posts: 2041
Joined: Wed Mar 08, 2006 8:30 pm

Re: UCI Win/Draw/Loss reporting

Post by ernest »

Rémi Coulom wrote: Thu Oct 31, 2019 11:33 pm
You can use the logit of the probability of winning, and multiply it by a constant so that it looks like centipawns. I do this for my program, and it works very well.
Salut Rémi,

So logit, rather than the current tg/arctg ?... :wink:
User avatar
phhnguyen
Posts: 1434
Joined: Wed Apr 21, 2010 4:58 am
Location: Australia
Full name: Nguyen Hong Pham

Re: UCI Win/Draw/Loss reporting

Post by phhnguyen »

hgm wrote: Thu Oct 31, 2019 9:16 pm In UCI2WB I just scan with strstr (or StrCaseStr) for the keywords of the standard infos, and then read the token that follows them as the corresponding value. So it would indeed just ignore the 'wdl' and its parameters.

This is not optimally efficient; it would be better to just scan through the info string once testing every token for being an info name (e.g. through a small hash table of keywords). Then you only have to traverse the info string once. But I was lazy, and just repeating the strstr on the entire string produced the simplest code.
I guess all GUIs scan for keywords too, thus it is safe to put anything programmers want, just avoid keywords.

However, give wrong data types for known keywords may be a problem. For example,

Code: Select all

info depth abc
(a string instead of a number) may make some GUIs crash.
https://banksiagui.com
The most features chess GUI, based on opensource Banksia - the chess tournament manager
Fulvio
Posts: 395
Joined: Fri Aug 12, 2016 8:43 pm

Re: UCI Win/Draw/Loss reporting

Post by Fulvio »

hgm wrote: Thu Oct 31, 2019 9:16 pm In UCI2WB I just scan with strstr (or StrCaseStr) for the keywords of the standard infos, and then read the token that follows them as the corresponding value. So it would indeed just ignore the 'wdl' and its parameters.

This is not optimally efficient; it would be better to just scan through the info string once testing every token for being an info name (e.g. through a small hash table of keywords). Then you only have to traverse the info string once. But I was lazy, and just repeating the strstr on the entire string produced the simplest code.

Code: Select all

void parseInfoUCI(const char* info) {
    long valueNum;
    const char* value;
    while ((value = strchr(info, ' ')) != NULL) {
        //Calculate length and skip the space
        switch (value++ - info) {
        case 2:
            if (memcmp(info, "pv", 2) == 0) {
                // Do something with value
                return;
            }
            break;
        case 3:
            if (memcmp(info, "nps", 3) == 0) {
                valueNum = strtol(value, (char**) &info, 10);
                // Do something with valueNum
                continue;
            }
        /// etc...        
        }

        // Unknown: ignore it
        info = value;
    }
}