Added a github repo to attempt to update the PGN standard.
sje wrote: ↑Tue Sep 16, 2014 4: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.Deberger wrote: ↑Fri May 22, 2020 4:46 pm This is great news.
About that en passant target square
http://talkchess.com/forum3/viewtopic.p ... 25#p588125
sje wrote: ↑Tue Sep 16, 2014 4: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.
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.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.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
}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.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.It would be interesting to see how they improved the readability of the existing format.gbtami wrote: ↑Sat May 23, 2020 8: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?
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.leanchess wrote: ↑Sat May 23, 2020 8: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 }