How to store a chess position in 26 bytes (2022)

Post by nurettin » Sat, Jan 10, 2026, 12:23 PM UTC

01092026 wrote: post #81

nurettin wrote: post #79

Earlier quoted context omitted.

Yes 9 bits is 2 bytes. The article confusingly says 18 bits = ~2 bytes. It is the "about 2 bytes" that is confusing. They probably mean that an extra bit won't matter too much since we are bit packing the games in a contiguous stream. BUT In the article they don't mean that 00000034 is a bit or a byte. It is one of the possibilities and there are 495 of them and if you index each possibly in a 2 byte integer, you can…

You understand me, this is most important. And thank you for explaining this exercise - but to be honest, if the article says "How to store a chess position in 26 bytes" And you actually cannot store this in 26 bytes based on your implementation, and then you show integer bits and bytes that aren't even binary...eh. And to be honest, like how about we store the chess position in 1 bit. I will execute some chess posit…

Post by undeveloper » Sat, Jan 10, 2026, 12:39 PM UTC

NooneAtAll3 wrote: post #92

what's wrong with scrolling on that blog? arrow keys don't work

Post by jonsoft » Sat, Jan 10, 2026, 12:50 PM UTC

leothetechguy wrote: post #88

I remember asking myself this question years ago, and came to 162 bits. I was just a kid back then so the logic is probably wrong but I do wonder how simple the encoding could be under those constraints... Edit: Here are the Notes 0 Empty 10 Pawn 1100 Knight 1101 Rook 1110 Bishop 1111 Queen 32 + 32 + 4 7 2 2 times 6 bits: position of the kings 30 bits: color mask 120 + 2*6 + 30 = 162 bits We can store the rest using…

Post by tromp » Sat, Jan 10, 2026, 1:14 PM UTC

jonsoft wrote: post #95

leothetechguy wrote: post #88

I remember asking myself this question years ago, and came to 162 bits. I was just a kid back then so the logic is probably wrong but I do wonder how simple the encoding could be under those constraints... Edit: Here are the Notes 0 Empty 10 Pawn 1100 Knight 1101 Rook 1110 Bishop 1111 Queen 32 + 32 + 4 7 2 2 times 6 bits: position of the kings 30 bits: color mask 120 + 2*6 + 30 = 162 bits We can store the rest using…

Each pawn that wants to be promoted either takes: (a) another 'special' piece (knight/rook/bishop/queen), in which case it has already bought enough bit budget to later be promoted; or (b) another pawn, in which case this temporarily saves 1 bit (as the other pawn becomes a space), but then later we need 2 extra bits for the promotion, so we pay 1 bit extra per pawn in total In the case of (b) there are now fewer paw…

Post by [deleted] » Sat, Jan 10, 2026, 1:50 PM UTC

tromp wrote: post #84

jstanley wrote: post #83

> Since each position takes up 6 bits ($2^6 = 64$), multiplying 6 bits by 32 pieces gives us 192 bits / 24 bytes (1 byte = 8 bits). But each position can only be used once, so you really only have 64*63*62*61*...*33 possibilities = 64!/32! = ~2^53, so you could encode this with less than 7 bytes, and then use the basic 12-byte encoding for captures, castling, en-passant, and promotions, and you are below 19 bytes in…

Multiplying 32 numbers each over 5 bits long obviously results in more than 160 bits. 64!/32! > 2^178.3