Evaluation Diagram, Winboard

[MB123]

Hi,

Evaluation Diagram in Winboard
I have 4.2.7 but it's not working, is this working in some other version?
Or is there some option to make it work?

Regards.

[H.G.Muller]

How do you mean, "not working". There is no such thing as an Evaluation Diagram in WinBoard 4.2.7, is there?

WinBoard 4.2.7 is stone age (from 2001, or so). We are nearly at 4.6.0 now for the beta version...

[MB123]

Evaluation Diagram is also there in 4.2.7+ (unofficial version "X") however there is no graph.
I installed 4.5.2 but Evaluation Diagram is not working.

Why? Does it work for you?

[EdCollins]

MB,

Is your Evaluation Graph not working at all?

As I type this I'm watching a match between two engines, and it's working fine for me, with version 4.5.2a. Note that very small score differences (like +.03) won't show up (give you a bar) on the graph at all.

Are you referring to it being "backward?"

If you have a polyglot ini file for your UCI engine, and if you happen to have ScoreWhite=true in it, then the graph will "look funny" from this type of graph you probably have seen in other GUIs. The reason is that chess engines usually report the score from their point of view and WinBoard takes this into account when it displays the graph. But the ScoreWhite=true switch exists because some people, like me, want to see the score reported from both engines from WHITE's point of view. Thus, all of my engine polyglot ini files have ScoreWhite=true in them. But WinBoard doesn't know this. It doesn't evaluate the position. If it sees +3.00, for example, coming from the Black side, it displays the graph bar below the horizontal axis line, believing that the engine thinks it (Black) is winning, when really Black knows that White is winning. So the evaluation data you see in the Engine Output windows wont necessarily match the bar graphs from what you are used to. (If you have ScoreWhite=true.)

(I think that explanation is correct. HG explained that to me in a earlier question I had. I thought the graph was broken, because it was off to me.)

In a future WinBoard version I would like the option of being able to the change the scale on the left, the y-axis, in the winboard.ini file. The bars are too small for me. I'd like to see taller bars for the smaller evaluations.

[EdCollins]

Hey H.G., now that I think about it, a quick "fix" for this "bar problem" should be easy. It's only my Black bars that are always backward. All you would need is a new switch in Winboard.ini, something like FlipBlackEvalBar=true. (The default would be false.) But if true, WinBoard just reverses what it would normally draw for Black. If it would normally draw the bar above the line, draw it below the line, and vice versa. This would fix the problem of not seeing the Black bars match the valuation of what is seen in my Engine Output window, for anyone choosing to use the ScoreWhite=true switch in their Polyglot ini.

[H.G.Muller]

No fix is needed, since there is no problem. ScoreWhite=true breaks correct operation of the WB engine simulated in Polyglot, and the fix for that already exist in the form of the Sccore is Absolute options. Flipping black bars in the Eval Graph would still leave score-based adjudications broken, would leave scores in the PGN broken, etc., so it is definitely not a good idea.

[H.G.Muller]

Evaluation Diagram is also there in 4.2.7+ (unofficial version "X") however there is no graph.
I installed 4.5.2 but Evaluation Diagram is not working.

Why? Does it work for you?

Ah, you are using Winboard_x. That is a world of difference with 4.2.7...

And yes, the Eval Graph works perfectly for me. But you have to be more specific about what you mean by "not working", because the latter can mean a thousand different things. (E.g. does the window not open, does it stay blank, does it only display the axis and no bars when you play engines against each other, etc.)

So:
1) What exactly are you doing with WinBoard (play against engine, play two engines, play on FICS, view PGN, ...)?
2) What would you expect the Eval Graph to do in this situation?
3) What is happening in stead?

[MB123]

File->Load Game then I've got three windows opened (plus one with the game): Move History, Engine Output and Evaluation graph.
This Evaluation graph is not working for me:

[EdCollins]

Wait! Okay, now I think I'm confused.

You say that no fix is needed and there is no problem and you mention the 'score absolute' options I don't see this option in winboard.ini, and I'm not aware of it being valid polyglot option either.

To clarify, here's what I would like:

1) To see the score from White's point of view in the Engine Output window. I do see this now, for all my engines, and I think (or I thought) it was because I have ScoreWhite=true in all of my polyglot ini files. (I have a different ini file for each engine.)

2) To see positive bars on the evaluation graph when White is winning, and negative bars on the graph when Black is winning. Right now, I don't see this. White's bars are always as they should be but Black's bars are always "reversed."

