3 ms·
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 N
by 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 agothis 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