ChessGUI 0.245f is available

[Edmund]

Well, I would say that when an engine does not hover around +1.00 when presented with a position where it is a Pawn ahead without any compensation for the opponent (such as classical Pawn odds, deleting f2 or f7 from the opening position), but says +0.50 or +2.00 instead, it is clearly wrong. If engines systematically differ a factor between their score, it should not be very difficult to find out which one is miscalibrated, using such a test.

well, that would be a completely new standard you are defining here. You might also want to add a certain resource constraint, e.g. an engine should return +1 after 10.000.000 nodes searched when presented the opening position with f7 missing.

if this would have been written in the specifications instead of the ambiguous "centipawn" we wouldn't face this discussion here.

However you must admit that this definition appears pretty arbitrary.
For comparison you might find the statistics interesting in this thread:http://www.tcec-chess.net/viewtopic.php?f=14&t=119, where the average evaluation of removing any one pawn is compared.


Sune Fisher and Pradu Kannan conducted a different scaling study. http://chessprogramming.wikispaces.com/ ... 2C+and+ELO
They assumed the following piece value scaling (P=1, N=4, B=4.1, R=6, Q=12) and found that counting positions where a certain piececonfiguration remained for at least 5 plies, material score correpsonded to win probabability: 1 ELO advantage = 1 centipawn. So scores can then be interpreted in the way: how much more elo would I need on average to draw.

According to the Houdini website, scores are scaled according to winning probabilities, but again a different scale. 100 centipawns = 80% winning probability = 240 Elo. (chance of winning the game against an equal opponent at blitz time control)

I think Fishers and Kannans scaling would allow for the most intuitive score interpretation should there ever be a clear standard defined.

[casaschi]

The other feature that would be useful would be the evaluation given in brackets after each move in the displayed pgn.

It would be much better to have an agreed standard to display engine info into the PGN.

...

What Graham is talking about does not involve, nor affect PGN files.
It is stuff that is generated and spit only on screen.

Well, I can't read people's mind, but he talked about the displayed pgn.

If it's PGN then it should follow the syntax.

If it's not PGN then why calling it pgn and also why bother with the curly brackets? You could just show a game text with bold moves and everything else in a lighter color; no need of brackets... unless you think your user might cut&paste that into a file or another program... then again it would be nice that cut&paste to be PGN compliant.

[casaschi]

What Graham is talking about does not involve, nor affect PGN files.
It is stuff that is generated and spit only on screen.

Indeed, I think this is what he means. But isn't that what most GUIs already (optionally) do? E.g. in the WinBoard Move History window (so not the PGN!) it looks like this:

Code: Select all

1. Kd2 {+0.20/15} Sd8 2. a4 {+0.08/17} b6 3. Sc2 {+0.16/16} b5 4. Sf2 {+0.28/17} Gg8 5. h4 {+0.24/16} g6 6. h5 {+0.28/15} Sf8 7. h6 {+0.44/16} hxh6 8. Rxh6 {+0.40/15} Kf9 9. Rh2 {+0.80/13} P@h7 10. Gde2 {+0.88/13} e6 11. P@h6 {+1.52/14} hxh6 12. Rxh6 {+1.24/13} P@h7 13. Rh4 {+1.04/14} Sde7 14. Rg4 {+1.00/13} Ge8 15. a5 {+0.68/15} Sd6 16. i4 {+0.96/14} c6 17. Ni3 {+1.04/13} Sc5 18. Ba3 {+0.84/13} Sg7 19. Re4 {+0.60/13} e5 20. Rxe5 {+1.20/14} b4 21. bxb4 {+0.84/14} Sf6 22. Rh5 {-400.00/15} Sg5 23. Sb3 {+1.36/13} a6 24. axa6 {+1.72/14} Lxa6 25. P@a5 {+0.32/14} Lxa5 26. P@a4 {-0.36/14} P@b2 27. Bxb2 {-400.00/15} Sxb4 28. P@b7 {-2.60/14} Rxb7 29. Sxb4 {-3.32/13} Rxb4 30. S@c1 {-4.40/12} P@a2 31. Lxa2 {-7.20/11} Rb3+ 32. axa5 {-7.84/11} +Rxa2 33. L@e4 {-9.84/11} P@e5 34. Lxe5 {-15.16/11} Bxe5 35. P@b3 {-22.68/12} +Rxb1 36. e4 {-18.24/10} N@c4 37. cxc4 {-21.32/12} Bxb2+ 38. Sxb2 {-21.80/11} +Rxb2 39. Ke3 {-400.00/11} B@a7 40. B@d4 {-21.88/9} S@c3 41. f4 {-22.96/9} Sxd4+ 42. dxd4 {-400.00/10} B@c1 43. Kf3 {-23.24/9} Bxf4+ 44. Kg2 {+0.00/1} P@e3 45. S@f3 {-25.52/9} exe2+ 46. Gxe2 {-28.28/9} Bxd4 47. P@d2 {-27.80/9} Bxf2+ 48. Gxf2 {-22.76/9} +Bxf3 49. Gxf3 {-29.92/9} +Rxd2 50. B@f2 {-400.00/10} S@h3 51. Rxh3 {-399.68/9} S@f1 52. Kxf1 {-399.72/12} S@e2 53. Kg1 {-399.76/12} G@g2 54. Kxg2 {+0.00/1} Sxf3+ 55. Kh1 {-399.84/8} G@g1 56. Ki2 {-399.88/6} +Rxf2 57. B@g2 {-399.92/4} +Rxg2 58. S@h2 {-399.96/2} +Rh1#

