Evert wrote: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
WB protocol specs wrote: 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:
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.