How can I do that? What do I need to do?

That certainly seems like a reasonable desire/request... for my bars to match what I see in the engine output windows. A positive score = a positive (above the line) bar. Negative score = a negative bar.

Currently, when the Black engine reports a negative score, (indicating to me that White is losing) the bar appears above the horizontal line. When a Black engine reports a positive score, (indicating that White is winning), the bars appear below the line.

I remember playing around with this a couple of months ago, and chatting with you about it, but I thought it was determined that I couldn't have both. I thought it wasn't possible.

[EdCollins]

MB, I think it's because the evaluation graph only works on engine vs engine games, or human vs engine games played via WinBoard. If you simply loaded a game, and are analyzing it, you won't see bars on the graph. HG will surely confirm or deny this.

[H.G.Muller]

File->Load Game then I've got three windows opened (plus one with the game): Move History, Engine Output and Evaluation graph.
This Evaluation graph is not working for me:

Unfortunately the image you tried to post does not work either. ([edit] But pasting the link to it directly in the browser address field does. It shows an Eval Graph without any data displayed in it.)

But are you sure the PGN game you load does contain scores? Can you post that game here?

[H.G.Muller]

You say that no fix is needed and there is no problem and you mention the 'score absolute' options I don't see this option in winboard.ini, and I'm not aware of it being valid polyglot option either.

These options can be set through the Options -> Adjudications dialog, (Engine #1/2 Score is Absolute). As command-line options they are available as -first/secondScoreAbs true|false.

To clarify, here's what I would like:

1) To see the score from White's point of view in the Engine Output window. I do see this now, for all my engines, and I think (or I thought) it was because I have ScoreWhite=true in all of my polyglot ini files. (I have a different ini file for each engine.)

2) To see positive bars on the evaluation graph when White is winning, and negative bars on the graph when Black is winning. Right now, I don't see this. White's bars are always as they should be but Black's bars are always "reversed."

How can I do that? What do I need to do?

It might very well be that WinBoard currently does not support that. But violating the standard in a way that achieves one of the things you want, but breaks correct operation in many different other places, and then providing new options to fix the self-inflicted problems in each of these other places, is certainly not a sensile way to handle it. For one, engines should follow the standard. And if they are not, an option should be provided to pre-process their output to make it look like they do, so that everything else automatically works correctly. The Score is Absolute options do this, by completely neutralizing the effect of the Polyglot ScoreWhite=true option, which is harmful.

That certainly seems like a reasonable desire/request... for my bars to match what I see in the engine output windows. A positive score = a positive (above the line) bar. Negative score = a negative bar.

It would only be a reasonable request that things work properly for compliant engines. Garbage-in, garbage-out is kind of an unavoidabe reality. If you feed WinBoard garbage, like scores with the wrong signs, you should expect bars to point in the wrong direction, muti-PV output to be sorted in the wrong order, winning engines to be adjudicated as loser, wrong scores in the PGN, etc. The Eval Graph (in its design by Alessandro Scotti) chooses the white POV for display, presumably because it makes it easier to compare the score of two playing engines, and I think this is a good choice. I see no benefit whatsoever in having the bars point in opposite directions, so I don't think it is a good idea to make the direction of the black axis user configurable.

For the POV used in score reporting in the Engine-Output window, there is an option -absoluteAnalysisScores true|false. This option is only effective in analysis mode, however, because this is a case where it is not so clear with which side the engine should associate itself. Its effect could be extended to Two-Machines mode, however, or a new option could be provided to control this in two-machines mode. This is open for discussion.

Currently, when the Black engine reports a negative score, (indicating to me that White is losing) the bar appears above the horizontal line. When a Black engine reports a positive score, (indicating that White is winning), the bars appear below the line.

I remember playing around with this a couple of months ago, and chatting with you about it, but I thought it was determined that I couldn't have both. I thought it wasn't possible.

[EdCollins]

As always, thanks.

I certainly understand, as a programmer myself, that making a fix/path to one thing could lead to the need to make a fix/path to all sorts of other things in other sections, and I DON'T want that either. That's not ideal at all.

As I'm sure you're aware, that's the proper way a chess evaluation graph should look which this Chess Cafe article confirms.

http://www.chesscafe.com/text/lopez06.pdf

When either engine believes White is winning, the bars are printed above the line. When either engine believes Black is winning, the bars are printed below the line.

