PGN standard & null moves (Steven?)

[hgm]

The current PGN standard does not support null moves. While the latter can be very useful in variations, to indicate a threat. E.g.

1. e2 e4 2. Nf3 Nc6 (2... pass 3. Nxe5 Qe7!) 3. Bc4

So there is a lot of software that supports null moves, but for lack of a standard, there is a Babylonic confusion in the notations they use for it. Not writing them at all is not really an option, as the next move would be mistaken for a move of the wrong side, and SAN in general does not make that obvious (e.g. Ng5 could be possible for Knights of both sides). So I think it is pretty important to adopt an official standard for it, and add it to the authoritive document describing the PGN standard.

So my question is: who decides about the PGN standard, and how can we approach them?

As as small (and probably incomplete) overview of what is currently in use, I made the following:

SCID uses "--", but has the option to save it as a comment ("{--}"?). It also understands "Z0" on input.
According to SCID docs there is other software that uses "Z0".
WinBoard uses "pass", but also understands "null" and "@@@@" on input.
WB protocol uses "@@@@".
UCI uses "0000".

I don't like the "--" much, because of low visibility, and possible confusion with other (non-compliant) notations +=, -= etc. I don't like the "Z0" much because a leading capital suggests a piece name (some variants use a piece called Zebra), which makes parsing more difficult / less efficient, and because it is notvery intuitive, but I think it is better than "--".

Any comments / suggestions are welcome.

[smrf]

"0000" may conflict to bad written castling moves,
"null", "pass" or "@@@@" does not look like a regular move.

I would suggest to have the (always existing) King move
from his field to his field, thus changing nothing. Because
of different encoding of castlings there would not be a conflict.

Nevertheless there is a problem on how to encode free castling moves:
"long" free castling to a-side: e.g. O-O-O-d (w-King to d1)
"short" free castling to h-side: e.g. O-O-g (w-King to g1)

[hgm]

Indeed, the protocol forms do not seem suitable for use in PGN, which is no problem for their own, much more limited context (which has its own conventions for castling, like e1g1).

The use of a dummy King move is an interesting idea, and a new proposal. This can be compared to one way of entering null moves in SCID, which is capturing the opponent King with your own. This would yet be another proposal.

The downside of both of these is that the notation of null move will become dependent on the board position, making it much less obvious we are dealing with a null move. Personally I don't think it is a bad thing that null-move notation (like "pass" or "null") doesn't look much like any other move. On the contrary. This just reduces chances for confusion. After all, a null move is not like any other move. It is very special (if only because it is illegal to play it), so why shouldn't it stand out 'loud and clear'? SAN for castlings is not very much like a normal move either.

[Rémi Coulom]

My treemap visualizer uses "null" for null moves in PGN, FWIW.

Rémi

[Michel]

I would prefer "pass" for games where passing is legal and "null" for
games where it is illegal.

EDIT: Of course I am sure that there are variants where passing is sometimes legal but not always....

[Herb Goodwin]

The current PGN standard does not support null moves.

SCID uses "--"

I don't like the "--" much, because of low visibility, and possible confusion with other (non-compliant) notations +=, -= etc.

Any comments / suggestions are welcome.

ChessBase .cbh Notation displays the null move as "--", and when translating to PGN notation maintains this convention in the text.

ChessBase reads PGN notation with moves such as 10.-- as a null move, and translates PGN with this null move convention back to .cbh Notation without a hitch.

It seems to me that with ChessBase and SCID already supporting this convention in PGN notation, the chess world already has a standard for the null move in PGN notation.

[Michel]

EDIT: Of course I am sure that there are variants where passing is sometimes legal but not always....

Because of this issue I amend my proposal. A pass move is written as "pass" if it is legal and "null" if it is illegal (so in regular chess it would always be written as "null").

I think in games where passing is sometimes legal and sometimes not (e.g.
reversi) it is important to distinguish the two cases.

[sje]

PGN allows only for legal moves and only for orthodox chess. This was settled nearly twenty years ago on r.g.c.c, and this was done entirely in public. Changing the legal-moves-only clause would break nearly all PGN importing software.

I've been thinking of doing a re-write of the standard over the winter months. Perhaps at that point appendices could be added for support for extended features. But in no case should anything be changed that would cause existing PGN readers to fail when accessing legal, orthodox chess text.

[stevenaaus]

I'm slowly coming up to date with this issue.

Scid uses "--" , which i prefer more than the alternatives suggested so far. And using this slightly unusual string, i can do a header search for "--" in pgn text, to identify which games contain a null move. AFAIK there's no other way to find these games.

The use of a dummy King move is an interesting idea, and a new proposal.

Hmmmm... in *some* places, Scid already repesents null move as "e8e8" (for example) ie. King moves to same square. But i still prefer "--"

According to SCID docs there is other software that uses "Z0"

haha... i just reiterated that in my doco update, but of course i know anothing about it.

And it's true, null moves probably *shouldn't* exist ... at least in mainlines. But i'm sure lots of people still shake their head at complex numbers too, so i have no plans to change their implementation in Scid vs. PC.

[hgm]

Well, I guess there always is the possibility to extend the standard in a backward-compatible way, by assigning a meaning to what legacy software would understand as a comment. It could, for instance, be defined that any comment starting with {{ would in fact be a variation in the extended standard, so that al new software could write things like

1. e4 e5 2. Nf3 Nc6 {{2... Nf6 3. Nxe5 Qe7 4. Nf3} 3. Bc4 Bc5

in stead of

1. e4 e5 2. Nf3 Nc6 (2... Nf6 3. Nxe5 Qe7 4. Nf3) 3. Bc4 Bc5

and then use null moves in the 'protected part':

1. e4 e5 2. Nf3 Nc6 {{2... pass 3. Nxe5 Qe7 4. Nf3} 3. Bc4 Bc5

It would be a bit awkard, though, because there can be comments inside variations, and these would the closing brace of those would then have to escaped too, e.g. by replacing } by ]:

1. e4 e5 2. Nf3 Nc6 {{2... Nf6 3. Nxe5 {captures a pawn] Qe7 4. Nf3} 3. Bc4 Bc5

It is really very unfortunate when a standard is dead, by not offering any handles for future extension at all. Handles could be easily provided, e.g. by the simple rule that anything surrounded by (nesting) angular brackets < > should be parsed as a comment when stripping the surrounding brackets off would give you something that would violate the standard as you know it. People could then simply surround parts of the output that can only be understood in a later version of the standard by < > to hide it from legacy software.