xmas79 wrote:IMHO it still won't. Sometimes I have multiple fail-lows in a row, so the interface will sort them in the bad order.
No, it won't. Any more recent line will pass the earlier fail low in (if it was explicitly indicated as one) in the upward direction during the sort. Even when it was not indicated as such, it will likely have the same PV move (strictly speaking, a fail low should have none), and should thus be considered an improved score of the previous fail low, and sorted above it.
Sometimes I have search instability which produces a fail-high with a score X, then the research will produce a score lower than X, failing again to sort PVs in the temporal order.
Yes, this is the case that Bob also showed. But if the lower bound is marked as a fail low, it will never prevent the later line from floating to the top. If the later line starts with the same move as the fail high, it will also always float past the latter, because XBoard now can conclude it must have been a fail low, or the same move could not repeat with a different score.
If you want the engine to give explicit output to recall the fail high, it should repeat the best line in this situation.
I think that asking for the engines to modify their output logic to satisfy a GUI that should "only" (really) print on the screen what the engines have to say seems a bit forced to me... [/quote]
Well, the Engine Output window is not intended to be a general log window for the engine-GUI communication. It is intended for presenting thinking output of well-defined format by the protocol, and there never was any guarantee given that output would be presented in temporal order. There could very well be a conflict of interest here between engine developer and the typical user. In general it is more convenient to have the engine's current favorite move at the top of the list. So even if it is not a protocol requirement that moves are sent with their scores in ascending order, I think it is quite justifiable that GUIs will correct engines that sin against this logic. WB Thinking Output is not intended, for instance, to keep the GUI informed on how the engine is progressing. (The stat01 commands are for this purpose.) So when an engine would start to send a line for every low-failing move it searched after the PV move, with an upper-bound score lower than the PV move, I would definitely consider it non-compliant. Sending exact scores that are lower than an earlier exact score in the same iteration is only justifiable as multi-PV output; in single-PV mode an engine should not do that. Reporting fail highs on individual late moves before you have resolved them does come close to abuse of Thinking Output, IMO. It clutters the output, and for a non-technical user that does not know in intimate detail how engines work (i.e. 99% of all users...), it does not convey any information.
Why it can't be made a simple checkbox on the options dialog? "Do you want to sort engine output by score? Yes/No". "Yes" will put on all this logic, "No" will disable all this stuff and will display exactly what the engines have to say (that it seems to me is the most obvious way to look at that window).
This could be done, but the problem is that in multi-PV mode you would really want score order rather than temporal order, because some multi-PV implementations print the lower scores later. And users might want to switch between single and multi-PV mode quite often. So it would be annoying if they were forced to toggle yet an extra option to do that. Plus that there is no guarantee engines won't frivolously print fall lows and highs in multi-PV mode.
So if there was to be a new option, I think a much more useful one would be a checkbox "discard fail highs and fail lows", default true. But as the ! and ? standard is not yet in common use, that would not help much in practice. (Although having Polyglot do it right would make all UCI engines compliant in one swoop.)
Maybe managing a failed move (high/low) as a "non sorting point" could be a solution. In this way, if an engine outputs ! or ? then the PVs below this point should never be sorted. This saves single-PV engines (which usually output ! and ? for FH-FL moves), and multi-PV engines (which put ! and ? for FH-FL moves, and put clean PV for the multiPV part). No?
The idea of always letting more recent lines rise above failed lines was sort of an attempt at that. But I think the real issue is: what is the most useful way to present engine output like
early
13 +0.12 1:10 d4 Nf6 ...
13 +0.20 1:15 e4!
13 +0.10 1:25 e4 e5 ...
late
The current algorithm would display it as
top
13 +0.20 1:15 e4!
13 +0.12 1:10 d4 Nf6 ...
13 +0.10 1:25 e4 e5 ...
bottom
because although the +0.10 line could pass the +0.20 line upward, because the latter is a fail low (or has the same move), it now is not allowed to pass the +0.12 line, as +0.10 < +0.12. But
top
13 +0.10 1:25 e4 e5 ...
13 +0.20 1:15 e4!
13 +0.12 1:10 d4 Nf6 ...
bottom
because the +0.20 reset the sorting bottom and forces everything that comes later to come above it (as a higher depth would) IMO is even more confusing. The e4-e5 line has no business being on top, as it is not the best move. And I really think the engine is the culprit for sending it, as strict temporal order would produce exactly the same display of the lines. Most GUIs do not sort, and sending lines for poor moves after good ones will just confuse the user.
