Some more WB protocol extensions

[hgm]

I know a lot has been discussed about this in the past, but I want to re-open the discussion, as I might actually implement some new stuff. This applies to the following isues:

1. Multi-PV

This seems the least controversial one: simply allow an engine to send feature multipv=1 at startup. If the GUI has received this, it can then send multipv N to the engine, to request it to calculate and send (as Thinking Output) the best N lines. The engine can decide how many lines it will actually send; the command is a request only. (After all, there might be only one legal move...)

2. Hash clearing

The specs on the memory command will be beefed up a bit, to imply clearing the hash table (and other tables) even if the requested size is equal to the current size. Currently WinBoard sends the memory command after new on every game, but future interfaces could refrain from that, if the hash size can stay the same and they don't really want to reset the engine to a known state. To the specs of the new command the recommendation will be added that it should leave the hash table alone.

3. Thinking Output

Currently there is a hideous feature in WB protocol called 'periodic updates', whereby the engine is polled by the GUI for information it might or might not have. I want to deprecate that, as it is a clear case of totally wrong design. Polling is awful; the engine should volunteer this information, as it is the engine that knows when it has new information to present. And logically, the information belongs with the Thinking Output. In fact it even duplicates part of it (depth, time, nodes).

So I plan to make an extension to the specs for Thinking-Output lines, which can include this information. The engine can then send this info not only during analysis, but also during pondering and regular search. And as the PV in the olds protocol specs is a free-format field, there is automatic backward compatibility. Old interfaces that do not know about the new standard, would simply display the info as part of the PV. In fact, I already know some engines that use this technique (e.g. NanoSzachy), and it looks quite nice.

In particular, I want the new format to look as

depth score time nodes tbhits {move movenr/totalmoves} PV +-

In front of the PV, between braces, the engine can display the move it is currently considering in the root, the sequence number of that move, and the total number of root moves. (I.e., the info that formerly was in the stat01 lines.) In front of it, there can be an optional number to indicate the number of tablebase hits. Perhaps some more optional fields could be squeezed in here in the future; I would like to keep their number low, though, in order not to push the PV out of view on old interfaces. Prepending 0 {f3e5 3/20} (14-15 characters) seems still acceptable.

The 'time' parameter should specify CPU-time used (sum of all threads for SMP engines), so that the GUI can calculate CPU load. Sending wall-clock time here is kind of redundant, as the GUI can measure this itself.

Mate scores should be standardized, and preferably encoded in a way that does not break old interfaces. In Joker I use the system of encoding a mate in N (moves!) in the Thinking Output as 100000+N, and mated in N as -(100000+N). This keeps it purely numeric, and in a way that makes you immediately read the DTM on old interfaces, rather than having to do a mental subtraction from an obscure number such as 32,768. GUIs aware of the standard would of course convert it to a text like MATE6 in the score field.

At the end of the PV there can be an optional + or - to indicate fail high or fail low. If I understand correctly, the PV will never be longer than 1 move in that case, so it will always be in view.

4. Multi-Session Time Control

When an engine sends feature xlevel=1 at startup, the GUI will send it a multi-session level command at the beginning of every session.
This is just like the old-style level command, except that it has an arbitrary number of MPS, TC, INC triplets on the same line. The first of these triplets will contain the parameters for the upcoming session. The following parameters will offer the engine a preview of what to expect in subsequent sessions.

Trustful engines could look only at the first three parameters, to know what to expect for the next MPS moves. (The TC will actually be a bit redundant, as it will immediately be superseeded by the following time command.) They will naively fall, however, for "treacherous" time controls like 40/60+100/0:01 (specified by level 40 60 0 100 0:01 0 before move 1 and level 100 0:01 0 before move 41). If the engine wants to be more clever, it can always look ahead, as far into the future as it deems necessary. (I can imagine that after seeing 40/60+20/15+..., it is not terribly interesting to know what will happen in the third session before the second session starts.)

There will be no guarantee that what the engine is told by the GUI is true; the engine should always obey the last level command that is received, even if that contradicts to what was said before. It would be perfectly valid for GUIs to implement a sort of handicap TC mode where the engine suddenly and unexpectedly has to speed up after a certain move, even before the end of he current session. So after receiving level 40 10 0 at the start of the game, promising classical 40/10 repeating TC, the GUI could surprise the engine by a level 0 5 0 command at move 30, forcing the engine to finish the game in 5 min under sudden-death rules. Conducting such games could by useful for certain types of testing, so the protocol should support this possibility.

