31–40 of 46 posts
- "Golden ratio base is a non-integer positional numeral system" (2023) https://news.ycombinator.com/item?id=37969716
Number systems > Classification: https://en.wikipedia.org/wiki/Number#Classification ; N natural numbers, Z[±] integers, Q rational/s, R Reals, C complex numbers (with complex conjugate exponents), Infinity or Infinities, ; C ⊆ R ⊆ Q ⊆ Z ⊆ N
***
i^4x ~= e^iπx
e^(x*yi*zπ)
e^(x*yi*zπ) * e^(a*bi*cπ)
sign * e^(x*yi*zπ) * e^(a*bi*cπ)
sign * e^(x*yi*zπ)
A few other bases that are interesting: Base36: 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ Good encoding for binary data in textual contexts. Such as where you have parameter inputs or database fields that are constrained and only accept certain characters. The lack of spaces means that it can be used on the command-line easily. Example use: IRC channel names. Base64: 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrs…
> base36 textual contexts Better IMO is base 32 with U (obscenity), 0/O (ambiguity), and I (ambiguity) removed.
Hey Piotr/pchm, I'm not sure I follow your argument that Base32 is less popular because it's not a standard (there is a standard - RFC4648 as you mention). Not implementing the RFC, is not implementing Base32, changing the order, or using 32 emoji does not make it Base32. Put another way, you can change the order of characters in Base64, or use a different dictionary, and indeed there are several variants of that too…
You make some good points. What I was trying to say is that even though there is the RFC, it's quite common to modify the alphabet or use other variants like Crockford's (mainly to avoid random profanity, e.g. in the URL identifiers). When you see a Base64 string, you can be pretty certain that it's the standard version. With Base32, it's not obvious which variant was used. Many languages don't provide a stdlib Base3…
Base64 is very close to the Schelling point of Base62 i.e. [A-Za-z0-9], requiring only a couple more additional decisions to be made: which two extra characters to add.
Unfortunately the original Base64 inexplicably got this wrong and chose + and / instead of the more sensible choice of - and _
I’m a big fan of base58 + almost as efficient as base64 + no special characters + no padding characters
Unlike Base64 or Base32, Base58 has approximately O(N^2) complexity because it requires iterative division and multiplication operations on big integers. You can't encode a gigabyte of data with Base58 in a reasonable time, but you certainly can with Base64 or Base32.
> u8 divmod 58 can be reduced to a u8->u16 multiply, a right shift, and three conditional subtractions; that's not great, but on a modern CPU it's a afterthought compared to the quadratic loop over the input size.
Same topic from 2018: https://news.ycombinator.com/item?id=18409344
I’m a big fan of base58 + almost as efficient as base64 + no special characters + no padding characters
Unlike Base64 or Base32, Base58 has approximately O(N^2) complexity because it requires iterative division and multiplication operations on big integers. You can't encode a gigabyte of data with Base58 in a reasonable time, but you certainly can with Base64 or Base32.
Earlier quoted context omitted.
Base64 uses / and +
Sometimes. Other times those chars are not allowed in the embedding context (paths, for instance), so you have to use '+' and ','. Or maybe '_' and '-'.
> This encoding [using '-' and '_'] may be referred to as "base64url"... Unless clarified otherwise, "base64" refers to the base 64 in the previous section ['+' and '/'].