Pv output/thinking shows in Arena, but not in Winboard

[Jim Ablett]

This is annoying and I want to understand why this happens.
I add winboard protocol to an engine such as Alibaba,
pv output/thinking lines work fine in Arena, but in Winboard it
just doesn't want to show.
This happen with a few other engines such as Mskcp.

Jim.

[H.G.Muller]

This is the line in WB that tests if a line of engine output ('message') is to be considered thinking output:

Code: Select all

       if (sscanf(message, "%d%c %d %d %lu %[^\n]\n",
             &plylev, &plyext, &curscore, &time, &nodes, buf1) >= 5) {


So the condition seems to be that it should start with 4 integers, where an arbitrary character would be allowed to follow the first integer. (But better not put anything else than a space or tab there, as with other characters WB will assume you are GNU Chess, and multiplies the time by 100, as GNU Chess reports in seconds.)

If WB does not accept an engine line as thinking output, it must be because it does not contain 4 integers. I don't know enough about the scanf format to see it there need to be at least 2 spaces between the first and second number, or that a single space would do.

[Michel]

I don't know enough about the scanf format to see it there need to be at least 2 spaces between the first and second number, or that a single space would do.

A space stands for any number of spaces, including zero.

[Sven Schüle]

This is the line in WB that tests if a line of engine output ('message') is to be considered thinking output:

Code: Select all

       if (sscanf(message, "%d%c %d %d %lu %[^\n]\n",
             &plylev, &plyext, &curscore, &time, &nodes, buf1) >= 5) {


So the condition seems to be that it should start with 4 integers, where an arbitrary character would be allowed to follow the first integer. (But better not put anything else than a space or tab there, as with other characters WB will assume you are GNU Chess, and multiplies the time by 100, as GNU Chess reports in seconds.)

If WB does not accept an engine line as thinking output, it must be because it does not contain 4 integers. I don't know enough about the scanf format to see it there need to be at least 2 spaces between the first and second number, or that a single space would do.

The format string given above:

Code: Select all

"%d%c %d %d %lu %[^\n]\n"

expects an integer, followed by one character which could be a whitespace but obviously not [0-9], followed by zero or more whitespaces, followed by an integer, and so on. So if an engine prints "66 77 88 99 e2e4", to choose a silly but syntactically correct example, then the first space char between "66" and "77" should be matched by the "%c", and the "77" should be matched by the second "%d" since the first space char in the format string matches zero or more whitespaces from the input string.

So to summarize, one space between the first two numbers is sufficient. But unfortunately also "66@77" would be accepted by that format string, which is not intended at all by the WB protocol.

Using sscanf() can be horrible sometimes. The WB code will probably not be changed anymore at this point but when writing new code I would never recommend to use sscanf() for this type of parsing. It can be used for simpler cases, like "%s %s %s %s %s", but as soon as numbers, single characters and strings are involved and mixed somehow you may get into trouble, or at least the code will be difficult to understand, as we see here.

Sven

[H.G.Muller]

OK, so any number of spaces will do. So if output is not recognized as thinking output, it must be because it does not start with 4 integers.

[Guenther Simon]

This is how the output from Alibaba 1.2 looks in the debug:

Code: Select all

12629 >first : go
nps: w=-1, b=-1
12639 <first : [0 positions remaining in transposition table]
12639 <first :
12639 <first :  h2-h3  ( 1/20)
12639 <first :  g2-g4  ( 2/20)
12639 <first :  1 -0.016      0.01s  4  g2-g4                                          1
12639 <first :  h2-h4  ( 3/20)
12639 <first :  1 -0.008      0.01s  12  c2-c4                                          1
12639 <first :  d2-d3  (10/20)
12639 <first :  1  0.008      0.01s  15  d2-d4                                          1
12649 <first :  e2-e3  (12/20)
12649 <first :  d2-d4  ( 1/20)
12649 <first :  c2-c4  ( 2/20)
12649 <first :  d2-d4  ( 1/20)
12659 <first :  c2-c4  ( 2/20)
12659 <first :  d2-d4  ( 1/20)
12669 <first :  c2-c4  ( 2/20)
12669 <first :  d2-d4  ( 1/20)
12679 <second: pong 1
12679 <first :  c2-c4  ( 2/20)
12689 <first :  5 -0.020      0.06s  13158  c2-c4   e7-e5   e2-e4   f8-c5   a2-a4          5
12719 <first :  g2-g4  ( 3/20)
12809 <first :  c2-c4  ( 1/20)
12929 <first :  d2-d4  ( 2/20)
12989 <first :  6 -0.038      0.35s  106164  e2-e4   c7-c6   d2-d4   d7-d5   e4-d5   c6-d5  6
12999 <first :  f2-f3  (14/20)
13440 <first :  e2-e4  ( 1/20)
13440 <first :                       g1-e2                                          7
13800 <first :  c2-c4  ( 2/20)
14932 <first :  e2-e4  ( 1/20)
14932 <first :                       c3-e2   c7-c5   d2-d4  . c5-d4  d1-d4          11
16734 <first :  c2-c4  ( 2/20)
16734 <first : 1345867 nodes (int:529716, leaf:816151, quies:364060), 327860 n/s
16744 <first : 132080 filled (25.19%), 1598758 reads, 81982 hits ( 5.13%) 165648 writes
16754 <first : 4356274 moves in 144165 times (30.22)
16754 <first : move  e2-e4

[Sven Schüle]

So the 's' character at the end of the "time" part (third number) in the PV seems to be the offending one.

Sven

[Sven Schüle]

So the 's' character at the end of the "time" part (third number) in the PV seems to be the offending one.

Sven

It is even more than that, the time is printed with decimal point instead of as an integer meaning "centiseconds". The problem (for Alibaba) is in macro.h, line 281 (in the version I downloaded from Jim's site), and a quick fix could be to replace

Code: Select all

printf( " %8.2fs ", timeUsed );

by

Code: Select all

printf( " %d ", (int) (100 * timeUsed) );

For MSKCP it is a similar problem. In mskcp.c, both lines 1991 and 2007 contain

Code: Select all

printf("%i %+1.2f %.0f %i ", depth, best_score / 100.0, diff, nodes);

which should be changed into something like

Code: Select all

printf("%i %i %i %i ", depth, best_score, (int) (100 * diff), nodes);

Sven

[Jim Ablett]

So the 's' character at the end of the "time" part (third number) in the PV seems to be the offending one.

Sven

It is even more than that, the time is printed with decimal point instead of as an integer meaning "centiseconds". The problem (for Alibaba) is in macro.h, line 281 (in the version I downloaded from Jim's site), and a quick fix could be to replace

Code: Select all

printf( " %8.2fs ", timeUsed );

by

Code: Select all

printf( " %d ", (int) (100 * timeUsed) );

For MSKCP it is a similar problem. In mskcp.c, both lines 1991 and 2007 contain

Code: Select all

printf("%i %+1.2f %.0f %i ", depth, best_score / 100.0, diff, nodes);

which should be changed into something like

Code: Select all

printf("%i %i %i %i ", depth, best_score, (int) (100 * diff), nodes);

Sven

Thanks for the help guys.

Sven's fix worked for MsKcp (new version > http://www.mediafire.com/?m5fintztwze), but Alibaba still refuses to show anything.
I'm sure Sven's fix is correct so must be another issue that winboard doesn't like.

Jim.

[Sven Schüle]

I'm sure Sven's fix is correct so must be another issue that winboard doesn't like.

It may be correct but incomplete

There is a second place for Alibaba that should be changed since I overlooked that also the score is printed with decimals, while the protocol requests an integer measured in centipawns.

"macro.h", line 240 (in the PrintValue() macro) contains:

Code: Select all

printf( "%7.3f ", value*1.0/pieceValue[ WhitePawn ] /5 )

and should become something like:

Code: Select all

printf( "%d ", value )

Try again, please ...

Sven

[Jim Ablett]

I'm sure Sven's fix is correct so must be another issue that winboard doesn't like.

It may be correct but incomplete

There is a second place for Alibaba that should be changed since I overlooked that also the score is printed with decimals, while the protocol requests an integer measured in centipawns.

"macro.h", line 240 (in the PrintValue() macro) contains:

Code: Select all

printf( "%7.3f ", value*1.0/pieceValue[ WhitePawn ] /5 )

and should become something like:

Code: Select all

printf( "%d ", value )

Try again, please ...

Sven

That did the trick! Many thanks Sven.
I just needed to to format it a little to

Code: Select all

printf( "%9d ", value )

I think this problem shows Winboard is very fussy in what it accepts.
It will refuse to show any pv line at all if one element of the line is slightly incorrect or doesn't use an integer.
Maybe this could be improved.

New version of AliBaba > http://www.mediafire.com/?z4yzdz5mgcj

Jim.

[H.G.Muller]

I think this problem shows Winboard is very fussy in what it accepts.
It will refuse to show any pv line at all if one element of the line is slightly incorrect or doesn't use an integer.
Maybe this could be improved.

I doubt if this is desirable. The WB protocol specs are very explicit in how the thinking output should be sent (centi-seconds and centi-Pawns). It is important that engines respect that, as the output is not merely for display, but WinBoard should actually understand it. (For the purpose of adjudication, or decrementing the clock in NPS mode.) The fact that engines use a floating-point format here is likely to be more than a problem of using a wrong format: with centi-Pawns there hardly would be need for any decimal places. So they probably use some wrong kind of unit, but which one?

I think it is in general much better to keep a tight standard, than accepting as much non-compliant output as possible. The latter just invites chaos.

[Jim Ablett]

Sorry,

I just noticed I hadn't updated the modified src (AliBaba 1.4) to the latest version in
the distribution.

Please download again here or from my homepage >
http://www.mediafire.com/?5wnmoct3ymw

Jim.

[Sven Schüle]

I think this problem shows Winboard is very fussy in what it accepts.
It will refuse to show any pv line at all if one element of the line is slightly incorrect or doesn't use an integer.
Maybe this could be improved.

I doubt if this is desirable. The WB protocol specs are very explicit in how the thinking output should be sent (centi-seconds and centi-Pawns). It is important that engines respect that, as the output is not merely for display, but WinBoard should actually understand it. (For the purpose of adjudication, or decrementing the clock in NPS mode.) The fact that engines use a floating-point format here is likely to be more than a problem of using a wrong format: with centi-Pawns there hardly would be need for any decimal places. So they probably use some wrong kind of unit, but which one?

I think it is in general much better to keep a tight standard, than accepting as much non-compliant output as possible. The latter just invites chaos.

Actually, in the two cases of Alibaba and MsKcp it was only the wrong formatting of output that caused the problem, internally both programs are book-keeping correctly. So it was easy to fix once the offending lines of code were all detected.

I agree that the PV output requirements of the WB protocol should be kept strong. One could possibly think of a small change that would allow for getting the PV itself printed at least, even if some of the numbers are "unknown": the format of a PV output line could be compatibly changed into

Code: Select all

<plyString><spaces><scoreString><spaces><timeString><spaces><nodesString> <spaces><pvString>

with the constraint that each of the first four strings must be numeric in order to be accepted, but if one of them isn't, it is replaced by a zero value. "Division by zero" should be checked then (hopefully already done since an engine could send "0" already now, e.g. as "time").

The change could never break an existing engine since it would still accept output that is accepted now but would also "partially accept" more output. So this should be a good example of a compatible change; correct me if I'm wrong here.

It could be implemented with sscanf() using five times %s and then checking the first four strings with atoi() or similar functions. A few more (trivial) code lines, the price for slightly more flexibility.

Just as an idea. Not a very important one, but maybe also not unimportant for some people.

A disadvantage could be that PV output problems of some engines could be missed more likely than now.

A further problem could arise if one of the numbers were missing completely. In this case, possibly some of the other numbers inbetween would be shifted and get a different meaning, and the first token (move string) of the PV would be cut off and taken as "nodes", but immediately set to zero for not being numeric.

So I'm not sure what is better. Harm, what do you think? A "/strictPV" option with default=yes, really??

Sven

[H.G.Muller]

The main danger of relaxing standrads is that it encourages those subject to the standards to quickly occupy the new allowed region, with as much spill-over into the forbidden region as there was before. We must draw the line somewhere, and it is not obvious that drawing it in a different place from where it is now will cause less transgression, other than for the short period it takes to people to catch up with the new location of the line.

Before considering it, it would be better to take some inventory of how many engines actually have this problem. Just to make sure that we are not trying to solve a non-existing problem, thereby creating a much bigger one in the long run.