FEEDBACK WELCOME!

[Michel]

Currently there is a hideous feature in WB protocol called 'periodic updates', whereby the engine is polled by the GUI for information it might or might not hav

Why "hideous"? It is just a command the GUI sends and the engine answers....

I don't like the use of such charged words when discussing a communication protocol.

[michiguel]

2. Hash clearing

The specs on the memory command will be beefed up a bit, to imply clearing the hash table (and other tables) even if the requested size is equal to the current size. Currently WinBoard sends the memory command after new on every game, but future interfaces could refrain from that, if the hash size can stay the same and they don't really want to reset the engine to a known state. To the specs of the new command the recommendation will be added that it should leave the hash table alone.

Would it not be better to have another command "clearbrain" or "clear" (or whatever name) to separate those tasks rather than interfering with previous commands? In fact, "clearing" is a different conceptual task that may be useful even if the engine is not using hashtables (for instance, clearing killers, or any variable inherited from the previous search).

Miguel

[hgm]

Why "hideous"? It is just a command the GUI sends and the engine answers....

It is polling: an unnecessary flow of information in the wrong direction. We don't poll the engine for asking if it already has a move, do we? That would also be just a command to which the engine answers. But it woud be very poor design to require a GUI to send such queries, and have the engine reply with "nomoveyet", "nomoveyet", ...., "move e2e4".

The engine knows when this information is going to change, so the initiative to transfer the information should ly with the engine.

[hgm]

Would it not be better to have another command "clearbrain" or "clear" (or whatever name) to separate those tasks rather than interfering with previous commands? In fact, "clearing" is a different conceptual task that may be useful even if the engine is not using hashtables (for instance, clearing killers, or any variable inherited from the previous search).

The command reset has also been proposed for this, but that was before the memory command existed. When memory forces you to re-size the hash table, I guess there is no practical way to do it without clearing it. We might as well make it a recommendation to always do that.

I have considered adding a new command for this, but it seems a waste to add a new command for one that does already do nearly the same. The fewer commands the better. Especially when at the moment there is no practical use for this command. In theory it could be used for epd-suite testing, but that is not something that WinBoard supports.

The more different commands you make, the less likely engines will be to implement any of them. On the other hand, if a command can be usful in many situations, it enhances the chances that people wil want to implment it. Of course we could put it in the specs as merely a recommendation: bring the engine in as well-defined a state as you ever care it to be in. People wil implement what they want anyway, and if they do not care about epd suites, why shoud they bother with clearing killer tables etc. That 'new' should not clear the hash is also only a recommendation. Some engne authors prefer clearing the hash before every move (for reproducibility of errors), and it would be logical for them to aso clear on 'new'. They should have that freedom. Some engines might not even have a hash table...

[Michel]

I was simply objecting to the use of the word "hideous" for a command that allows the GUI to ask information from the engine.

There is no need to use such charged words when discussing a communication protocol.

[hgm]

Well, for one, it indicates that it is high on the priority list to deprecate it. That is useful information...

[Michel]

Well, for one, it indicates that it is high on the priority list to deprecate it. That is useful information...

You could simply say that the next version of WB will stop sending "." to the engine....
After all nothing in the WB protocol forces the GUI to send this command to the engine....

EDIT: Of course it is still useful for engine authors to implement it since for example Arena will keep sending it, at least for a while.

[hgm]

Of course WB will keep sending it as well, to provide backward compatibility with existing engines. (The default setting of priodic updates might be changed, but in WinBoard this is quite meaningless, as the setting in the winboard.ini deermines what happens in practice.)

But the information contained in the stat01 lines is unsatisfactory for modern engines. So new protocol is needed to allow engines to send what they would like to send. And that new protocol will be based on through Thinking Output, not through stat01 extensions.

So IMO modern engines would be better off when they ignore "." commands, and send the info they like the user to see as part of the thinking output. Other GUIs should display that too (if they properly implemented WB protocol). And the engine can then do that whenever it wants, even during normal search or pondering.

[plattyaj]

3. Thinking Output

Currently there is a hideous feature in WB protocol called 'periodic updates', whereby the engine is polled by the GUI for information it might or might not have.

There are really two pieces of information - one of which, yes, the engine knows when it changes but one of which is useful to poll for. To get the current number of nodes, I think the GUI should continue to poll - even if the protocol allows the engine to send when the current move it's thinking about changes.

Andy.