Evaluation Diagram, Winboard

[EdCollins]

Oh my God...

IT WORKS!

Very nice. Thanks a lot. Much appreciated.

- Ed

[H.G.Muller]

Yes, well, sort of. I guess it is still inconsistent that when you step through a game, the scores that are shown in the comment window are still always engine POV, which is confusing if you have them white POV in the engine-output window.

I wonder if I should keep that feature at all, though. Initially, (in Winboard_x) the score was shown in the Comment window only when you loaded a game (not when you stepped through a just-played game), because it is stored in the PGN file in the format of a comment, and then treated it on loading like any other comment. This was inconvenient, because the Eval Graph would then not work. So on loading a game, I also copied this info to the list of PV info, where it is stored when it is directy obtained from an engine. But then, saving the game a second time would duplicate the info, because it converts the PV info again to a {score/depth} comment, and saved the other comments (including the score/depth) as they were displayed in the Comment popup. So I added code to recognize if the Comment window contained a score/depth comment, and to ignore it if it did.

But having the Comment window pop up when stepping through a game (when /autoDisplayComment=true) for every move just because of the score/depth comment is annoying more often than not. If I treat score/depth comments special anyway, diverting them to the PV info on loading and removing them from the comment channel on saving, I might as well remove them from the comment channel on loading. They would then never show up in the comment window. Which is just as wel, because there is no reason why you should be allowed to edit them. The scores could still be seen from the Eval Graph. (Not depth, however.) And the Move History window can be set to show score/depth info with every move. I am reluctant to mess with
the sign of the score there, though, because the Move History is in PGN format (albeit without tags), and people could copy-paste it to post games, hampering the interchangeability of data when they mess with the score.

Perhaps I should add a function for hovering over the Eval Graph. Currently WinBoard only reacts to clicking on the graph, by going to the corresponding move. But perhaps it would be nice if you could just point to a bar in the Eval Graph, which then would display the move number, score, depth and thinking time in the title bar of that eval graph. (And then of course display the score there with the sign as indicated through the /absoluteAnalysisScores option.) Or perhaps I should forget about the hovering, and simply print the PV info of the current move in that title bar. (Like "Evaluation Graph {-2.75/12 6}". Move number and move would already be displayed in the message field of the board window.)

As far as making better use of (now often static) title bars is concerned: how about using the title bar of the Move History to display the 50-move counter? Or would it be better to do that in the title of the Engine Output window? I certainly could indicate the score POV in the latter, now that we make it variable.

[H.G.Muller]

I now uploaded a version (same link) that displays the score in the Eval Graph title in stead of the comment window. It also prints the number of ply to go to a 50-move draw when it drops below 40, in the Engine Output title.

[EdCollins]

After work I will download this version and take a look at the changes.

This reminds me...

At this page:

http://www.autochess.com/forum/firebird ... 98-45.html

there is a mention, and an image near the bottom of the page, that show a little "cloud" that apparently appears in the engine output window when an engine has accessed an endgame tablebase. Is that true? If so I don't believe I've ever noticed that before. Is that an undocumented "Easter Egg?" I also don't recall reading about that anywhere in the winboard help files.

[EdCollins]

The score in the evaluation graph window is a nice touch.

Question: How difficult is it to give the user the option to define the scaling for the y axis? Sometimes I think it would be nice to see a smaller scale, so that small edges produce slightly taller bars. Or bars when there are none. Currently, it appears no bar is drawn at all if the evaluation is within + or - .25. Thus, for often a dozen opening moves or more, no bar is show at all, since the score is often still close out of the opening. During these times the user, (until they start seeing bars), probably think it's not working at all!