And I thought it was proper for the score to always be displayed from White's point of view. Based upon all of the different forums we all participate in, and all of the scores reported for games/positions in those forums, that certainly seems to be preferred method. (It's certainly much less confusing/easier that way! A person only has to look at one thing... the score! I see +12.08 and I know White is winning. But if the score is displayed from the engine's point of view, then you always have to look at TWO things. You have to look at the score AND the color of that engine. +12.08 would mean Black is winning if that scored is displayed for Black.)

And I'm just still so used to the the Fritz interfaces, which I've used for years. (But they are not as good as WinBoard! ) For years I've owned Fritz 8 and now 12. No matter what engine I load, the score is always reported from White's point of view and I don't think I'm doing anything special to see that. And the evaluation graph is always printed as I described above and in the Cafe article.

So this it seems a little odd to me that WinBoard can't handle displaying the graph in the proper manner AND displaying the evaluation score output in the preferred manner. I've tried and tried, but no matter what I try, I can't seem to get both. I can get the bars printed correctly, and I can get both engines to report the score from White's point of view, but, as you again confirm, there is no way for WinBoard to do both. (Fortunately, I don't use the evaluation graph much at all, so I've been living without that.)

If I were to attempt to remedy this, my fix would go something like this: Just before the code is executed that actually graphically prints the Black bar on the screen, a new IF statement would be added to check to see if Ed's new "ReverseBlackBar" switch was set to true. And if so, that Black bar would be printed the opposite of what it was just about to do. If it was about to print it above the line, print it below the line and vice versa. (It's only Black's bars that are always messed up.) This code would be executed when replaying past PGN games or when engines play games... anytime the program is about to print the bar on the screen. (Temporarily multiply the score by -1 if necessary, but then immediately after the bar is printed, do that again to reverse it to set it back to what it was.)

And that's it. The program would only change the actual graphical printing of the bar on the screen. Everything else would be done just as it is now.

But I haven't seen the WinBoard code and I will certainly take your word that it's not that easy and there is much more involved than that. You've probably forgotten more about programming than I will ever know, and you certainly know the WinBoard code more than anyone.

[H.G.Muller]

If I were to attempt to remedy this, my fix would go something like this: Just before the code is executed that actually graphically prints the Black bar on the screen, a new IF statement would be added to check to see if Ed's new "ReverseBlackBar" switch was set to true. And if so, that Black bar would be printed the opposite of what it was just about to do. If it was about to print it above the line, print it below the line and vice versa. (It's only Black's bars that are always messed up.) This code would be executed when replaying past PGN games or when engines play games... anytime the program is about to print the bar on the screen. (Temporarily multiply the score by -1 if necessary, but then immediately after the bar is printed, do that again to reverse it to set it back to what it was.)

And that's it. The program would only change the actual graphical printing of the bar on the screen. Everything else would be done just as it is now.

And then it would be badly broken... Games would be adjudicated to the wrong side, scores would go wrong into the PGN, multi-PV output would be sorted in the wrong way... Having a bar point up or down, or seeing a + or - in the Engine Output window is a matter of taste, but adjudicating the wrong side to win, or having the best line so far not on top of the display are absolute errors, and thus much worse, agreed?

Currently WinBoard prints the bar exactly as you want it (and as anyone would probably want it). So no fix is needed there. Provided the engine does not lie about its score, of course. No matter how well WB does it, you can always wreck it by having the engine send wrong data. WinBoard has to go on the engine, it cannot calculate scores itself.

Reporting scores from the engine's own POV in the message field and engine-output window is how WinBoard has always done it (this is known as the EPD standard). But if you don't want that, the proper fix would be to flip the sign just before printing in the engine-output window. Which is exactly what the option /absoluteAnalysisScores=true does. Not flipping the input score, breaking everything, and then only repair the eval graph, leaving everything else broken...

[EdCollins]

And then it would be badly broken... Games would be adjudicated to the wrong side, scores would go wrong into the PGN, multi-PV output would be sorted in the wrong way... Having a bar point up or down, or seeing a + or - in the Engine Output window is a matter of taste, but adjudicating the wrong side to win, or having the best line so far not on top of the display are absolute errors, and thus much worse, agreed?

Agreed. All of that is much, much worse. But my first thought was that, if it was possible, only the printing of the bar on the screen would change. Everything else - adjudications, scores in the PGN, multi-PV output, all of that - would all continue to be exactly as it is now. That's all fine now and so we certainly don't want any of that to change.

I didn't realize all of that was so closely related. I only wanted Black's bars reversed from the way they were being printed on the screen and nothing else changed anywhere else.

