Buggy pgn output from a CEGT & CCRL gui

[Norm Pollock]

Some gui(s) used by both CCRL and CEGT produces pgns that violate an important pgn principle. This gui assumes there is ALWAYS ambiguity when 2 of the same pieces can move to the same square. However, if one of these pieces cannot legally move to the square, then the gui does not notice that there is NO ambiguity. For example, if 2 white knights can move to e5, but 1 of the white knights is pinned to the white King by a black bishop, then there is no ambiguity.

This type of situation has occurred hundreds of times in the pgn downloads of CCRL and CEGT, and will keep on occurring unless corrected.

I am just interested in identifying the gui(s) that do this. I have software that can correct the situation, but I do want to know which gui is doing this so that perhaps they will correct their bug.

Here are 2 examples, the first from CEGT, and the second from CCRL. In the first, I removed the comments. These games are very recent.

I have put in a comment at the top of each game that notes the move whose notation I am questioning.

Code: Select all

{white move 9: Nge2 should be Ne2}
[Event "Rybka231g01"]
[Site "?"]
[Date "2007.04.10"]
[Round "12.3"]
[White "Shredder 10"]
[Black "Rybka 2.3.1 w32 1CPU"]
[Result "1/2-1/2"]
[ECO "E20"]
[WhiteElo "2812"]
[BlackElo "2950"]
[Annotator "0.58;0.06"]
[PlyCount "205"]
[EventDate "2007.04.07"]
[EventType "simul"]
[Source "Buczyna"]
[TimeControl "40/1080:40/1080:600+10"]

1. d4 Nf6 2. c4 e6 3. Nc3 Bb4 4. f3 c5 5. d5 b5 6. e4 bxc4 7. Bxc4 Ba6 
8. Bxa6 Nxa6 9. Nge2 c4 10. O-O Qb6+ 11. Kh1 O-O 12. Bg5 Rab8 13. Bxf6 gxf6 
14. Ng3 Be7 15. Na4 Qb5 16. f4 Kh8 17. f5 exd5 18. exd5 Bd6 19. Ne4 Be5 
20. Rb1 Nb4 21. Nac3 Qb6 22. Qd2 Qd4 23. Qe2 Rbc8 24. Rbd1 Qb6 25. Rf3 Rg8 
26. b3 Nd3 27. d6 Bxc3 28. Nxc3 Ne5 29. Nd5 Qxd6 30. Rf4 Nd3 31. Rxc4 Qxd5 
32. Rxd3 Rce8 33. Rxd5 Rxe2 34. g3 Rxa2 35. Rxd7 Re8 36. Rd1 a5 37. b4 a4 
38. b5 Kg7 39. Rg4+ Kf8 40. Rb4 Ree2 41. h4 Rh2+ 42. Kg1 Rag2+ 43. Kf1 Rb2 
44. Rxb2 Rxb2 45. Ra1 Rxb5 46. Rxa4 Rxf5+ 47. Ke2 h6 48. g4 Rc5 49. Ke3 Kg7 
50. Kf4 Rc1 51. Ra5 Rf1+ 52. Ke4 Rh1 53. h5 Re1+ 54. Kf5 Re7 55. Rd5 Rb7 
56. Kf4 Ra7 57. Ke4 Rc7 58. Kf5 Rc2 59. Ke4 Re2+ 60. Kf4 Re1 61. Rb5 Rf1+ 
62. Ke4 Rc1 63. Kf4 Ra1 64. Kg3 Ra4 65. Kf3 Ra3+ 66. Ke4 Ra1 67. Kf3 Rd1 
68. Ke4 Rd2 69. Rc5 Re2+ 70. Kf4 Re7 71. Ra5 Rc7 72. Rd5 Rc4+ 73. Kf3 Rc3+ 
74. Ke4 Rc6 75. Kf4 Rc8 76. Ke4 Rc1 77. Ke3 Re1+ 78. Kf4 Re8 79. Ra5 Rb8 
80. Kf5 Rd8 81. Ke4 Rd6 82. Kf4 Rd4+ 83. Kf3 Rd3+ 84. Kf4 Rb3 85. Rc5 Rb4+ 
86. Kf3 Rb8 87. Kf4 Rb2 88. Ke4 Rb1 89. Kf5 Rf1+ 90. Ke4 Re1+ 91. Kf4 Rd1 
92. Ra5 Rd2 93. Ke4 Re2+ 94. Kf5 Rg2 95. Rb5 Ra2 96. Ke4 Kf8 97. Kf5 Rf2+ 
98. Ke4 Rd2 99. Rc5 Rd6 100. Kf5 Kg7 101. Rc7 Rd4 102. Rb7 Rd1 103. Rd7 
1/2-1/2 