The stuff in braces can be displayed in a lighter font.

and, if it's not PGN, without the brackets...

[hgm]

Indeed, I cut and paste that very often, and consider it a big advantage that it is PGN compatible. Hence WinBoard uses the braces, rather than unprotected numbers in another font. I wouldn claim it is PGN (no tags...), but at least a liberal PGN parser should not choke on it.

[casaschi]

The problem is that I consider this absolutely awful. I would rather die than use that

Well, that end the discussion then.

So yes, I agree that it would be preferable to have a standard. But I don't think it should just be any standard, but rather a standard everyone could agree on.

The first format you give is actually extremely easy to parse, provided there is an agreed-upon ordering of the numbers.

That is all good and well, but only for your own small application.
What if instead of just a match between engines you would like for instance to annotate a human game using an engine; and you also want to mix engine notes and human annotations. The general format of the proposed extension allows for something like that. Just writing numbers without any label or context does not fit the job, especially if every other application defines its own order. If you define a tag with a label you solve the problem whatever else someone else might add.

But again, if you only care about your own application and you dont expect anyone else to read your files, then you are good.

[casaschi]

Indeed, I cut and paste that very often, and consider it a big advantage that it is PGN compatible. Hence WinBoard uses the braces, rather than unprotected numbers in another font. I wouldn claim it is PGN (no tags...), but at least a liberal PGN parser should not choke on it.

So you should title that the "almost pgn but not quite" window.
Or better, remove the curly brackets and have a "copy PGN" button/menu.
Doing things half-way is not a proper choice to me.

[hgm]

well, that would be a completely new standard you are defining here. You might also want to add a certain resource constraint, e.g. an engine should return +1 after 10.000.000 nodes searched when presented the opening position with f7 missing.

I don't understand why you consider that a 'completely new standard'. Isn't this exactly what 100 centiPawn means: being a Pawn ahead without compensation? Meaning f2/f7, because all the other Pawns give some advantage in terms of increasing mobility of a piece and facilitating development.

The only risk I see is that programs might have a relatively light Pawn, compared to all other pieces. So perhaps one should also look at the score for Knight odds. (But then at low depth only, because advantage this big tend to grow in time, while Pawn advantages are hard to cash on before you can force passers, etc.)

From the link you gave it seems to work extremely well, btw: The Stockfish score for deleting f7 is reported as 1.85, i.e. 1.85 times too large by my standard. And Matthias experiences all Stockfish scores as being 1.9 times too large. I am not sure what he based this on.

[hgm]

So you should title that the "almost pgn but not quite" window.

It is called a Move History window, because it contains the moves. For the PGN tags there is another window (usually closed, as looking at the same tags for the entire duration of a game is rather boring).

Or better, remove the curly brackets and have a "copy PGN" button/menu.
Doing things half-way is not a proper choice to me.