Currently WinBoard prints the bar exactly as you want it (and as anyone would probably want it). So no fix is needed there.

This is correct. If I get rid of my ScoreWhite=true option in the Polyglot ini file, the Black evaluation bars are perfectly fine.

Reporting scores from the engine's own POV in the message field and engine-output window is how WinBoard has always done it (this is known as the EPD standard). But if you don't want that, the proper fix would be to flip the sign just before printing in the engine-output window. Which is exactly what the option /absoluteAnalysisScores=true does.

You mentioned this option in an earlier reply above. I wasn't aware of that option in WinBoard. Thanks. I tried it and it looks like it does the same thing that the ScoreWhite=true option does in the polyglot ini files. If so, I suppose I could then remove that statement from my polyglot ini files and use this option here instead.

But it doesn't appears as if this option is saved in winboard.ini anywhere. Question: I would have to always start WinBoard with this option on the command line, or go into Winboard Options and then Adjudications window each time I loaded the program, to set this up, correct? Would it be a good idea to add this option to winboard.ini in a future release?

I understand what you are saying. Reporting the score from White's point of view is not EPD standard. And yet you've given the user the option to display the scores the way they want, even if it is not standard, and this is all fine. So if the user wants to see the evaluation scores "wrong" (not EPD), then they have to just accept that they must see the graph "wrong" too. That makes sense to me, but I was hoping there was an easy fix/option/solution for that, so the user could have both... the scores displayed from White's POV, without messing up the already-correct graphical display... and without messing anything else up. Those two displays, numerical (score) and graphical (bars), should go hand-in-hand.

It makes sense to me when flipping the score for the user, to not also flip the bars. The bars were okay. Wait! I know what you're going to say. "I'm not doing anything to flip the bars." Exactly. But to the user, the illusion is, the bars are flipped, because the existing code does what it normally does and thus prints them differently all thanks to the user wanting the scores displayed different. But he/she didn't want the evaluation graph changed. Thus, the code should flip them to give the illusion that they aren't being flipped!


Educate me here. (From a programming standpoint.) Why won't this work:

You certainly must have some kind of a sub-routine that is called when it's time to print the bars.
Something like:

Code: Select all

code
code
Call PrintBarSubroutine
code
code
etc.,

PrintBarSubroutine:
   code that prints the Evaluation Bar
END PrintBarSubroutine


Instead, why won't this work:

Code: Select all

code
code
Call PrintBarSubroutine
code
code
etc.,

