3 ms·

Why is a displaying 32 bits, rather than 16, per rune actually a useful idea? Why even, when MIME and USENET encodings like yyenc are denser, and hex aligns so

Why is a displaying 32 bits, rather than 16, per rune actually a useful idea? Why even, when MIME and USENET encodings like yyenc are denser, and hex aligns so well? They toss out a 40 bit number as an example, but who even uses that? What even is it, a truncated hash? A 32 or 64 bit truncation is just as valid, and using a range of 1, 16, 256, 4096, or 65536 buckets (zero to four letters) seems to be just as valid. EDIT (add this paragraph): Use cases for labeling involve 4 and 8 characters of 32-bit runes, but that's 4 vs 5 and 8 vs 10 hex characters. The hex characters are practically self-documenting, and as I noted in another part of the criticism an hour ago, the folding / skipping of some characters could cause someone to wonder where missing elements of a set are. No array or lookup table or spec definition is required for hex, which would be better in this use case than any 32-bit rune system. Additionally, Hex natively extends decimal in a natural way that doesn't skip any letters. The skipped letters actively make me worry that in a list of folders someone might believe there are missing locations. Our computational systems are currently based on powers of 2, because we use binary logic, and binary addresses. This is so powerful that the base set for text standardized on a friendly power of 2 within the useful range, 8, instead of other popular sizes at the time a couple decades ago. Octal encoding numbers only represents 3 bits, this is inconvenient enough that hex encoding became popular. Representing 4 bits per display character to align with base 2 alignments (as well as expanding the encoding of a single octet-byte, which was the defacto minimum unit of addressing in popular architectures, to exactly twice it's normal storage / display footprint).

yellowapple 6y ago
> Why is a displaying 32 bits, rather than 16, per rune actually a useful idea? To be clear: base-32 systems (including Base32H) use 5 bits per rune, which means... > A 32 or 64 bit truncation is just as valid, and using a range of 1, 16, 256, 4096, or 65536 buckets (zero to four letters) seems to be just as valid. ...base-32 systems would naturally produce 1, 32, 1024, 32768, or 33554432 buckets for that same range of letter counts. Base-64 systems would produce even better numbers of buckets within that range of letter counts, but (as outlined in the "Comparisons" page) it comes at the expense of case-sensitivity.
- mjevans 6y ago
  I was just updating my earlier reply after I thought to look at their use cases page. I should write a better criticism about that. Usernames: No, store them as given, just like real names. Also, use UTF-8. Consult the visual rendering engine for decomposing the value to display units, or a rendered result, etc. Asset tags: Just use hex, or numbers. Mortal people looking at either of those systems understand them quickly enough without further documentation. It's only 4 vs 5 letters, worth the lack of a binder describing why you're not missing crates. Cheat codes: This is actually fine, I don't care, it isn't important. Though hex or anything else is just as fine. Cryptography: Less possible artifacts from less letters. 0123456789ABCDEF typically don't contain any difficult to read or alias characters for dyslexic or other non-perfect readers. If density matters (again 4 vs 5) no printed media is going to work out. Geographic coordinates / addresses: Everyone's using base 10 here, either as big floats or as sets of numbers that are friendly to read. Those articles that have average consumers use an app and send 3 words back from it are making up for the missing safety feature of 911 sending a well formatted set of SMS messages with the call indicating the handset's current GPS data.

yellowapple 6y ago

> Why is a displaying 32 bits, rather than 16, per rune actually a useful idea? To be clear: base-32 systems (including Base32H) use 5 bits per rune, which means... > A 32 or 64 bit truncation is just as valid, and using a range of 1, 16, 256, 4096, or 65536 buckets (zero to four letters) seems to be just as valid. ...base-32 systems would naturally produce 1, 32, 1024, 32768, or 33554432 buckets for that same range of letter counts. Base-64 systems would produce even better numbers of buckets within that range of letter counts, but (as outlined in the "Comparisons" page) it comes at the expense of case-sensitivity.

mjevans 6y ago
I was just updating my earlier reply after I thought to look at their use cases page. I should write a better criticism about that. Usernames: No, store them as given, just like real names. Also, use UTF-8. Consult the visual rendering engine for decomposing the value to display units, or a rendered result, etc. Asset tags: Just use hex, or numbers. Mortal people looking at either of those systems understand them quickly enough without further documentation. It's only 4 vs 5 letters, worth the lack of a binder describing why you're not missing crates. Cheat codes: This is actually fine, I don't care, it isn't important. Though hex or anything else is just as fine. Cryptography: Less possible artifacts from less letters. 0123456789ABCDEF typically don't contain any difficult to read or alias characters for dyslexic or other non-perfect readers. If density matters (again 4 vs 5) no printed media is going to work out. Geographic coordinates / addresses: Everyone's using base 10 here, either as big floats or as sets of numbers that are friendly to read. Those articles that have average consumers use an app and send 3 words back from it are making up for the missing safety feature of 911 sending a well formatted set of SMS messages with the call indicating the handset's current GPS data.