Thinking output ordering and failing low.

[Michel]

xboard currently orders its thinking output within a given depth according to score. However in case of an aspiration search repeatedly failing low this has the effect that the most recent (and most relevant score) is not on the topmost line of the thinking output window which is very confusing, especially when watching blitz games.

At least this is what I am observing. Is this correct?

I guess the workaround is to not send thinking output for fail lows...

[hgm]

Good point. Normally root moves that fail low (because there already is a better move in that iteration) would not be printed. How is that different here? As long as there is no move, would you print a PV for every move that fails low? Or just the first? I suppose the whole idea of having an aspiration window is that when the PV move fails low, you will try all other moves first before enlarging the window and redoing the iteration?

I could alter the sorting algorithm such that a new PV could never pass a PV of the same iteration that starts with the same move. Would that solve it?

[Michel]

I could alter the sorting algorithm such that a new PV could never pass a PV of the same iteration that starts with the same move. Would that solve it?

I am not sure.

I thought that when encountering a fail low at root one would output a score (an upperbound) before researching with a widened window. I currently don't even output a pv since it would likely be nonsense anyway.

After a few fail lows one will (hopefully) obtain a new pv. This pv should be on top of the thinking output window but currently it isn't.

The issue seems to be that there is no standard way for the engine to communicate a fail low to xboard (in UCI there would be an "upperbound" tag in the corresponding info line).

[ZirconiumX]

I guess you could use Gaviota's method (I think) of printing a :-) (a fail high is a good thing) when failing high and :-( failing low (a fail low is a bad thing).

Matthew:out

[bob]

Good point. Normally root moves that fail low (because there already is a better move in that iteration) would not be printed. How is that different here? As long as there is no move, would you print a PV for every move that fails low? Or just the first? I suppose the whole idea of having an aspiration window is that when the PV move fails low, you will try all other moves first before enlarging the window and redoing the iteration?

I could alter the sorting algorithm such that a new PV could never pass a PV of the same iteration that starts with the same move. Would that solve it?

Just a note. I re-search immediately, as I want to know how bad the fail-low is before continuing, so I have some clue on how much extra time I might want to use to improve things.

[diep]

Good point. Normally root moves that fail low (because there already is a better move in that iteration) would not be printed. How is that different here? As long as there is no move, would you print a PV for every move that fails low? Or just the first? I suppose the whole idea of having an aspiration window is that when the PV move fails low, you will try all other moves first before enlarging the window and redoing the iteration?

I could alter the sorting algorithm such that a new PV could never pass a PV of the same iteration that starts with the same move. Would that solve it?

As a side question - your modifications to xboard HGM, are they already stable - does nowadays xboard with your modifications no longer crash after a while?

Kind Regards,
Vincent

[Michel]

As a side question - your modifications to xboard HGM, are they already stable - does nowadays xboard with your modifications no longer crash after a while?

The released versions of xboard have always been extremely stable.
But please don't hijack this thread.

[diep]

As a side question - your modifications to xboard HGM, are they already stable - does nowadays xboard with your modifications no longer crash after a while?

The released versions of xboard have always been extremely stable.
But please don't hijack this thread.

Michael, it was a side note - but it's a very serious question as it was a serious issue here. We went back to old versions.

Now of course i only test at multisocket machines equipped with the latest GCC versions usually - there is more software very unstable at multisocket machines.

A good example of some years ago is filezilla server, which after some bugreports (and the initial denying that it could be a programming problem) were fixed.

[JVMerlino]

Good point. Normally root moves that fail low (because there already is a better move in that iteration) would not be printed. How is that different here? As long as there is no move, would you print a PV for every move that fails low? Or just the first? I suppose the whole idea of having an aspiration window is that when the PV move fails low, you will try all other moves first before enlarging the window and redoing the iteration?

I could alter the sorting algorithm such that a new PV could never pass a PV of the same iteration that starts with the same move. Would that solve it?

It seems to me that the most recent PV sent by the engine should always be on top, pushing all others down one row. Easy to read and understand, at least to me....

jm

[Michel]

It seems to me that the most recent PV sent by the engine should always be on top, pushing all others down one row. Easy to read and understand, at least to me....

The sorting is for multipv mode. It looks nicer if the PV with the highest score is on top even if other inferior PV's are generated later.