WB protocol extension: thinking output

[Evert]

As for the situation in 10 years, I think it would be exactly the reverse from what you worry about. The (optional) extension from 4 to 7 leading numbers would find its way in the specs, of course, and in 10 years no one would remember that it ever had been any different. By specifying that it could only be done after a feature, we would be stuck with another 'must have' feature forever.

Well, backward compatibility comes at a price. If there would be some other way to do this that could also work (protover 3? Older engines that don't know about version 3 will just continue to send stuff in the version 2 format, which the GUI should be able to deal with, engines that do can send the new stuff if they're running on a protocol 3 GUI and refrain from doing it if they're running on a version 2 GUI).

It also seems kludgy use of the feature mechanism: features are intended to tell the GUI what it can send to the engine, not so much to control what an engine can send to a GUI. To control engine behavior there are engine-defined options.

I see them more as the engine telling the GUI "I support these options", or "I can tell you these things." If it's just about telling the GUI what it can send back, why are there "accept" and "reject" messages?
As it is at the moment I always ignore those: I tell the GUI that I support setboard. If it accepts that, fine (but what do I care if it tells me so?), if it doesn't… well, I don't have "edit" so there isn't much I can do about it either way. So what's the point?

I would be inclined to extend the specs for Thinking Output as follows:

An arbitrary number of space-separated integers can be inserted behind the 4 obligatory integers and the PV, in which case the PV field is assumed to start behind the last tab character before any non-numeric token. The last number before the PV will indicate EGT hits in this case. When there are distinct numbers in positions 5 and later, they will represent selective depth, engine speed (in knps), hash-usage (0-99, in percent), CPU load (0-99, in percent), respectively. This list can be expanded in the future.

With that specification, all my engines will report table base hits, starting with 1 hit at the first move, 2 hits at the second move, 40 hits at move 40 and so on.
So that will still break backward compatibility. Of course, I write the numbers as "1. e4 e5", "1. … e5 2. Nf3" and presumably I would write TB hits as " 1 ", but I don't think this is a safe assumption in general.

[hgm]

Well, backward compatibility comes at a price. If there would be some other way to do this that could also work (protover 3? Older engines that don't know about version 3 will just continue to send stuff in the version 2 format, which the GUI should be able to deal with, engines that do can send the new stuff if they're running on a protocol 3 GUI and refrain from doing it if they're running on a version 2 GUI).

Indeed. This is why I am very conservative with protocol, and have no plans whatsoever to upgrade to any 'version 3'. I strongly dislike doing the same thing in multiple ways. I think it was a mistake to add 'setboard' once 'edit' existed. If 'edit' had some defects, it could have been extended in a backward-compatible way with commands to specify castling and e.p. rights. There really was no need for anything like 'setboard', especially since when it was introduced XBoard would send dummy castling rights anyway. Features like san=1 are also madness, IMO.

Of course adding new commands for things that could not be done before is unavoidable. Ping is extremely useful. There backward-compatibility is only a matter of how to get by without them, not of supporting dual standards.

So what's the point?

I would be surprised if there were any engines that reacted to 'rejected'. Which shows that in practice this kind of backward compatibility just doesn't work. But engine-defined options are features just like the standard features. And they allow more user control than the latter, so I prefer their use. Sending unsollicited tbhits info to an older interface is still fully compliant with the specs, so anyone that wants to do it can do so anyway, feature or no feature. If you feel strongly it should not be sent to GUIs that do not treat it special, you can make it subject to an engine option that by default switche it off. (IMO this would be a mistake, though.) Then a user that doesn't share your preference can switch it on anyway. His "option ShowTbHits=1" would simply atake over the function of "accepted tbhits".

With that specification, all my engines will report table base hits, starting with 1 hit at the first move, 2 hits at the second move, 40 hits at move 40 and so on.
So that will still break backward compatibility. Of course, I write the numbers as "1. e4 e5", "1. … e5 2. Nf3" and presumably I would write TB hits as " 1 ", but I don't think this is a safe assumption in general.

No, that will not be the case. You missed the point (no pun intended) about the tab. You have no tab between the 1 and the . , and the latter is the first non-numeric (at least non-integer) token. So it would never consider the 1 as tbhits or anything else. It remains part of the PV field.

If you would have no period behind the 1, the 'e4' would be the first non-numeric token, and the 1 would only be taken as tbhits when there was a tab between the '1' and the 'e4'. Which I consider unlikely enough that I am willing to take that risk

[Evert]

EDIT: OH GREAT!

I just wrote a lengthy detailed reply, and it gets eaten by the forum software >:-|

I'll try to reconstruct what I wanted to say later.

[Greg Strong]

[quote="hgm]

An arbitrary number of space-separated integers can be inserted behind the 4 obligatory integers and the PV, in which case the PV field is assumed to start behind the last tab character before any non-numeric token. The last number before the PV will indicate EGT hits in this case. When there are distinct numbers in positions 5 and later, they will represent selective depth, engine speed (in knps), hash-usage (0-99, in percent), CPU load (0-99, in percent), respectively. This list can be expanded in the future.

[/quote]

I'm not sure I understand CPU load. Engines use all the CPU available don't they?

[bob]

I had thought about this issue a while back. One idea was, what about letting the program prepend "line 1" or "line 2" or something similar which would let it format the output window as it chooses? Might be a non-standard standard of course, where everybody would then format the output differently.

But a thought, anyway.

I suppose you could get REALLY fancy and support "line x column y" to just change a part of the window.

[hgm]

I'm not sure I understand CPU load. Engines use all the CPU available don't they?

I must admit I don't really understand that either. Even more so 'hashfull'; IMO the hash should always quickly fill up to 100%.

But these are things UCI engines print, and which other UCI supporting GUIs thus show, so that people expect XBoard to show them too. Which is only possible if the Polyglot adapter has a way to transmit them to XBoard in XBoard protocol.

[michiguel]

My proposal for this has always been to send 100000+N for mate in N, and -100000-N for mated in N. The GUI could display them as #N or MN, and even if it did not know that convention, it would display recognizable matescore, with the peculiarity it would have spelled 'M' as '1000.'.

But people don't seem to like it much.

Actually this is even simpler as it won't require any extra logic.
Maybe I'm an exception but I like your idea a lot
and I think there is no engine that sends scores > 1m or <-1m (I may be wrong).
It would be nice though if the GUI would translate it to M or # (could be an option),
even though I agree that 100000+N or -100000-N
should be easily readable by humans as well.
If you plan to add new stuff to the protocol, I vote for this standardization

I do not like that. First, if a score should be interpreted as "mate in", I think it should be better to use the EPD standard. Why use a different one?

Still, since most engines do not use that standard, using any kind of number may produce weird results. Some engines may use a "close" number for mate, which will result in a wrong interpretation. For that reason, and to guarantee that that "mate in __" will have the proper interpretation, a separate "mate in X" should be sent by the engine. In this respect, what UCI is doing is a good idea IMHO.

Miguel

[michiguel]

I would like to extend the amount of information that engines can send to the GUI together with their PV. The current protocol specs account for only 4 quantities next to the: depth, score, nodes and time. Possible extensions could be seldepth, knps, tbhits.

The obvious way to do this would be to exploit the fact that the PV field is just a free-format text field in WB protocol. So it is possible to prefix the PV with other data, without breaking backward compatibility. For easy recognition it seems best to not just start with a set of unprotected numbers, however, but to wrap the extended info in {braces}. As older interfaces that do not know about the extension would display the info in the PV field, readability of the raw format is a concern, and it is probably better to use comma separators than just spaces. It also seems better to keep it compact, so that it doesn't eat too much space from the PV. So formats like {tbhits=97080, seldepth=27} are probably not a good idea, and the meaning of the numbers can be implied by their position.

The question then is what order to define. Info that every engine can supply should preferably lead, so that engines for which some info does not apply (like tbhits when it doesn't use tablebases) needs not be sent at all. So I was thinking something like

{seldepth, knps, tbhits}

Are there any other engine parameters that could be useful? I am not even sure about the knps, as it seems this should be derivable by the GUI itself from time and nodes. UCI also has infos cpuload and hashful. Are these useful at all?

Actually, I like {tbhits=97080, seldepth=27} much better because it is less rigid and it is readable for a human in debug outputs, logs, etc. Readable communication, within limits, has been a hallmark of the wb protocol.

Miguel

[hgm]

Well, I don't know. What is readable about this:

Code: Select all

 6    -11       38      42940 g1h3 d7d5 d2d4 c8f5 b1c3 b8c6
 6     -9       54      63384 g1f3 d7d5 d2d4 b8c6 b1c3 c8f5
 6     -1       67      81000 a2a4 d7d5 d2d4 b8c6 b1c3 c8f5
 6      0       84     106629 c2c3 d7d5 d2d4 b8c6 c1f4 c8f5
 6      3      105     141781 f2f4 c7c5 b1c3 b8c6 g1f3 d7d5
 6      7      130     186968 b1c3 d7d5 f2f4 b8c6 g1f3 c8f5
 7      8      203     336052 b1c3 d7d5 g1f3 b8c6 d2d4 c8f5 c1f4
 7     11      317     580601 g1h3 c7c5 d2d3 d7d5 c1e3 d8a5 b1c3 c8f5
 7     17      400     752332 a2a4 c7c5 f2f4 d7d5 b1c3 b8c6 g1f3
 7     24      554    1083815 d2d3 c7c5 c1e3 b8c6 c2c3 d8b6 d1c1

it doesn't say

depth=7, score=24, time=554, nodes=1083812, pv=d2d3 ...

The latest proposal would just be more of the same, and definitely be the closest possible to the existing protocol. Only the requirement about the tab character is new, and I think it would be an almost fail-proof way to recognize one is dealing with the new format, and not accidentally interpreting some line number. It doesn't affect readability in any way, as the tab just shows up as whitespace.

[hgm]

I do not like that. First, if a score should be interpreted as "mate in", I think it should be better to use the EPD standard. Why use a different one?

1) Better readability. Both in the protocol and in interfaces that do not support the standard.

How long would it take you to understand 327.41 or 32741 means 'mate in 14'? Now compare that to 1000.14 or 100014. Not only did you have to subtract in the former case, but most people would not even know eher to subtract from...

2) The EPD standard is for EPDs, and WB Thinking Output is not an EPD.

3) Larger range. The EPD standard would get into trouble if DTM > 32768.

Still, since most engines do not use that standard, using any kind of number may produce weird results. Some engines may use a "close" number for mate, which will result in a wrong interpretation. For that reason, and to guarantee that that "mate in __" will have the proper interpretation, a separate "mate in X" should be sent by the engine. In this respect, what UCI is doing is a good idea IMHO.

Although this seems correct in principle, it also seems completely hypothetical. Is here an actual example known of any engine that uses mate scores above 1,000,000 cP? Or even above 100,000 cP? (Yes: Joker. But that already uses this method! ) Writing a sufficiently large number in practice is as good for recognizability as using a non-numeric keyword, and has the advantage that it is compatible with the existing standard for scores.