WB protocol extension: thinking output

[hgm]

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?

[Michel]

Probably the most important thing would be a standard way to indicate a fail high/fail low (UCI: upperbound, lowerbound).

[hgm]

Ah yes. Perhaps this could simply be done by writing ? or ! behind the PV.

[Michel]

This is what many engines do, but it is not formally specified.

[Harald]

Hi

You should try to separate the Engine - Winboard communication from
the visible output in a window or even in a log file.

Engine - Winboard:
There could be well defined and elaborate keywords for a lot of values.
Even different PV variables could be used pv_simple=e2e4 or pv_san=Nxg6.
Allow comments.
You could invent a complex syntax here. The engines have to agree to it
or modify it with the typical startup handshake. There could be a basic or
mandatory or default set that should be supported.

Log file:
The raw communication or the one from the display window.
Let the user (or the engine) chose it.

In the window:
Do it as nicely formatted as you can, or make it configurable by the user.
Think of a text that appears when the mouse hovers over the basic output.

Sorry if this is not what you had in mind. Just do not spoil the chance of
a real improvement.

Harald

[Evert]

The protocol has the very nice and versatile feature command, and I think this would be a wasted opportunity to not use it. Basically I would tell the GUI at startup that I want to send it random junk, and it can tell me "accept" or "decline". I will only print stuff if I get an "accept" from the GUI. This way, nothing breaks with older versions.

If going that route, I'd probably prefer to send a new command after the thinking output rather than abuse the "free form" text field at the end of the output (the "PV"). Just my opinion of course, but it seems cleaner.

As for what would be useful to send, I can think of a number of statistics that I've ever looked at: effective branching ratio (can be computed by the GUI, of course), first-move fail-high percentage, worst case move ordering for a move that improved alpha, etc.

Clearly adding all of these is not a good idea, but it may be doable to allow a generic "name=value" format. I can then send it whatever I like and the values get listed (and labelled) in the appropriate window. You can still predefine some names and display them in a special way if you want.

[hgm]

Well, this is how it currently looks in the display:

The user can hide or show all columns except depth and PV, by right-clicking the corresponding column title in the header line.

As for separation of the engine-GUI communication and the display: the problem is that interfaces that do not support the standard would not have such separation, but would print the extra information in the PV field. So it must not be too annoying there. In particular, it would not be a good thing if they would push the PV out of view.

[mar]

What I would like would be the possibility to send mate scores to GUI in a standard way.
The engine could send feature matescore=1 and if (and only if) GUI would accept it (send accepted),
the engine would then use (for example) #+n or #-n in score column (to make parsing simple - or maybe just #n or #-n).
n could be number of moves (because existing UCI engines already do that) or maybe plies to mate, that's just a detail.
Some may argue that it's useless but I prefer to see #11 instead of +99.xx or +9999xx or whatever.

[hgm]

Well, what you see is not necessarily the same as what the engine sends. So I don't think that should be much of a concern.

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.

[mar]

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