WB protocol extension: thinking output

[Harald]

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

But as you can see in the picture the user has to deal with two different pv display styles.
As an engine writer I would prefer to send only the e8c8 bic3 style
and as a Winboard user I would like to see only the c4 Qd6 SAN style for both engines.
The translation shoud be done by Winboard.
(And I don't care much about exotic chess variants that would not allow this.)

Harald

[hgm]

For this we already have the options -fSAN and -sSAN. Just wasn't using them here. For UCI engines Polyglot already does the job, of course.

In my philosophy display matters should remain a GUI job. I don't want to burden every engine with conversion to SAN.

For exotic variants I think the solution should be that the engine at startup sends how the pieces move, in case it wants to use pieces in other ways then they were intended.

[Greg Strong]

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.

Why not only print the extra information if the GUI explictly accepts the feature?

[hgm]

Because then the information would not be displayed if the GUI rejects it.

The existing format is 4 integers plus the PV. The only 'formatting' WinBoard does on this is separate the integers by tabs, so they are displayed in their own column. The obvious extension would be to have more such columns for the new infos. This would be exactly what you get if the engine would take care of printing the extra info at the start of the PV field in columnar format. So choosing for this format would cause a sort of auto-upgrade of all existing interfaces. Which I think is a very strong point in its favor.

Of course it is a good question whether such columnar formatting is possible, in the face of the fact that GUIs could use proportionally-spaced fonts. But I think the prospects for that are not too bad. With seldepth, knps and tbhits as the next three quantities, seldepth will almost always be 2 digits, knps will be pretty constant at 3-4 digits, and only tbhits has the potential to vary wildly. So with a "%2d %4d %d\t" format the alignment should be pretty good, even when a space would be only half as wide as a digit, as padding with spaces should hardly occur, and where it does occur, it occurs consitently through the column. The tab would take care of the variability in length of the tbhits number, and the amount of space it eats from the PV is not unnecessarily large, as columns that contain data of nearly constant width don't need large margins. If an engine does not want to supply a certain info, it can omit it if the info is last (e.g. if it does not support EGTs), or just replace it by a single zero if it still needs to print an info behind it (e.g. "0 0 %d\t" for tbhits only).

So perhaps I should forget about using {} and commas, to stay as closely as possible to the old format, and cause as little noise as possible in the display of 'auto-upgraded' GUIs. The main concern is that some GUIs might want to use the PV for some other purpose than displaying, (e.g. variation board), and that we cannot be sure the leading numbers would not interfere with that. My expectation was that printing something that is PGN compatible in the PV would have a good chance not to upset parsing attempts of the PV. Hence the enclosing {}, which would disguise it as a comment. But I am not sure that this would work on any other GUI than WinBoard. Perhaps unprotected numbers would be better, as many engines do print move numbers in their PVs, so PV parsers should be somewhat resistent to encountering numbers.

I want to point out that for authors who would prefer such auto-upgrading would not work, that it is always possible to use the feature handshaking to agree on an engine (check) option "ShowTbHits" that would allow users that don't want the extra infos to turn them off. This seems a more flexible method than reacting on the 'accepted'/'rejected' response to a feature, where the user would not have any say in it.

[Evert]

Because then the information would not be displayed if the GUI rejects it.

The question is if this is a bad thing.

Personally, I would rather not send stuff to the GUI that isn't going to be displayed properly than mess up the display with junk I need to interpret myself - especially if it's not formatted.

If the feature is popular enough, it will be added to other GUIs. Not older versions, of course, but then, new features are a good incentive to upgrade. As long as what used to work continues to work (ie, we respect the "rejected" message), there is no issue.

Perhaps unprotected numbers would be better, as many engines do print move numbers in their PVs, so PV parsers should be somewhat resistent to encountering numbers.

Of course, there is the danger that they would interpret them as move numbers in the game and get confused.
Either way, it would still pre preferable I think if the engine and the GUI would let each other know what data they are going to send to and expect from each other. Implicit assumptions and attempts to be clever about detecting what the engine is sending in addition to what had been defined earlier will probably make things (much) more complicated in the future (in say, 10 years).

Again, the feature command makes it possible to communicate about what is and is not supported and act accordingly. It seems like a mistake to not use it.

[hgm]

Implicit assumptions and attempts to be clever about detecting what the engine is sending in addition to what had been defined earlier will probably make things (much) more complicated in the future (in say, 10 years).

But the point is that nothing has been defined earlier: the protocol specs state that the PV field is free-format text. In fact it says

You can use the PV to show other things; for instance, while in book, Crafty shows the observed frequency of different reply moves in its book. In situations like this where your engine is not really searching, start the PV with a '(' character:

0 0 0 0 (e4 64%, d4 24%)

If the specs required something specific for this field, it would of course break backward compatibility to insert extra numbers, and I would never consider it. But as it is, it seems ideally suited for expansion, and continued future expansion. The specs don't guarantee anything for the PV format, so basically GUIs that want to use it do so at their own risk, and should better have a robust parser for it. Some engines even start their PV with a smiley...

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. 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 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.

[Michel]

proposed specs extension wrote:
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.

Perhaps this is also a good opportunity to hammer down how a fail high/fail low should be communicated?

[hgm]

Indeed, that would be very simple:

A question mark as the last character in the PV field should be used to indicate the reported score is from a fail low, and thus represents an upper bound only. Similarly, an exclamation point should be used to indicate a fal high / lower bound.

Normally this would mean a fail low just prints "?" as PV, and a fail high just a single move followed by "!". But engines like Stockfish seem to print phantom PVs in this situation. I was testing this on the Stockfish I obtained from the Ubuntu repository, and it doesn't even do a re-search on a fail low or high. It just continues with the next iteration! First I though I must have implemented the feature wrong, or that Polyglot would delete duplicates. But when I made it relay the raw engine output, it turned out there really was no further output at that depth after a PV containung the upprbound or lowerbound keyword.

[Michel]

Normally this would mean a fail low just prints "?" as PV, and a fail high just a single move followed by "!". But engines like Stockfish seem to print phantom PVs in this situation. I was testing this on the Stockfish I obtained from the Ubuntu repository, and it doesn't even do a re-search on a fail low or high. It just continues with the next iteration! First I though I must have implemented the feature wrong, or that Polyglot would delete duplicates. But when I made it relay the raw engine output, it turned out there really was no further output at that depth after a PV containung the upprbound or lowerbound keyword.

GNU Chess 5.50 prints the best move from the last iteration followed by a ? The logic is that if the search times out it will play that move. It is likely a bad move (hence the question mark) but what else can it do?

[hgm]

Well, that still sounds reasonable. There seems little reason to make a very long PV out of it, though. Especially if that would just repeat a PV that was already printed on the previous iteration.

In any case, what GNU Chess 5.50 does seems is compliant with the proposed specs.