Not sure what is done 'half'. WinBoard already has a 'Copy Game' menu item, which transfers PGN to the clipboard. I use the Move History window for copying when I want to select part of the game. A button could not do that.

The display of the scores is controlled by an option setting ('extra info in move history').

I don't see much harm in having the brackets. You could save a little bit of space by omitting them, but that is hardly worth it.

What if instead of just a match between engines you would like for instance to annotate a human game using an engine; and you also want to mix engine notes and human annotations.

I see no problems there. For one, the PGN standard allows multiple comments in a row. But WinBoard prefers to merge score/depth annotations with other comments. I have never yet encountered a case where there was any confusion. If a comment starts with "{+n.nn/N" it is always a score/depth annotation, which is then extracted, and everything that follows it which it doesn't understand is treated as a text comment.

The general format of the proposed extension allows for something like that. Just writing numbers without any label or context does not fit the job, especially if every other application defines its own order. If you define a tag with a label you solve the problem whatever else someone else might add.

Not if every other application would define its own labels... This seems a non-argument. You either follow a standard, or you don't, and standards without labels can be just as unambiguous as standard with labels. In practice a + or - after the opening { of a comment are pretty unique indicators that the first part of the comment is score/depth. Especially in combination with the slash. The use of labels and separate brackets and % sign seems excessively verbose.

Everyone adding his own stuff independently is exactly what you wouldn't want for a standard. Because it would not remain 'standard' very long, then.

But again, if you only care about your own application and you dont expect anyone else to read your files, then you are good.

I don't think WinBoard has any problems reading the score/depth info in files generated by Arena (and vice versa). I never heared any complaints from SCID vs PC either (but perhaps it doesn't use score/depth info at all).

[Graham Banks]

What Graham is talking about does not involve, nor affect PGN files.
It is stuff that is generated and spit only on screen.

Indeed, I think this is what he means. But isn't that what most GUIs already (optionally) do? E.g. in the WinBoard Move History window (so not the PGN!) it looks like this:

Code: Select all

1. Kd2 {+0.20/15} Sd8 2. a4 {+0.08/17} b6 3. Sc2 {+0.16/16} b5 4. Sf2 {+0.28/17} Gg8 5. h4 {+0.24/16} g6 6. h5 {+0.28/15} Sf8 7. h6 {+0.44/16} hxh6 8. Rxh6 {+0.40/15} Kf9 9. Rh2 {+0.80/13} P@h7 10. Gde2 {+0.88/13} e6 11. P@h6 {+1.52/14} hxh6 12. Rxh6 {+1.24/13} P@h7 13. Rh4 {+1.04/14} Sde7 14. Rg4 {+1.00/13} Ge8 15. a5 {+0.68/15} Sd6 16. i4 {+0.96/14} c6 17. Ni3 {+1.04/13} Sc5 18. Ba3 {+0.84/13} Sg7 19. Re4 {+0.60/13} e5 20. Rxe5 {+1.20/14} b4 21. bxb4 {+0.84/14} Sf6 22. Rh5 {-400.00/15} Sg5 23. Sb3 {+1.36/13} a6 24. axa6 {+1.72/14} Lxa6 25. P@a5 {+0.32/14} Lxa5 26. P@a4 {-0.36/14} P@b2 27. Bxb2 {-400.00/15} Sxb4 28. P@b7 {-2.60/14} Rxb7 29. Sxb4 {-3.32/13} Rxb4 30. S@c1 {-4.40/12} P@a2 31. Lxa2 {-7.20/11} Rb3+ 32. axa5 {-7.84/11} +Rxa2 33. L@e4 {-9.84/11} P@e5 34. Lxe5 {-15.16/11} Bxe5 35. P@b3 {-22.68/12} +Rxb1 36. e4 {-18.24/10} N@c4 37. cxc4 {-21.32/12} Bxb2+ 38. Sxb2 {-21.80/11} +Rxb2 39. Ke3 {-400.00/11} B@a7 40. B@d4 {-21.88/9} S@c3 41. f4 {-22.96/9} Sxd4+ 42. dxd4 {-400.00/10} B@c1 43. Kf3 {-23.24/9} Bxf4+ 44. Kg2 {+0.00/1} P@e3 45. S@f3 {-25.52/9} exe2+ 46. Gxe2 {-28.28/9} Bxd4 47. P@d2 {-27.80/9} Bxf2+ 48. Gxf2 {-22.76/9} +Bxf3 49. Gxf3 {-29.92/9} +Rxd2 50. B@f2 {-400.00/10} S@h3 51. Rxh3 {-399.68/9} S@f1 52. Kxf1 {-399.72/12} S@e2 53. Kg1 {-399.76/12} G@g2 54. Kxg2 {+0.00/1} Sxf3+ 55. Kh1 {-399.84/8} G@g1 56. Ki2 {-399.88/6} +Rxf2 57. B@g2 {-399.92/4} +Rxg2 58. S@h2 {-399.96/2} +Rh1#