PrintBarSubroutine:
   IF absoluteAnalysisScores = true AND about to print the BLACK bar = true THEN
         Multiply BlackEvaluationScore by -1
   END IF
  code that prints the Evaluation bar
  (and then switch the Black's score right back, so nothing else is broken in the program) 
  IF absoluteAnalysisScores = true AND just printed BLACK bar = true THEN
         Multiply BlackEvaluationScore by -1
   END IF
END PrintBarSubroutine


Nothing else in the entire program would change at all. Only with that one statement immediately before the Black bar is actually printed on the screen, is the program modified to check to see if the the user has the option set to see the scores from White's POV. If both are true, the program temporarily reverses Black's evaluation, prints the bar as it does now, (which would flip-flop the bar from the way it's printing now) and then reverse the score right back, so nothing else is altered or changed anywhere else. This would print the graph properly, but still give the user his/her option to display the scores from White's POV.

I'm very curious to know why that won't work, from a programming standpoint. There's obviously must be more to it than that, based upon WinBoard's actual code and what it does, and I'm kind of interested to know a little more about it.

I enjoy reading your comments. And again, thanks for all your work on WinBoard. It beats all other interfaces hands-down.

[H.G.Muller]

I didn't realize all of that was so closely related. I only wanted Black's bars reversed from the way they were being printed on the screen and nothing else changed anywhere else.

Changed compared to what? If you don't change anything anywhere else, we just agreed that all the anywhere else is seriously broken, when you use ScoreWhite=true. So why would you not want changed things that are seriously broken? And if you use ScoreWhite=false, so that all the anywhere else again works as it should, and doesn't need change, the eval-graph bars also already point in the direction you want them to point. So no change is needed there either, since I really don't know anyone that would want them to point the other way.

You mentioned this option in an earlier reply above. I wasn't aware of that option in WinBoard. Thanks. I tried it and it looks like it does the same thing that the ScoreWhite=true option does in the polyglot ini files. If so, I suppose I could then remove that statement from my polyglot ini files and use this option here instead.

No, it does not do the same. The -first/secondScoreIsAbs options do the same. The /absoluteAnalysisScores option would just flip the score in the Engine-Output window. Without reversing the black bars in the eval graph, wrecking score-based adjudication, like ScoreWhite=true does.

But it doesn't appears as if this option is saved in winboard.ini anywhere. Question: I would have to always start WinBoard with this option on the command line, or go into Winboard Options and then Adjudications window each time I loaded the program, to set this up, correct? Would it be a good idea to add this option to winboard.ini in a future release?

Are you sure about this? Looking at the code, it should be saved. And indeed I also find it in my winboard.ini.

I understand what you are saying. Reporting the score from White's point of view is not EPD standard. And yet you've given the user the option to display the scores the way they want, even if it is not standard, and this is all fine. So if the user wants to see the evaluation scores "wrong" (not EPD), then they have to just accept that they must see the graph "wrong" too.

No, no, no!

This is exactly why I added the /absoluteAnalysisScores option. On your request when we were discussing this issue on Rybka forum, I think. To enable the user to see the sign of the score in the engine-output window in any way he wants, without having to accept that the bars point the wrong way, score-based adjudication no longer works, etc.

That makes sense to me, but I was hoping there was an easy fix/option/solution for that, so the user could have both... the scores displayed from White's POV, without messing up the already-correct graphical display... and without messing anything else up. Those two displays, numerical (score) and graphical (bars), should go hand-in-hand.

It makes sense to me when flipping the score for the user, to not also flip the bars. The bars were okay. Wait! I know what you're going to say. "I'm not doing anything to flip the bars." Exactly. But to the user, the illusion is, the bars are flipped, because the existing code does what it normally does and thus prints them differently all thanks to the user wanting the scores displayed different. But he/she didn't want the evaluation graph changed. Thus, the code should flip them to give the illusion that they aren't being flipped!


Educate me here. (From a programming standpoint.) Why won't this work:

You certainly must have some kind of a sub-routine that is called when it's time to print the bars.
Something like:

Code: Select all

code
code
Call PrintBarSubroutine
code
code
etc.,

PrintBarSubroutine:
   code that prints the Evaluation Bar
END PrintBarSubroutine


Instead, why won't this work:

Code: Select all

code
code
Call PrintBarSubroutine
code
code
etc.,

PrintBarSubroutine:
   IF absoluteAnalysisScores = true AND about to print the BLACK bar = true THEN
         Multiply BlackEvaluationScore by -1
   END IF
  code that prints the Evaluation bar
  (and then switch the Black's score right back, so nothing else is broken in the program) 
  IF absoluteAnalysisScores = true AND just printed BLACK bar = true THEN
         Multiply BlackEvaluationScore by -1
   END IF
END PrintBarSubroutine


Nothing else in the entire program would change at all.

So how would that fix then that score-based adjudication would not work?

Only with that one statement immediately before the Black bar is actually printed on the screen, is the program modified to check to see if the the user has the option set to see the scores from White's POV. If both are true, the program temporarily reverses Black's evaluation, prints the bar as it does now, (which would flip-flop the bar from the way it's printing now) and then reverse the score right back, so nothing else is altered or changed anywhere else. This would print the graph properly, but still give the user his/her option to display the scores from White's POV.

I'm very curious to know why that won't work, from a programming standpoint. There's obviously must be more to it than that, based upon WinBoard's actual code and what it does, and I'm kind of interested to know a little more about it.

I enjoy reading your comments. And again, thanks for all your work on WinBoard. It beats all other interfaces hands-down.

I don't understand why we have so much difficulty in communicating this. Let me tell you a story, that will teach us a moral lesson:

There once was a prince, who liked to drink tea. But the kitchen in his palace only had a tap for cold water, and the tea he was brewing with that tasted pretty lousy, especially since he liked his tea strong. So, being also in charge of the water company of his princedom, he dictated a law that the water company should pipe boiling water to the capital, so that it would emerge scaldingly hot from the tap in his palace. But occasionally he also wanted to drink cold lemonade, and it annoyed him that he had to wait a long time for the water to cool down. So he wanted the water company to install a cooler in his kitchen, where the hot tap water would flow in, and would come out with ice cubes. In the mean time, the villagers were complaining that they scalded themselves trying to wash their hands, but the prince did not care much about that, because washing was something he never did. The manager of the water company by now was receiving many death threats from angry customers, and pestering the prince about that. But the prince said: "Just install me a cooler, that would solve everything. Then you don't have to change anything anywhere else!" The manager complied, and was richly rewarded by the prince, and both of them lived happily (albeit shortly) somewhat after.

(Moral lesson: when you want to brew tea, use a kettle!)

[EdCollins]

Are you sure about this? Looking at the code, it should be saved. And indeed I also find it in my winboard.ini.

I'm positive. Hold on... I just checked something. Ah ha. In my hgmaster-20110529 winboard.ini file (that I run from a different directory), there is that option saved. It is definitely not saved in the winboard 4.5.2a ini file. Throughout this discussion I've been testing and using the 4.5.2a program. (I don't use the hgmaster version too much at all.)

I have to go to work, but later this evening, I will run some more tests. Our lack of communication might be because we've been using/talking about different versions of the program.

Thanks.

[H.G.Muller]

Well, 4.5.2a would not know this option. So it cannot save it to the ini file, and wen it happens to be in the ini file, it would choke on it.

It is only in the 4.5-TM version. We discussed this (plus the option to change the multi-PV setting from the engine-output window) well after the release of 4.5.2.

[EdCollins]

Ok. Here we go.

I was happy to read this sentence:

The /absoluteAnalysisScores option would just flip the score in the Engine-Output window. Without reversing the black bars in the eval graph, wrecking score-based adjudication, like ScoreWhite=true does.

That's exactly what I (and lots of other users) would like to see. However, I still can't get it to work.

I'm using hgmaster-20110529. (As mentioned above, I DO see the AbsoluteAnalysisScores switch in this winboard.ini file.)

I'm using Glaurung as my engine, for both sides. (Although all engines I test give identical results.)

I do NOT have ScoreWhite=true in my Glaurung ini file. That's been removed. (The only thing in this ini file is the engine path so Polyglot knows where the Glaurung engine is.)

In each of the four configuration tests below, I begin a game between Glaurung and itself with the moves 1.e4 Nf6 2.Qh5 Nxh5. (2.Qh5, of course, is a clear blunder, which loses the Queen with zero compensation. Black is clearly winning.)


Test #1
---------
/absoluteAnalysisScores=false in ini file.
Both of the "Engine Score is Absolute" boxes are NOT checked.

Result:
White's score in the Engine Output window is negative.
Black's score in the Engine Output window is positive.
Evaluation Bar Graph is fine. (All bars pointing down... both sides agree Black is winning.)

These are probably the default options and it's all good. The analysis is "proper." The graphs are drawn correctly. Everything is fine. But Black's analysis is positive and not from White's POV as I would like. So lets try...


Test #2
---------
/absoluteAnalysisScores=false in ini file
Both "Engine Score is Absolute" boxes ARE checked this time.

Result:
White's score in the Engine Output window is negative.
Black's score in the Engine Output window is negative.
Evaluation Bar Graph is wrong. (Black's bars are now pointing up, which indicates White is winning when Black is really winning.)

Nope. So now let's exit, edit winboard.ini, and try again.


Test #3
---------
/absoluteAnalysisScores=true in ini file this time.
Both "Engine Score is Absolute" boxes are NOT checked.

Result:
White's score in the Engine Output window is negative.
Black's score in the Engine Output window is positive.
Evaluation Bar Graph is fine. (All bars are pointing down... both sides agree Black is winning.)

Nope. (This is the same result as Test #1.)



Test #4
---------
/absoluteAnalysisScores=true
Both "Engine Score is Absolute" boxes ARE checked.

Result:
White's score in the Engine Output window is negative.
Black's score in the Engine Output window is negative.
Evaluation Bar Graph is wrong. (Black's bars now pointing up, which indicates White is winning when Black is really winning.)

Nope. (And this is the same result as Test #2.)

After these tests, initially with 20110529, I checked your site and I see I'm NOT using the latest version. However, I downloaded hgmaster-20110619 (WinBoard-4.5TM) but the results with this latest version are identical to that above.

So what, in blazes, am I doing wrong?

[H.G.Muller]

OK, it works only in analysis mode, not in TwoMachines mode (as the name of the option already suggests).

But it would be easy to extend its effect to all modes, or make another, similar option for that works in all modes, like /displayWhiteScores. It is just that no one ever requested that.

[edit] I just posted a version at http://hgm.nubati.net/WinBoard-4.5.beta.zip , where I deleted the condition gameMode == AnalyzeMode where the /absoluteAnalysisScores flips the sign for the engine-output window.