3 ms·
Some thoughts I had while reading this, probably not very original: the fact that chess moves are not random and usually adhere to opening theory to some degree
by evertedsphere 3y ago
Some thoughts I had while reading this, probably not very original: the fact that chess moves are not random and usually adhere to opening theory to some degree means you could get some value out of using something like a trie of some small finite depth, trained on a database of games, to compress common opening lines much better, at the cost of making things like 1. a4 a5 2. h4 h5 that aren't in the trie much costlier to represent. A practical way to actually do this would likely look like applying arithmetic coding to all of the possible length-N prefixes of the game.
The mid- or lategame are also far from random and could probably be compressed in small "chunks" via a coder that would (effectively) learn to predict patterns of e.g. capture being followed by a recapture and cause such chunks to require fewer bits to represent.
I'm not very knowledgeable about compression algorithms, though; I'm sure others will be able to provide corrections or references.
- Spark_Ed 3y agoYou can reference specific move numbers from specific master games to compress. But you still need to compress how you store those master games. What you're describing for mid/late game might make more sense like this: you use a fixed version of stockfish to suggest moves (depth and version should be locked to static values so it reproduces the same engine move each time). If it's within the first 8 suggestions, you can flag that it's an engine move with 4 bits. Decompression time is significantly larger, but it maximizes the space for cpu trade-off.
- andruby 3y agoThat's exactly what the author seems to have done and describes in their subsequent post: https://mbuffett.com/posts/compressing-chess-moves-even-further/ https://mbuffett.com/posts/compressing-chess-moves-even-furt... (published yesterday)