# Long algebraic notation-piece promotion

I am building a chess engine with the use of Artificial Intelligence, and I am almost done as long as the AI and the internal game mechanics are concerned.

Currently I am training the AI and I want to get it to play with as many other AIs as possible. As I was searching, I came across the Arena interface which makes possible exactly what I want.

So I began to modify my engine to meet the specifications required for this to work and here is where my question lies. To be more specific, Arena uses the UCI protocol to make two engines communicate.

In the UCI protocol, the move format is in long algebraic notation. I would like to know how exactly long algebraic notation differs from algebraic notation, and more specifically how pawn promotion is represented.

• This forum is not really for discussion about communication formats between robots. Further, the information you seek is plainly available with a straight-forward search. Commented Sep 10, 2016 at 15:26
• In my opinion this is a question about notation, which is relevant to the site. A related question can be found here: chess.stackexchange.com/questions/2895/… Commented Sep 20, 2016 at 6:33
• Well, nobody uses long algebraic notation ever, so I guess it's not a question about chess notation. I am a bit tired of computer nerds invading every single Stack community Commented Jun 13, 2019 at 22:58

Most games published for human study are written in short algebraic notation. For each move, the destination square is always specified, the moving piece is specified unless it's a pawn (in which case the origin file is specified for captures only), and if there's any ambiguity the origin rank and/or file is given to resolve it. Captures are indicated by inserting 'x' before the destination square. Promotion is indicated using eg. "=Q" suffix. Additional suffixes are used to indicate check, mate, and move quality.

Long algebraic notation is just like the above, except that the origin square is always exactly specified, and usually a '-' is inserted in place of the 'x' for non-captures. So Re1 might become Ra1-e1. The same suffixes are used, and castling is still specified using O-O type notation.

English descriptive notation is somewhat more arcane, and may specify only the piece identities if the resulting move is unambiguous, eg. RxB. It is now considered obsolete, though you might find it in old literature. I don't think it is used in any engine protocols. The same goes for foreign-language piece name abbreviations, eg. German chess uses Springer (S) instead of Knight (N).

The UCI protocol uses none of the above notations, but merely specifies the origin and destination squares; the only suffix is a single letter to disambiguate pawn promotions. So exd8=N in short algebraic would become e7xd8=N in long algebraic, but e7d8n in UCI (all in lowercase). Castling is specified by moving the king two spaces (in standard chess) or onto the corresponding rook (in 960) instead of in shorthand notation.

• Shouldn't "e7d8N in UCI" above read "e7d8n in UCI"? Commented Feb 9, 2021 at 16:28
• @MartinRattigan Apparently so. I cleaned up one or two other points as well. Commented Feb 10, 2021 at 18:53

The following open source program: pgn-extract can do a lot of manipulations with PGN files among others convert them to long algebraic notation. I expect that you are familiar with the short algebraic form so if you want to learn the difference between these two form of notations you could convert some of your short games to long and look at the cases you are in doubt about. An alternative since it is an open source program is that you use the code from that in your code to convert from short to long and vice versa.

• I realise this is an old question now, but I am the author of pgn-extract, so if the OP or anyone else wants to go the code editing route for something like this, they should feel free to get in touch with me personally if they need any assistance with it. I could also offer them source to an alternative to the full pgn-extract program that might be easier to work with. Commented Jun 13, 2019 at 21:26