Xboard's engine output requests

[velocidrom]

Hi,
1)In order to keep up easily with the latest output of the engine, I think it would be nice if the latest output would be displayed on the top of the outputs.
Currently it isn't so, as you can see in the screenshot.
2)It would be nice if the Engine Output showed the table bases hits number. For example stockfish with the syzygy table bases, right now I have no idea how often SF looks into the TB's nor how much.

Thanks for any feedback.

[H.G.Muller]

1)In order to keep up easily with the latest output of the engine, I think it would be nice if the latest output would be displayed on the top of the outputs.
Currently it isn't so, as you can see in the screenshot.

Well, in multi-PV you would typically want them sorted by score, best on top. The problem is caused by some engines hiding the fact that the scores are not real scores, but fail lows. I will check what can be done about this.

2)It would be nice if the Engine Output showed the table bases hits number. For example stockfish with the syzygy table bases, right now I have no idea how often SF looks into the TB's nor how much.
[/quote]
This is mostly a Polyglot matter. I will also check what can be done there.

[velocidrom]

Well, in multi-PV you would typically want them sorted by score, best on top. The problem is caused by some engines hiding the fact that the scores are not real scores, but fail lows. I will check what can be done about this.

I didn't really understand the part of not real score but fail lows.
Anyway thank you for investigating what can be done. I would like to point out that I was not using multi PV and that the scores are NOT sorted by score with best on top which seems to be what you said.

This is mostly a Polyglot matter. I will also check what can be done there.

Well thank you very much. That would be extremely nice!

[H.G.Muller]

... and that the scores are NOT sorted by score with best on top which seems to be what you said.

Indeed, and this is a bit puzzling. Which version of XBoard exactly were you using here? Normally an engine would not search the same move a second time at the same depth, unless the previous search was somehow wrong (fail low or fail high). So if the same PV with a different score is printed by the engine, it should be assumed to overrule all previous scores for that move at the same depth, and be sorted on top. I already made a patch to make that exception to sorting by score some time ago, but I don't know if that already is in the version you are using here. But with that patch, the +0.64 line should not have been left below the +0.72 line, as it came later. Without the patch, however, the +0.56 line should not have been able to get above the +0.64 line, however. So something seem to be not working as intended.

The existing patch is not satisfactory anyway; even if it would work as intended, it would have sorted the 18-ply lines {+0.56 (top), +0.64, +0.72}, i.e. most recent on top, as they all start with the same move. But then if later in the same (18-ply) iteration a different move would be discovered with score +0.60, it would deserve to be sorted above all of them. And the current patch would not allow it to rise above the +0.72 line for Bd2, despite the fact that this has already been corrected to +0.56. So in comparing the scores I really should correct the scores of 'overruled' lines to their most recent (presumably correct) value (internally; not in the display, of course).

One difficulty is that WinBoard cannot always see if the engine is in multi-PV mode; multi-PV is an engine-defined option. So the same system must work both in multi-PV and single-PV mode.

[velocidrom]

I see...
I was using xboard 4.7.2.

Edit: What about sorting the moves according to the total number of nodes searched? I am not sure it would be ideal in multi pv mode though but you know better that I do

Edit 2: In case this may help, I post a screenshot where there are 5 different scores for 2 different depths.

[H.G.Muller]

Well, sorting by nodes would be just displaying them in the order the engine prints them. So no need to sort then. (And not all engines print nodes; some just always print 0 there.)

I thought that 4.7.2 would strictly sort by score. (But I will check to make sure.)

The output of Stockfish is a bit confusing; for d=26 it reports scores -1.05, -1.13, -0.88, -1.25 and finally -1.13, the latter for another move. Apparently the first four are just bogus scores (upper limits).

I guess the new algorithm I had in mind should solve this correctly: the first four scores should (internally) all be corrected to -1.25 (because that is the last score received for that move), and then be displayed in order of arrival (because they are for the same move). After that, the higher score for Bc7 should be displayed above that.

It would be bad if the engine had been switching between moves that both had a bogus score. That might be impossible to detect: in a normal search it often happens that the best move, after printing the PV for it, is supercede by a better score on another move. So in such a case both scores could be real, and both could be bogus. And when you receive lower scores than you got before at the same depth, you can't even say for sure the earlier scores were bogus; they could just be multi-PV. Only when you receive different scores for the same depth and the same move, you can conclude for sure the earlier score for that move must have been bogus.

I guess it is essential that this should be fixed in the protocol: the engine must tell the GUI if the score is real or bogus, and only real scores should be sorted below higher real scores. I thought UCI does provide this information with the PV info. So then it would have to be solved in Polyglot, with the aid of a WB protocol extension.

And it is still a mistery to me why in the first screenshot XBoard 4.7.2 would not have strictly sorted by score. This seems a bug in itself.