At 10:59 AM -0700 7/24/08, Henry Baker wrote:
I haven't had time to grok your whole message, but one thing popped into my mind: asinh(x).
Yes, I'm a fan of asinh too. You forgot to mention the binary patterns in asinh-base-2 also. Asinh and sinh let you directly encode and decode a set of numbers like floating point represents, all with the same word length (uniform probabilities but changing resolution). If you treat asinh( kn ) as the cumulative probability for integers up to some max absolute value, then my method gives you a variable-length code using about log(|n|) bits for n. The implied distribution is like a two-sided Zipf (varying probabilities but uniform resolution). I was led to another function by the wikipedia entry on universal codes: Andrew Robbins' method of approximating what everyone hopes is a unique analytic version of the e^(e^(e^...)) (n times) function: http://tetration.itgo.com/paper.html Actually I mean the inverse, his "slog" or "superlog" function. Floating point and asinh let you represent googles; slog gives a key "To the Googleplex and Beyond!" But it's asymmetrical and doesn't give really small numbers either, not sure how to adapt it for use. I still have not figured out what is being optimized or approached by log(x)+log(log(x))+log(log(log(x)))... ( or more likely log(1+x) + log(1+log(1+x)) + log(1+(log(1+log(1+x)))... ). This is similar to the growth of Elias' Omega code, but what it optimizes may only be: fit to the distribution implied by that-- It seems virtuous or inevitable but I don't know why. --Steve