PGN standard

[Ferdy]

Probably won't happen, but it would be good to see a PGN 2.0 that cleans up some of the complaints and ambiguities.

Added a github repo to attempt to update the PGN standard.
https://github.com/fsmosca/PGN-Standard

We can create issues and we try to solve/clarify it. We will be revising the PGN-Standard.txt file.

[Deberger]

This is great news.

About that en passant target square

http://talkchess.com/forum3/viewtopic.p ... 25#p588125

The original FEN specification is incorrect concerning the en passant target square.

The correct version is: The en passant target square which appears as the fourth field of a FEN record shall be "-" (nil) if no en passant capture is available. If an en passant capture is available, then the en passant target square will be the name of the destination square of an en passant capture. Note that for a non-nil en passant target square in a FEN string there will be at least one en passant capture in the position described by the FEN string; there may be two.

(en passant target square == "-") if and only if (no en passant move available)

(en passant target square != "-") if and only if (at least one en passant move available)

Simple, really. If a program is to generate a FEN record, then the program needs to know how to generate moves. There is no need for complex retro-analysis at all.

Yes, the twenty year old version of the documentation is out of date. But the above is the only change from the original, so if you've read the above then you're up-to-date.

[Ferdy]

This is great news.

About that en passant target square

http://talkchess.com/forum3/viewtopic.p ... 25#p588125

The original FEN specification is incorrect concerning the en passant target square.

The correct version is: The en passant target square which appears as the fourth field of a FEN record shall be "-" (nil) if no en passant capture is available. If an en passant capture is available, then the en passant target square will be the name of the destination square of an en passant capture. Note that for a non-nil en passant target square in a FEN string there will be at least one en passant capture in the position described by the FEN string; there may be two.

(en passant target square == "-") if and only if (no en passant move available)

(en passant target square != "-") if and only if (at least one en passant move available)

Simple, really. If a program is to generate a FEN record, then the program needs to know how to generate moves. There is no need for complex retro-analysis at all.

Yes, the twenty year old version of the documentation is out of date. But the above is the only change from the original, so if you've read the above then you're up-to-date.

Created an en-passant branch https://github.com/fsmosca/PGN-Standard/tree/en-passant to address this issue.

Was:

Code: Select all

...

An en passant target square is given if and only if the last move was a pawn
advance of two squares.  Therefore, an en passant target square field may have
a square name even if there is no pawn of the opposing side that may
immediately execute the en passant capture.

Now:

Code: Select all

...

An en passant target square is given if and only if the last move was a pawn
advance of two squares and the active color has a legal en passant capture
move.

Check if that is enough.

[Deberger]

"the active color" seemed odd at first glance, but that's absolutely consistent with the document terminology.

Well done.

[bob]

I think I would prefer "side on move"

[leanchess]

I'd suggest replacing PGN with a JSON/YAML-based format.

As it happens, I've been recently fiddling with the following position serialisation:

Code: Select all

{
  "players": [
    {
      "pieces": [
        "Ke1",
        "Ra1",
        "Rh1",
        "Bc1",
        "Bf1",
        "Nb1",
        "Ng1",
        "Qd1",
        "Pa2",
        "Pb2",
        "Pc2",
        "Pd2",
        "Pe2",
        "Pf2",
        "Pg2",
        "Ph2"
      ],
      "castlingFiles": [
        "a",
        "h"
      ]
    },
    {
      "pieces": [
        "ke8",
        "ra8",
        "rh8",
        "bc8",
        "bf8",
        "nb8",
        "ng8",
        "qd8",
        "pa7",
        "pb7",
        "pc7",
        "pd7",
        "pe7",
        "pf7",
        "pg7",
        "ph7"
      ],
      "castlingFiles": [
        "a",
        "h"
      ]
    }
  ],
  "currentColor": "white",
  "enPassantSquare": null
}

[gbtami]

Years ago Tord Romstad suggested to create a PGN replacement format in https://www.reddit.com/r/chess/comments ... gn_format/
Does anyone know was it evolved to something concrete?

[Ferdy]

I think I would prefer "side on move"

In the document the phrase active color refers to side on move (as also observed by Deberger for consistency). If you really insist on "side on move" I will add it with or like this.

Code: Select all

...

An en passant target square is given if and only if the last move was a pawn
advance of two squares and the active color or side on move has a legal
en passant capture move.

Or perhaps we can use the phrase "side to move" which is probably more common.

Code: Select all

...

An en passant target square is given if and only if the last move was a pawn
advance of two squares and the active color or side to move has a legal
en passant capture move.

[Ferdy]

Years ago Tord Romstad suggested to create a PGN replacement format in https://www.reddit.com/r/chess/comments ... gn_format/
Does anyone know was it evolved to something concrete?

It would be interesting to see how they improved the readability of the existing format.

[lucasart]

I'd suggest replacing PGN with a JSON/YAML-based format.

As it happens, I've been recently fiddling with the following position serialisation:

Code: Select all

{
  "players": [
    {
      "pieces": [
        "Ke1",
        "Ra1",
        "Rh1",
        "Bc1",
        "Bf1",
        "Nb1",
        "Ng1",
        "Qd1",
        "Pa2",
        "Pb2",
        "Pc2",
        "Pd2",
        "Pe2",
        "Pf2",
        "Pg2",
        "Ph2"
      ],
      "castlingFiles": [
        "a",
        "h"
      ]
    },
    {
      "pieces": [
        "ke8",
        "ra8",
        "rh8",
        "bc8",
        "bf8",
        "nb8",
        "ng8",
        "qd8",
        "pa7",
        "pb7",
        "pc7",
        "pd7",
        "pe7",
        "pf7",
        "pg7",
        "ph7"
      ],
      "castlingFiles": [
        "a",
        "h"
      ]
    }
  ],
  "currentColor": "white",
  "enPassantSquare": null
}

I think you are attacking the wrong problem. FEN is perfectly good and easily parsable, much easier than what you propose. FEN parsing is implemented by every amateur programmer in their engines, and is trivial. It is arguably the only good thing about the PGN standard.

The problem with PGN is everything after the tags. Move numbers are both useless and not even properly defined. SAN is an abortion, parsing it is atrocious, and requires writing almost a full move generator. Then all the stupid parsing rules about comments, etc.