The stuff in braces can be displayed in a lighter font.

and, if it's not PGN, without the brackets...

I was referring to this:



I am perfectly happy with the pgn text output options that Matthias provides. I opt for this output:

[Event "44th Amateur D3"]
[Site "ChessGUI4"]
[Date "2013.12.17"]
[Round "33.1"]
[White "ProDeo 1.86"]
[Black "iCE 1.0 64-bit"]
[Result "1/2-1/2"]
[ECO "B51"]
[PlyCount "114"]
[EventDate "2013.??.??"]
[TimeControl "40/1500:40/1500:40/1500"]

{i5 Quad} 1. e4 {[%eval 0,1] [%emt 0:00:00]} c5 {[%eval 0,1] [%emt 0:00:00]} 2.
Nf3 {[%eval 0,1] [%emt 0:00:00]} d6 {[%eval 0,1] [%emt 0:00:00]} 3. Bb5+ {
[%eval 0,1] [%emt 0:00:00]} Nd7 {[%eval 0,1] [%emt 0:00:00]} 4. d4 {
[%eval 0,1] [%emt 0:00:00]} cxd4 {[%eval 0,1] [%emt 0:00:00]} 5. Qxd4 {
[%eval 0,1] [%emt 0:00:00]} a6 {[%eval 0,1] [%emt 0:00:00]} 6. Bxd7+ {
[%eval 0,1] [%emt 0:00:00]} Bxd7 {[%eval 0,1] [%emt 0:00:00]} 7. c4 {
[%eval 0,1] [%emt 0:00:00]} Bg4 {[%eval 0,1] [%emt 0:00:00]} 8. Nc3 {
[%eval 0,1] [%emt 0:00:00]} Bxf3 {[%eval 0,1] [%emt 0:00:00]} 9. gxf3 {
[%eval 10,13] [%emt 0:00:06]} e6 {(e6) [%eval 7,19] [%emt 0:00:46]} 10. b3 {
(Bd2) [%eval 5,15] [%emt 0:00:53]} Be7 {(Be7) [%eval 11,18] [%emt 0:00:46]} 11.
Bb2 {(Bb2) [%eval 0,16] [%emt 0:00:48]} Bf6 {(Bf6) [%eval 6,19] [%emt 0:00:46]}
12. Qe3 {(Qe3) [%eval -1,16] [%emt 0:00:53]} Ne7 {
(Qa5) [%eval 4,19] [%emt 0:00:46]} 13. Rd1 {(f4) [%eval -1,15] [%emt 0:00:39]}
O-O {(O-O) [%eval 49,18] [%emt 0:00:48]} 14. f4 {
(O-O) [%eval 0,15] [%emt 0:01:20]} Qc7 {(Qb8) [%eval 61,17] [%emt 0:00:46]} 15.
O-O {(Rg1) [%eval -1,15] [%emt 0:01:25]} Rfb8 {
(Rac8) [%eval 43,18] [%emt 0:01:34]} 16. Ba3 {
(Rd2) [%eval 24,16] [%emt 0:00:51]} Rd8 {(Rd8) [%eval 36,18] [%emt 0:00:44]}
17. Rd2 {(Na4) [%eval 20,16] [%emt 0:00:43]} Ng6 {
(b5) [%eval 36,18] [%emt 0:00:44]} 18. Ne2 {(f5) [%eval 14,16] [%emt 0:01:04]}
b5 {(b5) [%eval 28,18] [%emt 0:00:44]} 19. Rc1 {
(cxb5) [%eval 17,16] [%emt 0:00:30]} Nh4 {(bxc4) [%eval 61,18] [%emt 0:00:44]}
20. Bb4 {(Bb4) [%eval 5,15] [%emt 0:00:40]} Rac8 {
(Rac8) [%eval 60,19] [%emt 0:00:44]} 21. Rdd1 {
(Rdd1) [%eval 0,15] [%emt 0:00:36]} Qb8 {(Qb8) [%eval 75,19] [%emt 0:00:37]}
22. Ba5 {(Ba5) [%eval 0,16] [%emt 0:00:37]} Re8 {
(Re8) [%eval 60,19] [%emt 0:00:50]} 23. Bb4 {(Qd3) [%eval 0,16] [%emt 0:00:35]}
Be7 {(Red8) [%eval 74,19] [%emt 0:00:45]} 24. a3 {
(c5) [%eval 0,15] [%emt 0:00:32]} bxc4 {(bxc4) [%eval 82,18] [%emt 0:00:45]}
25. bxc4 {(bxc4) [%eval 0,14] [%emt 0:00:51]} h6 {
(Qc7) [%eval 86,17] [%emt 0:00:45]} 26. Kh1 {(Kh1) [%eval 0,14] [%emt 0:01:00]}
Qb7 {(Qb7) [%eval 80,17] [%emt 0:00:45]} 27. Kg1 {
(Rg1) [%eval 0,15] [%emt 0:00:43]} Red8 {(Qb8) [%eval 95,18] [%emt 0:00:45]}
28. Kh1 {(Nd4) [%eval -3,14] [%emt 0:01:20]} Rd7 {
(Rd7) [%eval 87,17] [%emt 0:00:46]} 29. f3 {(Qd3) [%eval -7,14] [%emt 0:00:43]}
Qc7 {(Qa8) [%eval 85,16] [%emt 0:00:43]} 30. Bc3 {
(Bc3) [%eval 0,15] [%emt 0:00:54]} Bf8 {(Qc5) [%eval 60,18] [%emt 0:02:04]} 31.
Be1 {(Rg1) [%eval 0,14] [%emt 0:00:31]} Ng6 {(Be7) [%eval 70,18] [%emt 0:00:37]
} 32. Bb4 {(Bg3) [%eval 0,14] [%emt 0:00:29]} a5 {
(Nh4) [%eval 74,17] [%emt 0:01:04]} 33. Bd2 {(Bd2) [%eval -3,16] [%emt 0:00:32]
} Rb8 {(Qc5) [%eval 70,17] [%emt 0:01:05]} 34. Bc3 {
(Qg1) [%eval 5,15] [%emt 0:00:56]} Rdd8 {(a4) [%eval 64,15] [%emt 0:00:36]} 35.
Qd2 {(Rg1) [%eval 18,16] [%emt 0:00:48]} Ra8 {
(Qc5) [%eval 52,17] [%emt 0:00:28]} 36. Rg1 {(Rg1) [%eval 12,14] [%emt 0:00:48]
} Rdc8 {(Kh7) [%eval 21,17] [%emt 0:00:34]} 37. f5 {
(Bxg7) [%eval 22,15] [%emt 0:00:34]} exf5 {(exf5) [%eval 25,18] [%emt 0:00:26]}
38. exf5 {(exf5) [%eval 33,13] [%emt 0:00:06]} Ne5 {
(Ne5) [%eval 13,18] [%emt 0:00:19]} 39. Qxh6 {
(Qxh6) [%eval 41,15] [%emt 0:00:27]} Qb7 {(Qb7) [%eval -19,17] [%emt 0:00:14]}
40. Rcf1 {(Rg3) [%eval 41,17] [%emt 0:01:10]} Rxc4 {
(Rxc4) [%eval 69,18] [%emt 0:00:44]} 41. Bxe5 {
(Bxe5) [%eval 55,16] [%emt 0:00:24]} dxe5 {(dxe5) [%eval 48,20] [%emt 0:00:37]}
42. f6 {(f6) [%eval 48,18] [%emt 0:00:42]} g6 {
(g6) [%eval 93,20] [%emt 0:00:37]} 43. Rxg6+ {
(Rxg6) [%eval 56,17] [%emt 0:01:01]} fxg6 {(fxg6) [%eval 75,20] [%emt 0:00:37]}
44. Qxg6+ {(Qxg6) [%eval 84,14] [%emt 0:00:06]} Bg7 {
(Bg7) [%eval 75,19] [%emt 0:00:37]} 45. fxg7 {
(fxg7) [%eval 58,15] [%emt 0:00:17]} Rc7 {(Rh4) [%eval 36,19] [%emt 0:00:37]}
46. Qe6+ {(Qe6) [%eval 53,17] [%emt 0:00:32]} Rf7 {
(Rf7) [%eval 39,18] [%emt 0:00:39]} 47. Ng3 {(Ng3) [%eval 52,17] [%emt 0:00:28]
} Qa6 {(Qa6) [%eval 34,17] [%emt 0:00:37]} 48. Qxe5 {
(Qxe5) [%eval 39,17] [%emt 0:01:07]} Qd3 {(Rd8) [%eval 74,16] [%emt 0:00:35]}
49. f4 {(f4) [%eval 37,16] [%emt 0:00:38]} Rxg7 {
(Rxg7) [%eval 72,16] [%emt 0:00:31]} 50. f5 {(Re1) [%eval 24,15] [%emt 0:00:29]
} Rd8 {(Rd8) [%eval 120,16] [%emt 0:00:37]} 51. f6 {
(Qe6) [%eval 24,14] [%emt 0:00:32]} Rh7 {(Rh7) [%eval 141,16] [%emt 0:00:37]}
52. Qxa5 {(Qf4) [%eval 17,14] [%emt 0:00:41]} Qd2 {
(Qd2) [%eval 187,18] [%emt 0:01:03]} 53. f7+ {(f7) [%eval 0,16] [%emt 0:00:59]}
Rxf7 {(Rxf7) [%eval 173,18] [%emt 0:00:36]} 54. Qxd2 {
(Qh5) [%eval 0,17] [%emt 0:00:47]} Rxd2 {(Rxd2) [%eval 213,19] [%emt 0:00:34]}
55. Rxf7 {(Kg1) [%eval 0,20] [%emt 0:00:41]} Kxf7 {
(Kxf7) [%eval 165,20] [%emt 0:00:36]} 56. a4 {(h4) [%eval 0,20] [%emt 0:00:39]}
Ra2 {(Ra2) [%eval 131,20] [%emt 0:00:46]} 57. a5 {
(h4) [%eval 0,20] [%emt 0:00:30]} Rxa5 {(Rxa5) [%eval 88,20] [%emt 0:00:31]}
1/2-1/2

