Optimised Algebraic Notation

[leanchess]

I've specified something like this https://github.com/Sopel97/chess_pos_db ... s/Eran.cpp (Extended Reverse Algebraic Notation, which is based on Reverse Algebraic Notation

Thanks! I should have done my research. It looks like my proposal is essentially a flavour of Reversible Algebraic Notation, only with fixed length. I'm wondering if that's really worth the effort.

[hgm]

Well, you know what they say on the stock exchange: "the market is always right". It doesn't really matter what you think is best. It matters what the majority of people prefer to use. It seems you are hugely outvoted on this. People like to use SAN. Look up the account of a chess match in a newspaper: the moves will be given in SAN. Buy a chess book (I have Seirawan's "Five Crowns" lying before me), and all moves in it will be printed in SAN. View a game on FICS or LiChess: the moves list will be displayed as SAN.

Now go back 50 years or so when descriptive notation was being used and apply your argument.

It was never used where I live.

[R. Tomasi]

I just spent a couple of days implementing a PGN parser, which of course includes parsing moves in SAN notation. Personally, I really do think that SAN is a royal pain, such that in principle I would be in favour of such a notation.

SAN is a massive mistake. It is much too error prone; not only in parsing it, but also in writing it. for example, something like a7xb8q could be written like this:

- axb8q
- a:b8q
- ab8:q
- ab8q
- ab:q
- abq

I've seen all of them during the years. I'll first have to find out what the default is for PGN.

I think that is the root problem with SAN: the standard doesn't seem to be defined with precision. Everybody is using ones' own interpretation/dialect. Granted, the PGN specification does to some extent clarify how SAN should be used within PGN files, but then again in a real world application you realize that not every PGN file sticks to that specification. Now, one could argue that these files aren't proper PGN files... but does that provide any help when you simply need to read them for some reason?

There are also many mistakes made when rooks are on the same files or ranks:

- Raa8 vs. Rea8
- R1a5 vs. R7a5

Well, mistakes/typos may happen with other forms of notation as well (although it's maybe easier to spot them). I used PGN files of grandmaster games for testing my parser (I'd have to look up where I got them from, but it was what looked like a professional source). A lot of them contained outright illegal moves. Upon inspection it turns out that virtually all of these were OCR errors (stuff like 7 instead of 1, a instead of e, etc.). I guess that may happen with any standard. Does not make it less annoying, though.

The best notation is long algebraic notation. This is not the 19th century anymore, where we have to conserve space in the paper.

I agree. PGN (with all the SAN madness) is however so widespread, that you simply cannot evade it. Sadly, it's not the first time that a poorly chosen standard (or even just an accident of history) haunts the entire industry for decades.

[R. Tomasi]

Addendum to my last post (and maybe somewhat back to the topic at hands):

I am not sure if these types of OCR errors are still an issue when new games are archived. I suspect these come from a time when the databases were mostly paper-based and had to be scanned/OCR-processed at some point. Nevertheless, what I would like to propose (in the unlikely event that a new standard emerges and gets adopted) is to incorporate some type of error-detection. Maybe some sort of checksum.

[hgm]

People won't care about standards. They will simply do what they consider most convenient.

All algebraic notations are one family. It is not that people who use SAN would not be aware that the from-square can also be unambiguously written by its coordinates. The just prefer to indicate it by the piece that is on it.

[leanchess]

Speaking of standards, is there one for RAN?

Wikipedia only has a trivial example, and Chessprogramming wiki only mentions Smith notation (which doesn't seem to fit the bill).

[dangi12012]

Well, you know what they say on the stock exchange: "the market is always right". It doesn't really matter what you think is best. It matters what the majority of people prefer to use. It seems you are hugely outvoted on this. People like to use SAN. Look up the account of a chess match in a newspaper: the moves will be given in SAN. Buy a chess book (I have Seirawan's "Five Crowns" lying before me), and all moves in it will be printed in SAN. View a game on FICS or LiChess: the moves list will be displayed as SAN.

You know that can be said about everything. Think back 30 years and what people said in 1991 about computer mice. Or in 1995 about the internet.

"It seems that you are hugely outvoted by people not using the internet so its proven that it cannot work"

And now the majority of all chess is over the internet. So pgn was not invented for the digital age and as is noted here is hard to parse correctly.

[hgm]

A totally nonsensical comparison. The internet was somerhing new, which required investment in equipment and services to use. People learn long algebraic notation and SAN at exactly the same moment, though, and are completely free to use whatever they like best.

[Ras]

People don't care about SAN in PGN, that's complete nonsense. What people care about is that there is a format that can be exported and imported in any chess software, and it just works. Any new "improved" format would break this number one feature. The setting for long or short notation is just a GUI option for the users with no relation to the file content format.

[R. Tomasi]

People don't care about SAN in PGN, that's complete nonsense.

Indeed, the typical user doesn't care. Whoever tries to implement a PGN parser is forced to care, though.

What people care about is that there is a format that can be exported and imported in any chess software, and it just works. Any new "improved" format would break this number one feature.

Yes, that's what I was trying to point out.

The setting for long or short notation is just a GUI option for the users with no relation to the file content format.

Not only for the user, also from a programmers viewpoint it's probably just one branch when parsing a move. Trouble for the user is, that unless the developer of whatever software he's using to import PGN chooses to provide that option he can't read "new" PGN files that use a different move notation. There would have to be some consensus among avtive developers to change most freeware programs to provide the option. Elsewise all complaining about how crap SAN is will not help. I have a hunch that it's not going to happen...