Optimised Algebraic Notation

[leanchess]

But "moved piece" and "captured piece" seems redundant to me?
Since for unmake you only would need to remeber that but you wouldnt need to store it in the "OAN" file.
I think its clear to just write E2-E4

Suppose struct Move looks like this (C# example):

Code: Select all

    public struct Move
    {
        public int From { get; set; }
        public int To { get; set; }
        public int PromoPiece { get; set; }
        public bool IsCapture { get; set; }
    }

How do you unmake a capture?

[dangi12012]

But "moved piece" and "captured piece" seems redundant to me?
Since for unmake you only would need to remeber that but you wouldnt need to store it in the "OAN" file.
I think its clear to just write E2-E4

Suppose struct Move looks like this (C# example):

Code: Select all

    public struct Move
    {
        public int From { get; set; }
        public int To { get; set; }
        public int PromoPiece { get; set; }
        public bool IsCapture { get; set; }
    }

How do you unmake a capture?

The struct should contain it. The text doesnt need to - since the piece on the FROM square just needs to be remembered.

[hgm]

It would be a cool feature of a notation that it could be read in two directions, though.

[leanchess]

The struct should contain it. The text doesnt need to - since the piece on the FROM square just needs to be remembered.

The idea is to follow the struct as closely as possible while keeping it readable. The code becomes very simple:

Code: Select all

        private Move FromStringInner(string value)
        {
            Move move = new();
            char[] chars = value.ToCharArray();
            move.Piece = GetPiece(chars[0]);
            move.From = GetSquare(chars[1], chars[2]);
            move.CapturedPiece = GetPiece(chars[3]);
            move.To = GetSquare(chars[4], chars[5]);
            SetPromoPiece(ref move, chars);
            return move;
        }

        private void SetPromoPiece(ref Move move, char[] chars)
        {
            if (chars[6] == EnPassantChar)
                move.PromoPiece = Pieces.Pawn;
            else if (chars[6] >= MinFileChar)
                move.CastlingFrom = GetSquare(chars[6], chars[2]);
            else
                move.PromoPiece = GetPiece(chars[6]);
        }

[leanchess]

It would be a cool feature of a notation that it could be read in two directions, though.

An interesting idea. That would require the game notation to include the final position.

[abulmo2]

To me the portable algebraic notation used in the UCI protocol is the optimised notation. It just contains the from & to squares and the occasional promoted piece. Nothing else is needed to store a move. Furthermore it is reasonably readable by a human.

Where is that defined? I read the UCI documentation and i only ever saw "moves" mentionend. Never in which format they are. From stockfish output i can see that From/To is written fully and castling is from/to square for the king (from<->to difference of 2 squares so its clear)

The uci protocol states:

Code: Select all

Move format:
------------

The move format is in long algebraic notation.
A nullmove from the Engine to the GUI should be send as 0000.
Examples:  e2e4, e7e5, e1g1 (white short castling), e7e8q (for promotion)

I wrongly called it portable algebraic notation, but it is not the long algebraic notation either. In chessprogramming wiki it is called pure algebraic notation ie like the long algebraic notation but without decorative hyphen, moving piece, etc.

[Sopel]

It would be a cool feature of a notation that it could be read in two directions, though.

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 but includes castling rights and ep square)and even used it for a chess position database to support going backward . It's fun, but requires too much information for a general purpose notation (I managed to compress it only to 27 bits in a packed binary implementation too, compared to what, like 12 bits for normal move?), so I'm not sure why the original proposal is trying to include it. It is however very useful for identifying transpositions in a database.

I'll allow to repeat myself - what's wrong with uci notation?

[mvanthoor]

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.

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

- Raa8 vs. Rea8
- R1a5 vs. R7a5

Etc... crap like that makes me not to even want to implement a PGN / SAN parser.

The problem that I do see is that SAN is widespread. Using this new notation would break compatibility with old programs. When parsing files, one would always have to be prepared to accept SAN to not break compatibility. That basically voids all positive aspects of any new standard (since we would have to be able to read the old one, anyways).

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

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

[Sopel]

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.