PGN standard

[Ovyron]

I've been using 1...e5 since 2001. I find incredible that not only it's incorrect, when people discuss what's correct it doesn't even get a mention as a possibility

Not only that, ALL the correspondence chess games played at the Rybka Forum have used 1...e5 notation (as opposed to 1.. e5, 1... e5 or 1. ... e5) since 2008.

And it's all wrong? This is like a Mandela Effect...

[leanchess]

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?

Interesting. That proposal (and most comments) align nicely with what I've been fiddling with. Too bad it didn't come to fruition.

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.

I don't disagree; I merely presented a taste of what (partially) structured data might look like. If we are to wholly replace PGN, board representation could be part of the whole.

[bob]

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.

Wasn't really insisting on anything. Just that in chess, "side on move" or "side to move" or "black to move" or "white to move" is the usual terminology. Not "black is the active color" for example.

[bob]

I've been using 1...e5 since 2001. I find incredible that not only it's incorrect, when people discuss what's correct it doesn't even get a mention as a possibility

Not only that, ALL the correspondence chess games played at the Rybka Forum have used 1...e5 notation (as opposed to 1.. e5, 1... e5 or 1. ... e5) since 2008.

And it's all wrong? This is like a Mandela Effect...

I went with my " 1. ... e4" approach as that was what was used in the chess books I used back in the 60's. All of my programs could export games easily, although obviously not in a PGN specification. The tags came way later after Steven did the standard. 1. ... e4 has always (to me) looked like the right way. Move number, white move, black move". Not sometimes move number, white move black move, or other times move number+white move jammed together, then black move (white move = .. obviously). The "ellipsis" is supposed to be 3 consecutive dots. But the move number also is followed by a . So a bit of ambiguity. IE 1.... e4 might be closer to being grammatically correct. but 1. ... e4 seems more logical.

[bob]

Personally, I am a fan of SAN and always have been. It's the way things are written in chess books, game scores by humans, etc. It reads much more naturally to me (as a human). I didn't find it difficult to parse although a move generator is needed. It is needed in a chess engine anyway, so that is not exactly a reason to not use it.

[Dann Corbit]

Personally, I am a fan of SAN and always have been. It's the way things are written in chess books, game scores by humans, etc. It reads much more naturally to me (as a human). I didn't find it difficult to parse although a move generator is needed. It is needed in a chess engine anyway, so that is not exactly a reason to not use it.

I agree with this. SAN is the easiest thing for humans to understand, and comes very naturally. And I was reading chess books before it came common place, so I did not grow up on it.

The notation used by UCI is nice for machines but much harder for me to read and visualize.

To me, the coordinate notation of UCI makes sense for engines, but not for display to people. Whenever something is emitted and intended for human consumption, it should be SAN.

[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.

Wasn't really insisting on anything. Just that in chess, "side on move" or "side to move" or "black to move" or "white to move" is the usual terminology. Not "black is the active color" for example.

All right I will just keep it as it is.

[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.

Wasn't really insisting on anything. Just that in chess, "side on move" or "side to move" or "black to move" or "white to move" is the usual terminology. Not "black is the active color" for example.

All right I will just keep it as it is.

en passant revision is now in master, also added version number.
https://github.com/fsmosca/PGN-Standard ... andard.txt

[bob]

Personally, I am a fan of SAN and always have been. It's the way things are written in chess books, game scores by humans, etc. It reads much more naturally to me (as a human). I didn't find it difficult to parse although a move generator is needed. It is needed in a chess engine anyway, so that is not exactly a reason to not use it.

I agree with this. SAN is the easiest thing for humans to understand, and comes very naturally. And I was reading chess books before it came common place, so I did not grow up on it.

The notation used by UCI is nice for machines but much harder for me to read and visualize.

To me, the coordinate notation of UCI makes sense for engines, but not for display to people. Whenever something is emitted and intended for human consumption, it should be SAN.

I started with English Descriptive Notation. IE B-QB4, KN-R3, etc. Took me a while to "become algebraic" which is what we all called SAN back in the early days since the main thing was squares became a1-h8, no KB4 and such, and most particularly KB or QB, not so easy to remember which came from kingside or queenside, particularly KN and QN. So SAN became a quick hit with me. Don't remember when I made the switch, I do know that when MCO10 came out, we were still using EDN since MCO was using EDN.

[Dann Corbit]

I don't know if anyone has mentioned it, but the:
[Setup "1"] tag that is required when there is a fen position is utterly and in all ways inconceivably useless.
Since we already have a [Fen "position"] tag, what is the Setup tag supposed to do for us? Is it a friendly warning?
"Strap on your helmets, boys and get ready for action. There's a FEN coming, and she's a beauty!"