Code: Select all

{black move 34 ... Rcc7 should be Rc7}
[Event "CCRL 40/40"]
[Site "CCRL"]
[Date "2007.04.08"]
[Round "?"]
[White "Adam 3.1"]
[Black "Prophet 2.0"]
[Result "1-0"]
[PlyCount "197"]

1. e4 c5 2. Nf3 d6 3. d4 cxd4 4. Nxd4 Nf6 5. Nc3 a6 6. Be3 e6 7. Bd3 b5 8. O-O
Bb7 9. a3 Be7 10. f4 Nbd7 11. Qf3 Qc7 12. Rae1 Nc5 13. Rc1 d5 14. e5 Nfe4 15.
Nd1 O-O 16. b4 Na4 17. Nb3 Rad8 18. Re1 Rc8 19. Na5 Ba8 20. Nf2 Nac3 21. Bd4 f5
22. Qe3 Bh4 23. g3 Be7 24. Nd1 Na4 25. h3 Kf7 26. c3 Ke8 27. Bc2 g5 28. Bxa4
bxa4 29. Kh2 Qb8 30. Qe2 gxf4 31. gxf4 Qb5 32. Qh5+ Rf7 33. Rg1 Bf8 34. Nb2
Rcc7 35. c4 dxc4 36. Naxc4 Qd7 37. Rgd1 Rc8 38. Nb6 Rxc1 39. Rxc1 Qd8 40. Rc8
Qxc8 41. Nxc8 Bb7 42. Nb6 Nd2 43. Bc3 Nf1+ 44. Kg1 Ng3 45. Qd1 Rg7 46. Kh2 Bc6
47. Bd4 Be7 48. N2c4 Bh4 49. Ne3 Ne4 50. Qh5+ Rg6 51. Qxh4 Nd2 52. Qf2 Nf3+ 53.
Qxf3 Bxf3 54. Nxa4 h6 55. Bb6 Ke7 56. Bc5+ Ke8 57. Bd6 Kf7 58. Nc5 Be2 59. a4
Rg8 60. Bc7 Ke7 61. Bb6 Rg6 62. Nb3 Kd7 63. Bd4 Rg8 64. Nc5+ Ke7 65. Ba1 Rg6
66. Bc3 Rg8 67. Be1 Kf7 68. Bd2 Rd8 69. Bc3 Rc8 70. a5 Rg8 71. Be1 Bb5 72. Bh4
Be2 73. Bf2 Bb5 74. h4 Ke7 75. h5 Kf7 76. Bh4 Be2 77. Bf6 Rb8 78. Nc2 Rb5 79.
Nxe6 Kxe6 80. Nd4+ Kd5 81. Nxe2 Rxb4 82. Kg3 Rb8 83. Kf2 Rb7 84. Nc3+ Ke6 85.
Kf1 Rc7 86. Ne2 Kd5 87. Ke1 Rb7 88. Kd2 Rb8 89. Kd3 Rb3+ 90. Nc3+ Ke6 91. Bg7
Rb7 92. Bf8 Rb8 93. Bc5 Rb2 94. Ne2 Kd5 95. Bd4 Rb4 96. Bc3 Rb1 97. Nd4 Rb4 98.
Kc2 Rc4 99. Nxf5 1-0

[Uri Blass]

<snipped>