Even if this y axis value were simply a value that was changed via the config file, that would be fine. (I love that winboard.ini file. You can't have too many options in there. They remain invisible to the casual user, and yet they are all there to edit if the more experienced user wishes to do so.)

I had forgotten about /AutoDisplayComment=true. I keep that at false. That comment window popping up all the time used to drive me crazy and I had no use for it. Question: Is there an option so that when I load a game, WinBoard doesn't automatically start stepping through the game on its own, if I don't want it to?

I like how the evaluation BAR graph turns into a LINE graph as soon as you draw edges inward and make it smaller.

Hovering over the graph, and instantly going to that position, instead of double-clicking the bars, might be neat. I'd have to see that to say yay or nay. (It would probably be welcome by all... double-clicking is a pain. I'd rather that be single click, if possible, rather than double-click.)

The number of plies to a draw, at the top of the Engine Output window, is also a nice touch. When watching engine-vs-engine matches, that might come in handy to know. Question: Will that also appear when playing live games on a chess server? (If so, that might be even more beneficial to know.)

I found a bug/mistake, I think:

I set up a locked pawn endgame position

3b1k2/8/5p1p/4pP1P/3pP3/2pP4/B1P3K1/8 w - - 0 1

and just watched the two kings and a couple of bishops dance around, doing nothing at all, for 50 moves.

As soon as Black made his 50th move, the position was adjudicated to a draw and the game was over. ("Draw by fifty-move rule" shown in main window.) However, back in the Engine Output window, the message said "2 plies to a draw."

At that point, once Black made his 50th, it almost certainly should have said "0 plies to a draw." It never said that, nor did it even get down to 1 ply. I think that Engine Output "plies to draw" counter isn't correctly synched with the adjudication code counter... it's off by two.

Back to the evaluation graph: On my screen, right now, I still have this game on the screen. The evaluation graph has been open the entire time. Guess what? There are no bars shown at all! And that's because the evaluation was so close, the entire game, so no bars were drawn at all. So here's a case where it might be desirable to see SOME bar, no matter how small, drawn. And I think we would see one if the y axis could be scaled.

[EdCollins]

Question: Is there an option so that when I load a game, WinBoard doesn't automatically start stepping through the game on its own, if I don't want it to?

Nevermind. Found it. /timeDelay=-1

[H.G.Muller]

The cloud icon in the Engine-Output window means the engine is pondering. Nothing more, nothing less. When it is thinking, you will see a clock, when it is analyzing, a magnifying glass. WinBoard can never know if an engine uses talebases or not; WB protocol does not define a way to transfer that information.

The /timeDelay option can be set through the Load Options menu dialog. Setting it to -1 suppresses stepping alltogether, so you stay at the initial position. Setting it to 0 moves you instantly to the final position of the loaded game. (Fractional settings like 0.3 sec are also accepted.) Note this parameter is currently also used to determine the analysis time per move when you do Analyze File. This is still a feature that needs some revision; perhaps it should have its own independent time-delay setting, or use the TC parameters do decide about stepping rate, and I would also not want it to have its own file-browse dialog, but simply act on a game that is already loaded (starting from the currently displayed position). I.e. replace the menu item by "Analyze Game".

The Eval Graph still works exactly the same way as Alessandro designed it in Winboard_x. I completely refactored the code, to separate logic from GUI functions, to facilitate porting it to XBoard, but I did not change anything. Except that I lately changed the scale in drop games (Crazyhouse, Shogi) to run from -15 to +15, as a score of +5 hardly means anything in those games, and Shokidoki can lose games where it has been at +23! I don't know what was Alessandro's reason to suppress the low scores. Perhaps I should simply not do that. I don't know if there would be a convenient algorithm to adapt the vertical scale. Currently it saturates at about 6-7, and expanding it further seems pointless, as in non-drop variants such scores are decisive. To better see small scores one can scale up the window. Scores of around 0.1-0.2 are completely meaningless; they are just evaluation noise, and I don't think you would need that much magnification to see such scores. (Provided even small bars are printed). I'd rather not make the scaling dynamic (dependent on the data in the graph), because it makes it more difficult to interpret it at a glance, and would make for a 'jumpy' display.
We could consider a non-linear scale, though, expand the range {-1,+1} compared to the rest of the graph by a factor. By making that factor user-configurable, you would also supply a means to switch it on and off. E.g. add the option /evalGraphScale with default value 1, which determines the expansion factor. If one would set it to 2, the distance between the horizontal axis and the y=1 line would be the same as that between the y=1 and y=3 line, etc.
I hardly ever click on the Eval Graph, but I was surrised to see one needed double-clicks. That seems pointless, and indeed in XBoard I implemented it with single clicks. (For the Move History window double-clicks are justified, because the single clicks are reserved for normal editing functions like select, copy, because it is text.) I guess I should change it to single click in WinBoard also.

