PGN standard

Discussion of chess software programming and technical issues.

Moderators: bob, hgm, Harvey Williamson

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
Ferdy
Posts: 4270
Joined: Sun Aug 10, 2008 1:15 pm
Location: Philippines

Re: PGN standard

Post by Ferdy » Fri May 22, 2020 3:20 am

bob wrote:
Fri May 22, 2020 1:18 am
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.

User avatar
Deberger
Posts: 49
Joined: Sat Nov 02, 2019 5:42 pm
Full name: ɹǝƃɹǝqǝᗡ ǝɔnɹꓭ

Re: PGN standard

Post by Deberger » Fri May 22, 2020 2:46 pm

This is great news.

About that en passant target square :-)

viewtopic.php?p=588125#p588125
sje wrote:
Tue Sep 16, 2014 2:35 pm

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
Posts: 4270
Joined: Sun Aug 10, 2008 1:15 pm
Location: Philippines

Re: PGN standard

Post by Ferdy » Sat May 23, 2020 12:41 am

Deberger wrote:
Fri May 22, 2020 2:46 pm
This is great news.

About that en passant target square :-)

viewtopic.php?p=588125#p588125
sje wrote:
Tue Sep 16, 2014 2:35 pm

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.

User avatar
Deberger
Posts: 49
Joined: Sat Nov 02, 2019 5:42 pm
Full name: ɹǝƃɹǝqǝᗡ ǝɔnɹꓭ

Re: PGN standard

Post by Deberger » Sat May 23, 2020 6:10 am

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

Well done.

bob
Posts: 20916
Joined: Mon Feb 27, 2006 6:30 pm
Location: Birmingham, AL

Re: PGN standard

Post by bob » Sat May 23, 2020 4:54 pm

I think I would prefer "side on move"

User avatar
leanchess
Posts: 84
Joined: Sun Dec 08, 2019 7:16 pm
Full name: Dmitry Shechtman
Contact:

Re: PGN standard

Post by leanchess » Sat May 23, 2020 6:02 pm

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
}

User avatar
gbtami
Posts: 377
Joined: Wed Sep 26, 2012 11:29 am
Location: Hungary
Contact:

Re: PGN standard

Post by gbtami » Sat May 23, 2020 6:20 pm

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
Posts: 4270
Joined: Sun Aug 10, 2008 1:15 pm
Location: Philippines

Re: PGN standard

Post by Ferdy » Sun May 24, 2020 1:25 am

bob wrote:
Sat May 23, 2020 4:54 pm
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
Posts: 4270
Joined: Sun Aug 10, 2008 1:15 pm
Location: Philippines

Re: PGN standard

Post by Ferdy » Sun May 24, 2020 1:37 am

gbtami wrote:
Sat May 23, 2020 6:20 pm
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.

User avatar
lucasart
Posts: 3109
Joined: Mon May 31, 2010 11:29 am
Full name: lucasart
Contact:

Re: PGN standard

Post by lucasart » Sun May 24, 2020 4:32 am

leanchess wrote:
Sat May 23, 2020 6:02 pm
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.
Theory and practice sometimes clash. And when that happens, theory loses. Every single time.

Post Reply