[casaschi]

The first format you give is actually extremely easy to parse, provided there is an agreed-upon ordering of the numbers.

On a side note, the proposed comment tag scheme is pretty much following the same principle used for the PGN header. If an agreed-upon ordering of the data had been considered good enough, then a PGN game would look like this

Code: Select all

World Championship 2013, Chennai (India), Nov 7th 2013
Carlsen (2870, GM) - Anand (2775, GM)  draw

1. Nf3 d5 2. g3 g6 3. Bg2 Bg7 4. d4 c6 5. O-O Nf6
6. b3 O-O 7. Bb2 Bf5 8. c4 Nbd7 9. Nc3 dxc4 10. bxc4 Nb6
11. c5 Nc4 12. Bc1 Nd5 13. Qb3 Na5 14. Qa3 Nc4 15. Qb3 Na5
16. Qa3 Nc4 1/2-1/2

instead of

Code: Select all

[Event "World Championship 2013"]
[Site "Chennai IND"]
[Date "2013.11.07"]
[Round "1"]
[White "Carlsen"]
[Black "Anand"]
[Result "1/2-1/2"]
[WhiteElo "2870"]
[BlackElo "2775"]
[WhiteTitle "GM"]
[BlackTitle "GM"]
[ECO "A07"]

1. Nf3 d5 2. g3 g6 3. Bg2 Bg7 4. d4 c6 5. O-O Nf6
6. b3 O-O 7. Bb2 Bf5 8. c4 Nbd7 9. Nc3 dxc4 10. bxc4 Nb6
11. c5 Nc4 12. Bc1 Nd5 13. Qb3 Na5 14. Qa3 Nc4 15. Qb3 Na5
16. Qa3 Nc4 1/2-1/2