I like it very much to see the score in the Eval Graph title; this makes the use of /autoDisplayComment=true actually bearable, becase now the Comment window pops uponly when there are genuine comments. Like you, I also usually switched it off. I guess now that the main reason that it was made possible to switch it off was the scores in the PGN. (In 4.2.7 it could not be switched off, but that could also not print score/depth comments in the PGN...)

About the 50-move counter: Can you post the game where this happened? I could not reproduce it with Fairy-Max, because it goes for a rep-draw even before 20 moves are done. I did a similar test yesterday, before uploading the thing in KBPKB, though, where one of the engines avoids rep-draws because he is a Pawn ahead. Then the adjudication occurred at the point where it said "(0 ply to draw)".
Are you sure this was an adjudication? I don't recognize "Draw by fifty-move rule" as something WinBoard would ever say. So it seems that this is coming from the engine. Do you have "Verify Engine Claims" switched on?

[EdCollins]

Here is the game I mentioned, straight from my saved games pgn file:

Code: Select all

[Event "Engine vs. Engine Game"]
[Site "EDs-PC"]
[Date "2011.07.06"]
[Round "-"]
[White "Critter 1.2"]
[Black "Komodo 2.03"]
[Result "1/2-1/2"]
[TimeControl "180+2"]
[FEN "3b1k2/8/5p1p/4pP1P/3pP3/2pP4/B1P3K1/8 w - - 0 1"]
[SetUp "1"]

