PGN standard

[chrisw]

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.

UCI is precisely to be read by machines, not humans. Consider yourself lucky the interface doesn’t send hex codes instead of move coordinates.
There’s no reason, btw, that the gui you use to view engine best line chatter can’t convert to SAN and output that.
I guess what you may be thinking is why engines can’t communicate by SAN, well, they could, but the scope for ambiguity and consequent bugs would be high. Inter-engine communication should in general be as simple as possible.

[Ferdy]

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!"

Added an issue in github.

[Ferdy]

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

You have 1...e5.
Lets find out if it is according to standard. Not according to Rybka Forum standard

8.2.2: Movetext move number indications
A move number indication is composed of one or more adjacent digits (an integer
token) followed by zero or more periods. ...

So,
1... should be a move number indication, for black

8.2.2.2: Export format move number indications
... A black move number indication is formed from the integer
giving the fullmove number with three period characters appended.

1. should be a move number indication for white (for export)

... A white move number indication is
formed from the integer giving the fullmove number with a single period
character appended.

1 can be a move number indication for white (on import)

PGN import format does not require move number indications. It does not
prohibit superfluous move number indications anywhere in the movetext as long
as the move numbers are correct.

Let's go back to black move.
The 1...e5 is composed of black move number indication plus move element without a space, so this is not according to standard because the move number indication has appended characters.
1... e5 is according to standard. There is a space between the move element and the move number indication 1...
that is:
move number indication: 1...
move: e5

You can also post your comments here https://github.com/fsmosca/PGN-Standard

[Fulvio]

The 1...e5 is composed of black move number indication plus move element without a space, so this is not according to standard because the move number indication has appended characters.

The tokens are recognized accordingly to chapter "7: Tokens" (not using spaces).
The expression "1...e5" is composed of 5 tokens: an integer symbol token (1), three "." tokens, and a symbol token (e5).
Note that it is explicitly stated that some tokens are self delimiting (like the "." token) and do not require white space characters.

1... e5 is according to standard. There is a space between the move element and the move number indication 1...

All the notations cited in this thread are perfectly fine accordingly to the standard and should be parsed without problems.
Regarding the "export format" unfortunately the chapter 8.2.1 focus on space savings:
"As many tokens as possible are placed on a line with the remainder appearing on successive lines. A single space character appears between any two adjacent symbol tokens on the same line in the movetext."
However the prescribed ugly notation:
1.e4 e5 2.d3{a comment}2...e6
usually is not used preferring a more readable:
1. e4 e5 2. d3 {a comment} 2... e6
(Each symbol token is separated from the previous token using a single space. Each symbol token, excluding integer ones, is separated from the next token using a single space. The first token and the last token do not have a space before and after them respectively.)

[Ovyron]

1... e5 is according to standard. There is a space between the move element and the move number indication 1...

I get it. What I don't get is what does the space do? What purpose does it serve.

It's like 1. e4, the space doesn't seem to do anything (1.e4 would work), so looks like spaces were added to the PGN standard just to unnecessarily complicate things.

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

But a concise standard would be nice. IE san or coordinate. I prefer SAN since PGN is supposed to be human and machine readable. And what about: 0-0. O-O. and o-o? All appear in various PGN games lying around. Lots of other examples as well. A standard that says "anything allowed" is not very helpful.

[Dann Corbit]

But a concise standard would be nice. IE san or coordinate. I prefer SAN since PGN is supposed to be human and machine readable. And what about: 0-0. O-O. and o-o? All appear in various PGN games lying around. Lots of other examples as well. A standard that says "anything allowed" is not very helpful.

I think the problem is that we are late in the game. If a specification is written and ChessBase, ChessAssistant, Aquarium, Shredder GUI, Scid, and Arena can't read or write to the specification, it probably won't be accepted.

I guess that to succeed the commercial players will have to be involved.

Winboard has a really forgiving parser. The three castle formats you mention are all parsed by it, if I recall correctly. Since it is in its infancy now, what I would really like to see is a clear and unambiguous specification for computer annotation of games. Right now, it is anything goes and it can be frustrating trying to parse it because it will change tomorrow, even if you stick with the same interface.

For me, with backward specification in mind, the only changes that I think would be really helpful are fixing e.p. so that only when it is possible it gets set and removal of the [Setup "1"] tag.

I also wonder if communication between engine and GUI might be better served by a binary standard instead of text strings.

The new "probability of winning" score is bad for me but only because all of my data is in centipawns. I would like to see a requirement that centipawns are provided as an alternative, but I imagine not a lot of other people feel that way.

Oh yes, and depth reporting... I don't know what to think about the NN depth reporting. I think that the really low depths by engines like LC0 are not really reflective of the strength of the search. And the new neural net Scorpio engines give ludicrous depths (e.g. 70+ plies in a few seconds on a complex position). Daniel must be including qsearch depth or something. But the problem with depth reporting is that I have no idea how to standardize it, since the meaning is not really the same from engine to engine and especially across engine class boundaries.

[Terje]

...

Oh yes, and depth reporting... I don't know what to think about the NN depth reporting. I think that the really low depths by engines like LC0 are not really reflective of the strength of the search. And the new neural net Scorpio engines give ludicrous depths (e.g. 70+ plies in a few seconds on a complex position). Daniel must be including qsearch depth or something. But the problem with depth reporting is that I have no idea how to standardize it, since the meaning is not really the same from engine to engine and especially across engine class boundaries.

"Scorpio's search depth is arbitrary, and goes from 63 to 75. Scorpio reports pv 10 times during a search and increments "depth" on every report" from a TCEC chat command. It's not attempting to give a reasonable or meaningful depth.

[Ferdy]

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!"

Created a branch "remove-SetUp-pgn-tag" and started revising the standard. Can you check if this is enough?
https://github.com/fsmosca/PGN-Standard ... 6aaba5dc4b

This is the branch, see 9.7.1 and 9.7.2
https://github.com/fsmosca/PGN-Standard ... andard.txt

[Ferdy]

I did revised the top of the standard.

Code: Select all

Standard: Portable Game Notation Specification and Implementation Guide

Version: 1.0

Revised: 2020-06-03

Authors:
1: Interested readers of the Internet newsgroup rec.games.chess,
2: Interested readers in http://talkchess.com/forum3/index.php

Coordinators:
1. Previous: Steven J. Edwards
2. Current: ?

Was,

Code: Select all

Standard: Portable Game Notation Specification and Implementation Guide

Revised: 1994.03.12

Authors: Interested readers of the Internet newsgroup rec.games.chess

Coordinator: Steven J. Edwards (send comments to sje@world.std.com)

Any comments?