5 ms·

> piece at square (nibble, nibble) moves to square (nibble, nibble) Chess notation is very compact, you don't even need to say where the starting piece was in

> piece at square (nibble, nibble) moves to square (nibble, nibble) Chess notation is very compact, you don't even need to say where the starting piece was in most cases because it's implied by the move. If you have 2 rooks on A1 and H1, and the move says rh4, only one of your rooks can legally make that move. However if the move was rc1, both rooks could make that move so you do need to disambiguate.

permo-w 4y ago
presuming that the cheater communicates with the system through some form of physical pressure, they could probably use a modified Morse code re-optimised for the frequency of letters in chess notation. according to wikipedia[1] this already exists and was developed for telegraph and radio transmission of chess games, although I have no idea how well optimised it is [1] - https://en.wikipedia.org/wiki/Chess_notation https://en.wikipedia.org/wiki/Chess_notation
mabbo 4y ago
That suggests a fun strategy for Magnus or anyone else playing Niemann: do lots of moves where there would be ambiguity in which piece was moved. Now however Niemann is entering the moves, he's got more to type and more places he might make a mistake.
- permo-w 4y ago
  this is one of the reasons it may be best to find another method. one I thought of is to rank all the squares from most-used to least-used, then assign each of them a Morse code, simplest first. 64 squares is 2^6, so the maximum length input you would ever need is six. given a usage frequency for each of the squares, you could calculate your average input length by the sum of all len(square_code) * square_frequency divided by 64. assuming all squares are the same frequency (1/64), it's just the sum of all len(square_code) divided by 64, which I believe comes out at 322/64 = 5.03125, although I could be wrong about that. this makes your maximum necessary input per move 12 bits, but your average will be lower, depending on the frequency distribution of squares. (ignoring castling and en-passant for a moment) this is 2 bits more than using a piece+target square technique

permo-w 4y ago

presuming that the cheater communicates with the system through some form of physical pressure, they could probably use a modified Morse code re-optimised for the frequency of letters in chess notation. according to wikipedia[1] this already exists and was developed for telegraph and radio transmission of chess games, although I have no idea how well optimised it is [1] - https://en.wikipedia.org/wiki/Chess_notation https://en.wikipedia.org/wiki/Chess_notation

mabbo 4y ago

That suggests a fun strategy for Magnus or anyone else playing Niemann: do lots of moves where there would be ambiguity in which piece was moved. Now however Niemann is entering the moves, he's got more to type and more places he might make a mistake.

permo-w 4y ago
this is one of the reasons it may be best to find another method. one I thought of is to rank all the squares from most-used to least-used, then assign each of them a Morse code, simplest first. 64 squares is 2^6, so the maximum length input you would ever need is six. given a usage frequency for each of the squares, you could calculate your average input length by the sum of all len(square_code) * square_frequency divided by 64. assuming all squares are the same frequency (1/64), it's just the sum of all len(square_code) divided by 64, which I believe comes out at 322/64 = 5.03125, although I could be wrong about that. this makes your maximum necessary input per move 12 bits, but your average will be lower, depending on the frequency distribution of squares. (ignoring castling and en-passant for a moment) this is 2 bits more than using a piece+target square technique