You are still missing the crux on the mate scores. Of course the engine should not alter anything in the mate scoring it uses internally in its search. In all cases he "just adds something in the proposed PV line". E.g. your proposal:
Code: Select all
if(score > MATESCORE-100) printf("mate +%d", (MATESCORE-score+1)/2); else
while in my proposal
Code: Select all
if(score > MATESCORE-100) printf("%d", 100000 + (MATESCORE-score+1)/2); else
Mentioning the EPDs is also a non-argument. EPDs do not use #2 or "mate +2", so you your proposal differs just as much from the EPD standard as mine.
So the only difference remaining is that your proposal would totally break backward compatibility. So that additional mechanisms would have to be programmed to negociate with the GUI if it could be used. And the engine would have to be able to fall back on the old method if it the GUI did not support the new one, in which case the user would also not have the benefit of more easilaby interpretable mate scores.
As for the thinking output, your arguments also seem very shaky:
1) There is no need for an engine to count nodes, and many engines indeed print 0 in the time and node field (e.g. Pulsar). So this is an already accepted method in the existing protocol.
2) If we accept the idea that engines must calculate quantities like 'nodes' just because the protocol requires them to print those, keeping track of seldep is not intrinsically more complicated than counting nodes. Any engine could do it. Printing nodes/sec should never be a problem; engines that do not keep track of it separately can always divide nodes by time, both of which they already printed in the standard output.
3) The proposed system is not as rigid as you imagine, because it is not mandatory to print all extra infos, but you can clip off those at the end of the priority list if you don't want them. If you only want to print tbhits, you would print
(Note that I have already abandoned the idea of using enclosing {}.) If you want to print only seldepth:
If you want to print only knps:
Code: Select all
0 1528 0 (compare "knps=1528")
So the 'overhead' is typically quite small, even when you only want to print a single item. Even in the last case above it was only 4 extra characters, while the "knps=" prefix is already 5. And there is actually little excuse for not printing seldepth: any engine could calculate that, if it wanted. Printing 0 for seldepth or nodes is just laziness. Only the required extra 0 for tbhits in engines that do not use EGT should really be counted as overhead.
But I defined tbhits as highest priority, because IMO it is the only important number amongst the stuff UCI engines send. If I did not want to print tbhits in my engine, I would not bother printing any "extended infos" at all, and just stick to the old standard. Who cares about seldepth or knps?
I think compactness carries a lot of weight here. About 99% of all engine->GUI traffic is Thinking Output in WB protocol. I don't want it to become excessively verbose. It would IMO be extremely annoying to see tbhits=, seldepth=, knps=, cpuload= repeated at nauseum in every line of Thinking Output for the entire game.
It would be even more annoying if people using interfaces that do not implement the extended standard see that info push the entire PV out of view. They would have no choice but to switch that info off (hoping the engine at least supports an option for that). While a prefix to the PV like "27 1528 0 " to the PV to see seldep and and knps would be quite bearable, definitely much less intrusive than "seldepth=27, knps=1528 ". Compactness also matters there.
On a single line, printing "name=" keys might seem a good idea, but in a table, seeing it repeated in every line is actually quite annoying. Columnar output is much more readable.