In light of some recent discussions on this forum I came up with the idea of a move notation that would be both reasonably readable by humans and optimised for processing speed.
The notation is case-sensitive; only ASCII characters are used.
A move record MUST consist of the following seven characters:
Moved piece ('P', 'R', 'N', 'B', 'Q' or 'K').
Source file ('a'-'h').
Source rank ('1'-'8').
Captured piece ('-', 'P', 'R', 'N', 'B' or 'Q').
Destination file ('a'-'h').
Destination rank ('1'-'8').
Promoted piece ('-', 'R', 'N', 'B' or 'Q'), or '.' for e.p. capture, or source rook file ('a'-'h') for castling.
This should cover chess and chess960, and should be fairly easy to extend to support other variants (like shogi).
I'd love to hear your feedback (in a polite and respectful manner, please).
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. 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).
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.
abulmo2 wrote: ↑Mon Nov 29, 2021 6:28 pm
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)
Last edited by dangi12012 on Mon Nov 29, 2021 6:58 pm, edited 1 time in total.
leanchess wrote: ↑Mon Nov 29, 2021 4:57 pm
In light of some recent discussions on this forum I came up with the idea of a move notation that would be both reasonably readable by humans and optimised for processing speed.
The notation is case-sensitive; only ASCII characters are used.
A move record MUST consist of the following seven characters:
Moved piece ('P', 'R', 'N', 'B', 'Q' or 'K').
Source file ('a'-'h').
Source rank ('1'-'8').
Captured piece ('-', 'P', 'R', 'N', 'B' or 'Q').
Destination file ('a'-'h').
Destination rank ('1'-'8').
Promoted piece ('-', 'R', 'N', 'B' or 'Q'), or '.' for e.p. capture, or source rook file ('a'-'h') for castling.
This should cover chess and chess960, and should be fairly easy to extend to support other variants (like shogi).
I'd love to hear your feedback (in a polite and respectful manner, please).
On 4/7 why would you not just omit the - if no piece was captured? to have 7 characters always?
On 7 I think e.p. capture is clear on itself. You move the pawn diagonally but the target square is empty.
leanchess wrote: ↑Mon Nov 29, 2021 4:57 pm
In light of some recent discussions on this forum I came up with the idea of a move notation that would be both reasonably readable by humans and optimised for processing speed.
The notation is case-sensitive; only ASCII characters are used.
A move record MUST consist of the following seven characters:
Moved piece ('P', 'R', 'N', 'B', 'Q' or 'K').
Source file ('a'-'h').
Source rank ('1'-'8').
Captured piece ('-', 'P', 'R', 'N', 'B' or 'Q').
Destination file ('a'-'h').
Destination rank ('1'-'8').
Promoted piece ('-', 'R', 'N', 'B' or 'Q'), or '.' for e.p. capture, or source rook file ('a'-'h') for castling.
This should cover chess and chess960, and should be fairly easy to extend to support other variants (like shogi).
I'd love to hear your feedback (in a polite and respectful manner, please).
From an efficientcy standpoint I would omit captured piece as this is clear from the moves anyway. Also you dont have to write out which piece you moved.
A small ascii move would be from / to squares in base64 - with promotion encoded as a backwards/diagonal move of 1...5 squares to have that piece and one of the 3 promotion squares encoded.
First 3 moves:
IQ 4w QY
https://en.wikipedia.org/wiki/Base64
Readability is not given i guess. But its interesting anyways since a parser could just read the characters and know what to do with a mailslot array with 2 special cases for castling and EP.
dangi12012 wrote:No one wants to touch anything you have posted. That proves you now have negative reputations since everyone knows already you are a forum troll.
Maybe you copied your stockfish commits from someone else too?
I will look into that.
Perhaps I didn't state my goals sufficiently clearly.
Firstly, the idea was to optimise for speed, not for space. Second, the notation should remain human-readable.
As part of the speed optimisation, it should be self-contained, i.e. translate to a data structure requiring nothing else for performing make/unmake. Does it make any sense?
I am hoping to include this in a proposal for a PGN alternative in the vein of the recently proposed JSON Game Notation. Unfortunately, the discussion in that thread deteriorated beyond all repair, so I'm inclined to create a new topic for that.
leanchess wrote: ↑Mon Nov 29, 2021 7:27 pm
Perhaps I didn't state my goals sufficiently clearly.
Firstly, the idea was to optimise for speed, not for space. Second, the notation should remain human-readable.
As part of the speed optimisation, it should be self-contained, i.e. translate to a data structure requiring nothing else for performing make/unmake. Does it make any sense?
I am hoping to include this in a proposal for a PGN alternative in the vein of the recently proposed JSON Game Notation. Unfortunately, the discussion in that thread deteriorated beyond all repair, so I'm inclined to create a new topic for that.
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
