81–83 of 83 posts
Earlier quoted context omitted.
Hex is worse, see here [1] for UUIDs [1] https://news.ycombinator.com/item?id=39094251
I'm not confident of the math there. https://i.imgur.com/cAVbqka.png Because of quirks, in edge cases decimal is more efficient, but overall alphanumeric is better in QR code.
We have a similar problem at work right now, but due to different constraints we've settled on Base85. Slightly denser than Base64, but still just plain old printable ASCII characters and the following characters are still "free" so one can use them as field delimiters in a CSV-style format: "',/[]\ Incidentally, this also makes them JSON-Safe. Base94 uses all printable characters, and Base122 uses both printable cha…
I'm not following as Base85 isn't JSON safe. For example, { and } carry meaning in JSON.
Earlier quoted context omitted.
127 bit integers get 38 digits, which lines up well with 128 bit integers
No, they get 39 decimal digits (1.7e38 is 39 decimal digits). 127bit chunks would get you 2.36% overhead, which is not bad. However at 93bit chunks can (barely) be encoded in 28 digits (2^93 ~= 9.9e27) and it's more efficient at around 0.36% overhead. So once you have 128 bit arithmetic, it's still not worth using all or most of those bits per chunk, 93bit chunks is the most efficient under 128 bits.