{--------------
. . . b . k . .
. . . . . . . .
. . . . . p . p
. . . . p P . P
. . . p P . . .
. . p P . . . .
B . P . . . K .
. . . . . . . .
white to play
--------------}
1. Kf3 {+0.01/52} Ke7 {+0.03/26 0.6} 2. Kg4 {+0.01/54 5} Kd6 {+0.00/29 1.4}
3. Bc4 {+0.01/54 7} Bb6 {+0.02/29 1.1} 4. Bd5 {+0.01/53 6} Bc5
{+0.01/29 1.1} 5. Be6 {+0.01/53 5} Ba3 {+0.01/28 0.7} 6. Ba2 {+0.01/51 6}
Kc5 {+0.05/30 2.3} 7. Bc4 {+0.01/48 7} Bc1 {+0.05/30 1.0} 8. Kf3
{+0.01/46 7} Be3 {+0.05/30 0.9} 9. Be6 {+0.01/47 6} Bf4 {+0.05/32 1.3} 10.
Bd5 {+0.01/45 6} Kb4 {+0.05/29 0.8} 11. Ke2 {+0.01/45 6} Be3 {+0.05/32 1.8}
12. Ba2 {+0.01/45 6} Ka3 {+0.05/35 3} 13. Bc4 {+0.01/43 6} Kb2
{+0.05/33 0.9} 14. Kd1 {+0.01/44 6} Bd2 {+0.03/30 6} 15. Bf7 {+0.01/39 6}
Ka3 {+0.05/36 6} 16. Bg6 {+0.01/42 4} Ka2 {+0.05/36 7} 17. Be8 {+0.01/44 5}
Kb1 {+0.05/34 2.2} 18. Bc6 {+0.01/41 5} Bc1 {+0.05/39 6} 19. Ba4
{+0.01/39 5} Kb2 {+0.05/33 1.9} 20. Bb3 {+0.01/43 3} Bf4 {+0.05/35 1.3} 21.
Bd5 {+0.01/45 5} Bg5 {+0.05/38 2.5} 22. Be6 {+0.01/44 5} Kb1 {+0.05/37 2.1}
23. Bb3 {+0.01/45 3} Ka1 {+0.05/32 0.7} 24. Bc4 {+0.01/41 5} Bf4
{+0.05/33 1.5} 25. Bd5 {+0.01/41 5} Kb1 {+0.05/38 3} 26. Bf7 {+0.01/44 5}
Bc1 {+0.05/34 0.9} 27. Bc4 {+0.01/44 5} Ba3 {+0.05/35 1.0} 28. Bb5
{+0.01/40 5} Kb2 {+0.05/38 4} 29. Ba4 {+0.01/43 4} Bc5 {+0.05/37 3} 30. Bd7
{+0.01/42 4} Bd6 {+0.05/36 4} 31. Bc6 {+0.01/39 4} Be7 {+0.05/38 37} 32.
Bd5 {+0.01/37 4} Bb4 {+0.05/32 1.2} 33. Bg8 {+0.01/35 4} Bc5 {+0.05/34 32}
34. Bb3 {+0.01/33 4} Ba7 {+0.05/32 27} 35. Bc4 {+0.01/31 4} Ka3
{-0.05/30 23} 36. Bf7 {+0.01/29 4} Bc5 {-0.05/28 7} 37. Bd5 {+0.01/27 4}
Kb4 {-0.05/29 11} 38. Ke2 {+0.00/26 6} Bd6 {-0.05/27 1.8} 39. Bc4
{+0.00/26 4} Be7 {-0.05/28 4} 40. Bb3 {+0.00/29 3} Kc5 {-0.05/27 7} 41. Bc4
{+0.00/41 2.7} Bd6 {-0.05/26 6} 42. Bd5 {+0.00/45 4} Bc7 {-0.05/25 6} 43.
Kf3 {+0.00/47 4} Bb6 {-0.05/24 3} 44. Bf7 {+0.00/45 2.9} Kc6 {-0.05/24 14}
45. Be6 {+0.00/46 2.9} Kc7 {-0.05/21 3} 46. Bc4 {+0.00/56 1.1} Bc5
{-0.05/21 4} 47. Bd5 {+0.00/56 0.3} Kd7 {-0.05/21 3} 48. Be6+
{+0.00/56 0.2} Ke7 {-0.05/26 2.0} 49. Ke2 {+0.00/56 0.2} Kd6 {-0.05/32 2.1}
50. Bb3 {+0.00/56 0.2} Bb6 {-0.05/99 0.3}
{Draw by fifty-move rule} 1/2-1/2


And yes, my Verify Engine Claims box is checked, in the Options-Adjudications window.

Alas, I did not make a screen capture to prove I did see that it still said "2 plies to a draw" in the Engine Output window, after the game was over. However, I have no doubts that if I play the game again from the same initial setup, although I'd get a different game, the result would be the same, and the same display would appear. So I could do that if needed.

But I'm off to work now...

[H.G.Muller]

Oh, one more question:

What is the setting of the "N-move rule" in the Options -> Adjudications dialog?

[EdCollins]

That setting is currently set at 51. I almost positive I've never ever changed or touched that, so I must assume it was at 51 when I ran the initial test. (Shouldn't that default setting be 50?)

I tried it again, this time with two different engines.

On my first two attempts, the engines drew the position by repetition, so I had to try again. But eventually I got them to play all the way through. So the steps are:

