PGN standard

[Ovyron]

I think the point of spaces was to simplify parsing. IE strtok() will break a string into tokens using one or more specifiers. It doesn't, however, work with 1...e4, and it is messy with 1. .. e4 or 1... e4.

Probably irrelevant today .

Yeah, the problem with spaces is... the waste of space. Many GUIs have already decided that no space is the way to go, they show their PGNs on screen without spaces (so more of the game can fit on the screen), they show Engine PV lines without spaces (so more moves can be shown on the line.) And yet, when one Copy->Pastes the spaces are added to conform.

You can see this problem on this very forum when the PGN tags are used to display games, they're shown with spaces and are longer than necessary.

I believe in a flexible format that tries its best at understanding its input as a game, 00 could be allowed as castle notation, 4 (yes, just a 4) can be valid if this side only has a piece that can move to the 4th rank, Q can be valid if there's no queen and a single promoting pawn to queen, or the queen only has 1 playable move (then Q is unambiguous.) We could call it XPGN.

Having a human readable format isn't feasible because no human actually goes and reads a PGN and sees the moves in their head, we need an actual board with pieces moving anyway to see the game, so getting rid of anything that uses space (like h instead of just h4 when moving an h3 pawn, where declaring its rank isn't necessary, or just having .. for black moves) would be ideal.

[bob]

I think the point of spaces was to simplify parsing. IE strtok() will break a string into tokens using one or more specifiers. It doesn't, however, work with 1...e4, and it is messy with 1. .. e4 or 1... e4.

Probably irrelevant today .

Yeah, the problem with spaces is... the waste of space. Many GUIs have already decided that no space is the way to go, they show their PGNs on screen without spaces (so more of the game can fit on the screen), they show Engine PV lines without spaces (so more moves can be shown on the line.) And yet, when one Copy->Pastes the spaces are added to conform.

You can see this problem on this very forum when the PGN tags are used to display games, they're shown with spaces and are longer than necessary.

I believe in a flexible format that tries its best at understanding its input as a game, 00 could be allowed as castle notation, 4 (yes, just a 4) can be valid if this side only has a piece that can move to the 4th rank, Q can be valid if there's no queen and a single promoting pawn to queen, or the queen only has 1 playable move (then Q is unambiguous.) We could call it XPGN.

Having a human readable format isn't feasible because no human actually goes and reads a PGN and sees the moves in their head, we need an actual board with pieces moving anyway to see the game, so getting rid of anything that uses space (like h instead of just h4 when moving an h3 pawn, where declaring its rank isn't necessary, or just having .. for black moves) would be ideal.

A couple of points.

(1) while I certainly can't run through a 60 move PGN file in my head, I can (and do) run through the first 15-20 moves without a headache.

(2) IM Mike Valvo (RIP Mike) used to play blindfold matches, and the way he managed each board was to mentally store the list of moves along with his best recollection of the board position. Occasionally he would call out an illegal move, and when told he would run back through the sequence of moves, say "right, forgot about this..." and keep on playing.

I like SAN. I've used it for over 40 years, since I (and chess in general) dumped English descriptive notation. I can deal with the shortened forms. But things like "h" and "4" don't strike me as a good idea. If the goal is to compress the game, why not just have a specific move generator order for producing moves, then just output the index into that list of moves for the current position, which would mean one byte for every move. Humans could not deal with it at all however.

The original intent of PGN was to design something that had a standard so that any PGN-compliant thing could read and understand it, whether human or electronic. SAN was already in use, and seemed natural. A bit more difficult to export or import than pure algebraic, but more compact and actually easier to read (at least for me).

The main thing I would like to see fixed is the EP issue in PGN, and then adding a defined format for score, depth, etc, so that parsing becomes standard.

PGN itself is not actually so bad. Only 7 tags are required, and adding the starting position option later solved another issue when using PGN to create an opening book for 960 type games...

I think it needs a scalpel, not an axe...

[Ovyron]

(1) while I certainly can't run through a 60 move PGN file in my head, I can (and do) run through the first 15-20 moves without a headache.

Because it was there from the beginning. If my XPGN notation was there from the beginning, everyone would have gotten used to it, and you'd see a 5 and think "it can only be the d4 pawn that moved there earlier."

Just compare:

[d]rnbqkb1r/ppp2ppp/4pn2/8/2pP4/5NP1/PP2PP1P/RNBQKB1R w KQkq -

Engine: b1d2
PGN: Nbd2
XPGN: Nb2

That's a knight to the 2nd rank, the b specifies which knight, and that's it. Why is the d necessary when there's no other square on the 2nd rank to where it can move? Of course if there wasn't a knight on f3 we could just use N2, Knight to second rank, there's only one way to interpret that...

(2) IM Mike Valvo (RIP Mike) used to play blindfold matches, and the way he managed each board was to mentally store the list of moves along with his best recollection of the board position. Occasionally he would call out an illegal move, and when told he would run back through the sequence of moves, say "right, forgot about this..." and keep on playing.

The list of moves he'd have needed to store would have been shorter with XPNG. e4 e5 Nf Nc <- can't you visualize that? is the 3 on Nf3 and 6 on Nc6 necessary? No, they aren't.

If the goal is to compress the game, why not just have a specific move generator order for producing moves, then just output the index into that list of moves for the current position, which would mean one byte for every move. Humans could not deal with it at all however.

The difference is that I couldn't read what you came up with. If you were to teach a child XPGN she would be able to visualize the game as easily as with SAN, and faster because there's less characters to read, less space used on the screen, the eyes can just move faster from move to move.

This reminds me of QWERTY keyboards, it was found out that the arrangement of the keys would cause mistakes, and that to avoid them people would need to type at a slower speed. An optimal arrangement of the letters was found, minimizing mistakes while maximizing speed. The fastest QWERTY keyboard people couldn't keep up the pace with the people that learned to use the new arrangement.

Did people move on to it? No, most people in the world had already learned to type on QWERTY keyboards, their brains had been trained on them for so much that they struggled greatly with the new arrangement. And because of that, current generations, and future generations will be stuck with the inferior layout. Just like with PGN.

But paraphrasing Dann, the boat had sailed long time ago. 200 years from now people will continue to use PGNs and QWERTY keyboards.

[Dann Corbit]

On the extremely simplified move notation, I am not sure if I like it. Probably my problem is that I am used to SAN now.
But the removal of one letter makes me look at both knights and think for a moment.
With SAN, the clarification is coded in the move. It is implied in your notation, and it is one byte shorter. But one TB of storage is $100.
I guess I think of Einstein's quote, "Things should be made as simple as possible, but no simpler."

So maybe you are right, but I still like SAN better (at least for now).

[bob]

I agree. I started with English descriptive. Was very difficult for me to convert (mentally) to algebraic/SAN. But once I did, my conclusion was it was much better. I found it difficult to handle things qb-n3 and such. Particularly kn-f3. With a knight at e1 and g1 later in the game... My only issue with a move like "4" is that it requires a lot of context. IE what can reach the 4th rank, which could be any pawn on the 2nd/3rd ranks, plus lots of pieces. That would require some serious concentration. SAN requires some thinking at times.

But SAN is sort of "embedded" to me now, and more importantly, there are literally 100's of millions of games out there already...

[Ferdy]

Put up an issue on how to handle armageddon game in a PGN. Any thoughts?