WinBoard Evaluation Graph

[EdCollins]

1) From what I believe is standard, bars printed above the horizontal evaluation graph axis indicate the engine evaluates the position as better for White. Bars printed below the axis indicate the engine believes the position is better for Black.

Thus, when White is clearly winning and when both engines are in agreement with this, both engines print the bar above the axis line. (And if Black was winning and both engines agreed, all of the bars are printed below the horizontal axis line.)

This is how, for example, Fritz 12 displays the graphs.

However, with WinBoard, (version 4.5.2 and the hgmaster 20110521 version I'm using) the output is different. When White (for example) is clearly winning and both engines agree with this, one engine prints the bars above the line and the other engine prints them all BELOW the line.

And I've discovered why. Note that in my polyglot ini files for both engines, I do have ScoreWhite = true. When true, each engine is (apparently) printing the bars from their own point of view. White says I'm winning and prints the bars above the line and Black says, yep, I'm losing, and prints the bars below the line.

When I change it to ScoreWhite = false, I do get the 'proper' evaluation bar output. When false, when both engines agree White is clearly winning, all bars are above the line. (And when Black is clearly winning, all bars printed are below the line.) But of course, now the "engine output pane" is not what I desire at all... each engine is printing their scores from their own point of view, and I much prefer seeing each score from White's point of view.

To summarize, when we have...

ScoreWhite = true and White clearly winning:
Both engine scores are positive... but the graph
doesn't show both bars as positive. (Above the line.)

ScoreWhite = false and White clearly winning:
The graph shows all bars positive (above the line) but the engine
output doesn't show both scores positive (one is positive and one
is negative.)

(I hope that explanation is clear.)

Question: Does WinBoard know when the polglot ini file has ScoreWhite = true? It probably does not, does it? (I think maybe Polyglot "reverses" it and then sends the score to WinBoard and WinBoard simply prints it.)

Is there a new switch that can be added to winboard.ini... maybe something like /evalGraphScoreWhite = true or something, so the engine analysis score and the graph bars "match?"

I don't think the evaluation graph should ever print the bars in the way it's doing when ScoreWhite=true, (I don't think that's a proper graph) but if WinBoard has no way of knowing, then maybe a switch is desired for all of us who do have ScoreWhite=true in our engine ini files.



2) One other item, while I have your attention.

When a second game of the match starts between two engines, the engine analysis output from the first match should, ideally, be cleared immediately.

While watching a recent engine vs engine match, the second game of the match was almost a minute into the game, yet the window pane from one engine still showed analysis from the FIRST game! The reason was simple... this engine was not yet out of its book for this second game... it hadn't started analyzing yet, and the other engine was busy thinking. The previous analysis had not been cleared. So for almost a minute, until this engine starting analyzing on its own, I'm seeing analysis on my screen from the previous game that had nothing to do with the current game. Ideally, the window should be cleared right away.

I noticed a similar thing when I loaded a second engine in the hgmaster-20110521 copy. I started the program with two engines, but then immediately replaced one of the engines with a different engine via the ENGINE - LOAD ENGINE menu. (It's nice to be able to do this.) But after loading it, the prior engine's logo didn't immediately get replaced with the new engine's logo, as I expected it to, "indicating" and helping to inform the user that the new engine was indeed loaded properly. As soon as a user loads a different engine, I think the logo should be updated.

As always, thanks in advance.
Ed

[H.G.Muller]

WinBoard itself does not have the capability to judge the evaluation of positions. It is dependent on engines for this. So if not all engines report the score in the same (standard) way, whings will not work correctly for those that report scores the non-standard way. This is unavoidable. The standard is that engine report score from their own point of view. Engines that don't, should be considered broken, and several things will not work for them. One is the eval graph. Another is score-based ajdudication.

You are correct to suppose that WinBoard does not know what is in the polyglot.ini file. As far as WinBoard is concerned, Polyglot is the engine. If you use options in it that break correct operation of Polyglot, WinBoard will simply treat it as a broken engine. For score reporting it can of course not know that the engine is broken.

Hanging otput in the engine-output window is indeed a bit confusing. I guess I should indeed clear it when a new game starts.

As for the logos: Yes, I see that this has become a problem now that I do not really load the second engine when the user specifies another one with the Load Engine dialog. Normally the second engine is not loaded in WinBoard until you really use it. (And Two Machines mode is the only mode that uses it.) This is why you normally don't have to bother about what is in the second combobox of the Startup dialog when you are not planning to use Two Machines mode, even if there is a non-existing engine there.

Problem is that I load and display the logo from the routine that starts up the engine process, as this is in the platform-dependent part of the code, so I could do it only in the WinBoard part. This is not a fail-save method; it does for instance not know whether it s starting a process for the first or the second engine, and tries to figure it out by comparing the name of the engine it is starting to that of first and second. (Which fails if first and second have the same name!). An it also fails when starting the engine process is delayed to the actual usage, as with the second engine. It would be much better to control the loading of logos from the back-end, where all info is still available. But this cannot be allowed as long as XBoard does not support logos. I guess I should make dummy routines in the XBoard front-end to display the logos, and then migrate the remainder of the logo-handling code to the back-end. Unfortunately this is neither a small, nor a straightforward change, as WinBoard and XBoard do not spport the same formats for graphics files. So even handling the filename is not truly platform independent, as logo.bmp wouldn't make any sense in XBoard, where the logo would probably be a pixmap, and thus should be called logo.xpm.

I guess I will defer solving this problem until I have implemented logos in XBoard. Nevertheless, thank you for reporting the problem.

[Dann Corbit]

Notion to fix this problem:
Have a calibration run with an easy checkmate problem and an easy tactical problem for both white and black to move.
Then you will know for any given engine what the direction of the score means.

[H.G.Muller]

True, this could be done. Like I could do a test run feeding the engine a KPK position to determine if it numbers the ranks such that white Pawns move to higher-numbered or towards lower-numbered ranks. Or if they want to start counting ranks from zero in stead of one. But I think it is a lot more efficient to define a standard, and enforce it on the engine.

The way I see it, when an engine is non-compliant, it is a good thing fix the engine., and an evil deed to adapt the GUI to it. The latter encourages more non-compliancy, and eventualy total chaos.

[Dann Corbit]

Problem is that a zillion old engines that will never be fixed have the problem.
However, I do admit that I agree with you wholeheartedly.

[H.G.Muller]

Well, for this particular problem it is not that bad: WinBoard offers an option where the user can tell if the engine reports scores from the whitepoint of view. So the only inconvenience is that the user has to tick "first/second score is abolute" each time he uses the engine, as the default vlue is of course -firstScoreAbs false. Or he could add that to the engine line by editing the engine list, adding the option -firstScoreAbs true, so that it ecomes effective as soon as he selects the engine from the list.

IMO it is not a bad thing if the user needs to perform a few cumbersome actions to get non-compliant engines to run.