Setup Position and then Mode: Two Machines
The Verify Engine Claims box has not been touched. (It's still checked.)
Apply x move rule is set at 51.

For all three games, even the first two were a drawn by repetition, I noticed the "plies to draw" display notice was first seen moment after White made its 32nd move ("39 plies to draw").

This last attempt that finally lasted a full 50 moves had identical results to yesterday's test. The game is over... Drawn by 50-move rule seen in Main Window... and "2 plies to draw" still seen in Engine Output Window. See the graphic at the URL below.

Code: Select all

[Event "Engine vs. Engine Game"]
[Site "EDs-PC"]
[Date "2011.07.07"]
[Round "-"]
[White "Fruit 2.3.1"]
[Black "Crafty-23.4 PS"]
[Result "1/2-1/2"]
[TimeControl "240+2"]
[FEN "3b1k2/8/5p1p/4pP1P/3pP3/2pP4/B1P3K1/8 w - - 0 1"]
[SetUp "1"]

{--------------
. . . b . k . .
. . . . . . . .
. . . . . p . p
. . . . p P . P
. . . p P . . .
. . p P . . . .
B . P . . . K .
. . . . . . . .
white to play
--------------}
1. Kf3 {+0.03/34} Ke7 {-0.01/60 0.5} 2. Bd5 {+0.03/36 6} Kd6 {-0.01/60 0.3}
3. Ke2 {+0.03/47 10} Kc5 {-0.01/60 0.2} 4. Be6 {+0.03/53 11} Ba5
{-0.01/60 0.2} 5. Bc4 {+0.03/47 7} Bb6 {-0.01/60 0.3} 6. Bf7 {+0.03/41 5}
Bc7 {-0.01/60 0.3} 7. Bb3 {+0.03/49 6} Bd6 {-0.01/60 0.3} 8. Be6
{+0.03/50 10} Be7 {-0.01/60 0.3} 9. Bc4 {+0.03/51 5} Bd6 {-0.01/60 0.3} 10.
Bd5 {+0.03/51 9} Bc7 {-0.01/61 0.2} 11. Kf2 {+0.03/34 5} Bd6 {-0.01/60 0.2}
12. Ke1 {+0.03/46 5} Be7 {-0.01/60 1.6} 13. Be6 {+0.03/48 8} Bf8
{-0.01/60 0.5} 14. Bc4 {+0.03/48 8} Bd6 {-0.01/60 0.3} 15. Ke2 {+0.03/50 8}
Be7 {-0.01/61 0.2} 16. Be6 {+0.03/49 8} Bd6 {-0.01/61 0.3} 17. Bb3
{+0.03/51 4} Bc7 {-0.01/61 0.3} 18. Bf7 {+0.03/47 4} Bd6 {-0.01/61 0.3} 19.
Kf2 {+0.03/33 14} Be7 {-0.01/60 0.2} 20. Ke1 {+0.03/33 19} Bd8
{-0.01/60 2.0} 21. Be6 {+0.03/38 3} Bc7 {-0.01/60 0.2} 22. Bd5 {+0.03/45 4}
Bb6 {-0.01/61 0.2} 23. Kd1 {+0.03/49 4} Ba5 {-0.01/60 0.2} 24. Ba2
{+0.03/51 7} Bc7 {-0.01/60 0.3} 25. Bc4 {+0.03/45 6} Bd8 {-0.01/61 0.3} 26.
Ke1 {+0.03/47 6} Bb6 {-0.01/61 0.2} 27. Bd5 {+0.03/47 6} Ba5 {-0.01/60 0.2}
28. Kd1 {+0.03/45 6} Bd8 {-0.01/61 0.2} 29. Bb7 {+0.03/43 6} Be7
{-0.01/60 0.3} 30. Bc8 {+0.03/41 6} Bd6 {-0.01/60 0.2} 31. Be6 {+0.03/39 5}
Bc7 {-0.01/61 0.3} 32. Ba2 {+0.03/37 5} Bd8 {-0.01/61 0.3} 33. Bc4
{+0.03/35 5} Bc7 {-0.01/61 0.3} 34. Be6 {+0.03/33 5} Bd6 {-0.01/61 0.3} 35.
Bf7 {+0.03/31 5} Bf8 {-0.01/60 0.2} 36. Ba2 {+0.03/29 5} Be7 {-0.01/60 0.3}
37. Ke2 {+0.03/27 5} Kc6 {-0.01/60 0.2} 38. Bd5+ {+0.03/24 5} Kd6
{-0.01/61 0.3} 39. Kf2 {+0.03/23 5} Kc5 {-0.01/61 0.2} 40. Kf3 {+0.03/21 4}
Bd6 {-0.01/61 0.2} 41. Ba8 {+0.03/19 4} Bc7 {-0.01/60 0.7} 42. Bb7
{+0.02/19 4} Bb8 {-0.01/60 0.2} 43. Ke2 {+0.00/15 14} Bd6 {-0.01/61 0.2}
44. Ba8 {+0.00/16 4} Be7 {-0.01/60 0.2} 45. Kf2 {+0.00/18 3} Bd8
{-0.01/60 1.8} 46. Ke1 {+0.00/18 4} Ba5 {-0.01/60 0.2} 47. Ke2 {+0.00/24 3}
Bc7 {-0.01/61 0.2} 48. Kf3 {+0.00/32 3} Bd6 {-0.01/60 0.2} 49. Bd5
{+0.00/33 5} Bc7 {-0.01/61 0.3} 50. Ke2 {+0.00/42 1.9} Ba5 {-0.01/61 0.2}
{Drawn by 50-move rule} 1/2-1/2


http://www.edcollins.com/images/plies.png

Hopefully this is enough information to figure out what might be wrong. (Shouldn't my Adjudications box, by default, say 50-move rule and 3-fold repeats?)
- Ed

[EdCollins]

I'm looking at an old winboard.ini file that I have and I see

/ruleMoves=50
/repeatsToDraw=3

So, it looks like those are the defaults. Someone I must have changed mine. (?)

If I changed my ruleMoves from 51 to 50, I think it would still be off by 1. Maybe the final display isn't getting updated that last, final time, once the game ends?

[EdCollins]

Interesting. I just found another old winboard.ini file.

This one has:

/ruleMoves=51
/repeatsToDraw=6

6? I would never change that to 6. In fact, I still I don't remember ever changing either of these fields ever, for any reason. I would have no reason to.

[matematiko]

Interesting. I just found another old winboard.ini file.

This one has:

/ruleMoves=51
/repeatsToDraw=6

6? I would never change that to 6. In fact, I still I don't remember ever changing either of these fields ever, for any reason. I would have no reason to.

This is interesting, I do not know the story behind, but I inherit a similar problem with the ICS emulator I am maintaining now, the 50 (full moves) counter (100 half moves) seemed not to agreed with Yahoo, I am not saying Yahoo was right or wrong, I am just saying that for some reason I have to bumped this half moves number to 101 instead of 100 and everything was fine ever after....well kinda, please read.

Another problem, Threefold repetition is also a misunderstood concept by many, most people thinks that going back and forth with the same move for each player three times is the only threefold repetition, this is no correct. If a board position (including the specific player's turn) repeats three times, not necessarily in straight order, this is also a three fold "repetition" and is an automatic draw. By the way, how does WinBoard stand in this regard?

I know the above is known by most, but it is obviously also unknown by some.

Regards,

Edit, I was wrong...in this kind of three fold repetition there is not supposed to be such a thing as "Automatic Draw", a player has to "call" and "prove" with notes the three fold....whether or not or why some GUI's do the claim automatically is beyond the scope of my comment.

[EdCollins]

Okay, now that I edit the "Apply x-move rule" to 50, I think all is okay.

I just watched an actual complete game between Spike and Zappa Mexico.

After Spike, as White, made its 135th move, the number of plies to draw said "2" and I made a screen capture.

And two moves later, the game was adjudicated as a draw.

So in an actual game that all seemed to work out okay.

When I get a chance, I will try another test with a position that is set up. But for now I don't think anything is amiss. Sorry for initial report.

[EdCollins]

Confirmed. All is okay, even when starting from a setup position.

http://www.edcollins.com/images/plies-03.png

The only thing I see different is this time the main window said {Xboard adjudication: 50-move rule}.

The first time the main window said {Drawn by 50-move rule}.

[H.G.Muller]

The number of moves after which WinBoard adjudicates draw is user configurable. According to FIDE rules this is no automatic draw, but must be claimed. In comp-comp games you don't want non-claiming engines to play on forever, so you usually want to adjudicate at some point,which can be well after 50. Also, in other variants, such as XQ, one sometimes uses a 30-move rule, and on big-board games one would definitely need a larger number. To save testing time I sometimes set smaller limits.

When I originally added this feature, I made the compiled-in defaults 51 moves and 6 repetitions, so that the engines could still get the opportunity to claim themselves (thereby testing their correctness), rather than becoming completely dependent on GUI adjudication. When "Verfy Engine Claims" is on, claims after 50 or more moves, or after 3 repetitions, are aways accepted as legal.

When the limits are set to 50 and 3, WinBoard will adjudicate before the engines get a chance to claim. You can see the difference in the result message, as you noticed. When WinBoard adudicates, it will say "XBoard adjudication: ...", but when an engine makes a legal claim, it will just print the message the engine sent in its result claim. (And on a false claim the game will be forfeited, with a "False draw claim ..." message.)

The "ply to draw" feature measures the distance to WinBoard's adjudication. I agree this could be a bit confusing if it is not set for a standard value. Referring it to a hard 50 would be confusing for variants that use another number, though. I guess the alternative would be not to print "ply to draw", but count forward as "reversible ply". The user presumably knows the value at which the game can be claimed (like 100 in FIDE Chess)or to which he set it for adudication.

To Matematiko:

WinBoard compares every new position with all previous positions in the game with the same side to move, not only for piece placement, but also for e.p. and castling rights to detect repetitions.

[matematiko]

Mr. Muller,

Thanks for the confirmation and for adding en passant and castling.

Have a nice weekend.

[EdCollins]

Okay, that clears everything up, including why I found my 51 and 6 values and why I saw the two different messages.

The "ply to draw" feature measures the distance to WinBoard's adjudication. I agree this could be a bit confusing if it is not set for a standard value. Referring it to a hard 50 would be confusing for variants that use another number, though. I guess the alternative would be not to print "ply to draw", but count forward as "reversible ply". The user presumably knows the value at which the game can be claimed (like 100 in FIDE Chess)or to which he set it for adjudication.

Yea, that might be ideal. But what would be the display? "# of moves since last capture or pawn move: xx" is a little long. (But it's not too bad.) Or maybe just "Draw Move Counter: xx". And maybe just start displaying it from move 35 or 40 onward. I wouldn't suspect anyone would have a need or desire to see the count any earlier than that.

[H.G.Muller]

OK, the version I uploaded now combines it all, and corresponds to the latest sources in hgm.nubati.net hgmaster branch.(Which now also works for XBoard.)

*) Prints the value of the 50-move counter in the Engine-Output title, rather than the plies to go.
*) Prints score/depth and time in the Eval Graph title.
*) The Eval Graph now responds to single clicking also in WB.
*) To reduce confusion when used with evalZoom > 1, it prints more labels on the score axis of the Eval Graph, when there is room for it.
*) It supports the new options:

/absoluteAnalysisScores true|false Forces white POV for scores in Engine-Output window for analysis mode only.
/scoreWhite true|false Forces white POV for scores in Engine-Output window in all modes.
/evalZoom N blows up the range {-1,+1} in the Eval Graph by a factor N. (Default: 1)
/evalThreshold N suppresses histogram bars in the Eval Graph with score below N centi-Pawn. (Default: 25)
/fSAN, /sSAN converts PV of mentioned engine to SAN before printing. (Volatile. Default: no conversion)

[EdCollins]

Everything looks good.

It might just be "noise" but I think I will like seeing a bar even when the evaluation is low.
I think I'm gonna set my variables to /evalZoom=3 and /evalThreshold=0 !