hgm wrote:As I wrote above, WinBoard displays any variation the engine produces as thinking output, in the engine-output window. That would automatically include multi-variation.
The current results are less than ideal. I added "MultiPV=4" to my polyglot file for Rybka and analyzed [d]rnbqk1nr/pppp1ppp/8/2b1p3/3PP3/8/PPP2PPP/RNBQKBNR w KQkq - 1 3
At some point the analysis window showed
and then the next update showed
It then continued to delete lines from the bottom until one was left, and then the next update showed five lines like the first image above, but one ply deeper. Showing the worst variation on top is a little confusing, though understandable, but the deletions make it more or less useless.
It must be something Polyglot does that causes the deletion of engine-output lines. Normally all lines stay in the Window until the engine moves, or a move is sent to the engine.
If your OS can run 64-bit engines, and your OS can run WinBoard, you can run the engines under WinBoard.
It must be something Polyglot does that causes the deletion of engine-output lines. Normally all lines stay in the Window until the engine moves, or a move is sent to the engine.
The Polyglot log for one ply is pasted below. If you want the whole thing you could PM me your email or something.
It seems in the above engine output, PV lines are sent repeatedly: each time one of the four PV lines is increased in depth from 2 to 3, not only the new line is sent, but also a repetition of all the other PVs, which are still at depth 2.
This is not what the engine should do. Even if WinBoard would display such lines, it would needlessly eat up space in the engine-output window, as the lines are already there exactly as repeated. WinBoard reacts by clearing the engine-output window when it receives a PV with lower depth as the one it already has, as it assumes a new search has started.
In the end the 4 d=3 lines should have been displayed, though, which is the intended effect. But you would have lost all d=2 info, which is unintended. And if the search would have been continued with d=4, all d=4 lines would have immediately been cleared away by the following (repeated) d=3 lines, untill all d=4 lines are available.
A WinBoard engine running in multi-PV mode should not repeat lower-depth lines in its thinking output, but only send the PVs that are truly new.
hgm wrote:WinBoard reacts by clearing the engine-output window when it receives a PV with lower depth as the one it already has, as it assumes a new search has started.
Ah, that's the reason why the output sometimes just disappears when my
engine prints its PV. I have a strange depth management in the search
with increments and decrements a fraction of a ply and somehow this
may go down through the iterative search and its output. Or may be I write
the PV at each new best move in ply 0. I can't remember exactly without
looking in the source. But I plan to clean up this mess if I ever work on the
engine again.
I have no idea. If this is standard behavior for UCI engines, it should be considered an error of Polyglot translating UCI to WB protocol. If Polyglot would only forward those lines to WB it is not receiving for a second or later time, things would work smoothly.
