Live data from Hacker News

How to store a chess position in 26 bytes using bit-level magic (2022)

ezzeriesa.com

21–30 of 204 posts

Re: How to store a chess position in 26 bytes using bit-level magic (2022)

#21
It’s been a minute since I did this seriously so maybe my magic is out of date but I don’t think this is how bits to bytes works:

> 100 bits / ~12 bytes

> 18 bits / ~2 bytes

I didn’t want to spend a whole lot of effort tracking the arithmetic after this. Was it actually 28 bytes? 27 because I can squeeze those extras into one shared byte?

Re: How to store a chess position in 26 bytes using bit-level magic (2022)

#22
post #6
post #4

Original title is: > Compressing chess positions for fun and profit Which unlike that here is correct: you can store a board , the positions, in 26B; not an arbitrary length game!

Most games could possibly be encoded in less than 26 bytes. There are not that many legal moves each time and if you sort them by probability it may not require many bits to describe which one the players chose.

A Huffman code ...? The starting board is 0, 1.e4 is 1, etc...

Re: How to store a chess position in 26 bytes using bit-level magic (2022)

#23
post #17
post #5

Meanwhile the non-comp-sci dev in me is like, "why not just store every position in a simple JSON so everyone can read it and everything can parse it". Yeah, it might be half a kB, but you don't have to run through mental gymnastics just to render the pieces...

You need a compact encoding for chess engines that explore billions of states as fast as possible to plan the best move.

Well, this is arguably a kind of compression, right? So you'd be trading CPU time for fewer bytes? Is that a desirable tradeoff at chess engine scales?

Re: How to store a chess position in 26 bytes using bit-level magic (2022)

#24

There are two more things that should be considered. Both of them unlikely to influence a position, but they can matter - just like the en passant target. The fifty move rule[0] is quite simple, just store a number, fits in five bits. But the threefold repetition rule[1] is quite a pickle - it basically means that to know everything about a position you need to know every position that occurred before it. [0] https:/…

Not all previous positions, only the ones with the same pieces, pawn positions, castling rights and en passant rights.

But the standard, FEN, doesn't store that either. It's used more in the context of a full game than with individual positions.

Re: How to store a chess position in 26 bytes using bit-level magic (2022)

#25
post #5

Meanwhile the non-comp-sci dev in me is like, "why not just store every position in a simple JSON so everyone can read it and everything can parse it". Yeah, it might be half a kB, but you don't have to run through mental gymnastics just to render the pieces...

While we're at it, just take a screenshot of the board

Re: How to store a chess position in 26 bytes using bit-level magic (2022)

#27
post #5

Meanwhile the non-comp-sci dev in me is like, "why not just store every position in a simple JSON so everyone can read it and everything can parse it". Yeah, it might be half a kB, but you don't have to run through mental gymnastics just to render the pieces...

Mostly for automation. Bots don't need to read and they are very happy to parse data.

People like to use bots to run thousands or millions of simulated games to test how good their bot is at chess and have it ranked.

Other people like to use the bots that were created to play chess as practice toward a certain skill level. Beginners can pick bots that are proven to be beginner level, through thousands or millions of simulated games.

The smaller the data footprint for the games, the faster and more efficiently the bots can play, which reduces cost and time. In a more practical sense, AI/ML algorithms can be more efficient with tiny data sizes for a bunch of complicated reasons.

So, overall, this is "nerd sniping" to develop better chess players, both human and automated. It's not the most extensible presentation, I'll grant you, but I'm sure it's as fun as Regex Golf, or any other data-packing stuff.

P.S. I'm sure the comp-sci dev in you already knew all this; this is just a bill in case anyone read your comment and truly didn't already know all of this.

Re: How to store a chess position in 26 bytes using bit-level magic (2022)

#28
post #17

Earlier quoted context omitted.

You need a compact encoding for chess engines that explore billions of states as fast as possible to plan the best move.

Well, this is arguably a kind of compression, right? So you'd be trading CPU time for fewer bytes? Is that a desirable tradeoff at chess engine scales?

Is your assertion that it takes more time for a CPU to read values out of a 30 byte struct and do a couple shifts and branches than to parse a JSON representation?

Re: How to store a chess position in 26 bytes using bit-level magic (2022)

#29
post #15

An interesting cognitive phenomenon: if you ask chess experts and novices to memorize and recall an arbitrary chessboard, the experts are significantly better than the novices _only if_ the board is a legal board that can be arrived at during play. If it is not a legal board, there's no particular difference between novices and experts. Original ref: Chase & Simon 1973, Perception in Chess. This is usually taken to m…

It's not really about whether it's legal, but whether it looks normal. Very bizarre positions can easily be legal, but they're hard to remember for everyone.

Re: How to store a chess position in 26 bytes using bit-level magic (2022)

#30

Storing a chess position in 26 bytes. Storing a game is also interesting. The number of legal moves varies depending on the position. You could try to define a variable length encoding by giving more likely moves a shorter encoding, but the ordering would need to be deterministic so it could be decoded (running Stockfish for a second isn't).

Finally, a good use case for blockchain technology!
Post reply on HN