Some gui(s) used by both CCRL and CEGT produces pgns that violate an important pgn principle.
[/code]

I do not understand what is the importance of the principle that you give.
I see no big problem if irrelevant information is posted.

If the reason is size of the pgn then I think that it is better to change the pgn standard to make pgn even shorter.

Why to have 1.Nf3 when 1.Nf is enough to understand the move because moves that begins with 1.Nf can only be 1.Nf3?

Uri

[Alessandro Scotti]

The PGN standard has a section (8.2.3.4) dedicated to this:

Code: Select all

Note that the above disambiguation is needed only to distinguish among moves of the same piece type to the same square; it is not used to distinguish among attacks of the same piece type to the same square. An example of this would be a position with two white knights, one on square c3 and one on square g1 and a vacant square e2 with White to move. Both knights attack square e2, and if both could legally move there, then a file disambiguation is needed; the (nonchecking) knight moves would be "Nce2" and "Nge2". However, if the white king were at square e1 and a black bishop were at square b4 with a vacant square d2 (thus an absolute pin of the white knight at square c3), then only one white knight (the one at square g1) could move to square e2: "Ne2".

I agree it's not a terrible problem but it can possibly break some parsers so it should be implemented according to the suggested behavior.

[Norm Pollock]

<snipped>

Some gui(s) used by both CCRL and CEGT produces pgns that violate an important pgn principle.
[/code]

I do not understand what is the importance of the principle that you give.
I see no big problem if irrelevant information is posted.

If the reason is size of the pgn then I think that it is better to change the pgn standard to make pgn even shorter.

Why to have 1.Nf3 when 1.Nf is enough to understand the move because moves that begins with 1.Nf can only be 1.Nf3?

Uri

It's all about having "Standards" or "Specifications" and following them. Without standards, software that acts upon pgns wouldn't know what to expect as input. Here is a site with pgn standards:

http://www.very-best.de/pgn-spec.htm#9.9

Here are some other seemingly harmless illegal variations of pgn standards:

"1/2" instead of "1/2-1/2"

"2007.1.1" instead of "2007.01.01"

"[Eco" instead of "[ECO"

"++" instead of "#"

And if there wasn't a standard on capitalization, there would be confusion between "b" and "B".

Guis, databases and utilities accept a lot of variations from standards for practical reasons. But the more that standards are not followed, the more the chance the program will not work on that data.

In this particular case, mentioned in the 1st post here, it is really a small matter to fix the problem because the gui already knows all the possible legal moves. All it has to do is check the list of legal moves to see if there are 2 legal moves by the same type of piece to the same square before it uses "ambiguity" notation. The fix should be easy. All I am asking is that this bug be fixed.

[Marc Lacrosse]

A much more common "faulty" PGN interpretation is the lack of a white space between the dot after move number and the corresponding white move : "1.Nc3" (should be "1. Nc3").

Another common "fault" is incorrect writing of promotion moves.

Some major GUI's do not produce strictly correct PGN.

This is very annoying when using external command line utilities for PGN processing.

AFAIK, one of the best "PGN syntax correctors" is PGNextract by David Barnes. I apply it to any PGN produced by chessbase or SCID before further processing.

Marc

[Norm Pollock]

A much more common "faulty" PGN interpretation is the lack of a white space between the dot after move number and the corresponding white move : "1.Nc3" (should be "1. Nc3").

Another common "fault" is incorrect writing of promotion moves.

Some major GUI's do not produce strictly correct PGN.

This is very annoying when using external command line utilities for PGN processing.

AFAIK, one of the best "PGN syntax correctors" is PGNextract by David Barnes. I apply it to any PGN produced by chessbase or SCID before further processing.

Marc

The mystery gui, whose identity I am trying to find out, also has a problem with promotions and en passant.

It will use "f8Q" instead of "f8=Q"

It will use "exf3ep" instead of simply "exf3"

As for syntax correctors, besides the excellent "pgn-extract", I also use "Joined" by Andreas Stable and my own "trim". I use them in this order: trim, pgn-extract, joined