As well as https://en.wikipedia.org/wiki/Levenshtein_coding which also encodes iterated lengths.

Agree, I had to ask ChatGPT to explain this to me with an example number and then I was able to understand the approach.

Well the good news is that multiplication of n-bit numbers simplifies to handling the sign and adding n-1 bit numbers.

For low bit representations, you could just pre-calculate all the possible answers and cache those. A simple algorithm would be to decode numbers, do the arithmetic, and re-encode the answer. With the seven bit example used in the article, there are only 2^7 = 128 unique numbers. So you'd need 16KB of memory to store all possible multiplications. With 16 bit numbers that grows to 4GB. Beyond that, it probably gets too expensive rapidly. You might get some optimizations out of the symmetry for positive and negative.

That's exactly the crux. Addition and subtraction in log space is not exactly straight-forward.

Exact integers doesn't seem to be its strong suite. Can it even represent 3 exactly?

Running code from the linked notebook (https://github.com/AdamScherlis/notebooks-python/blob/main/m...), I can see that a 32 bit representation of the number 3 decodes to the following float: 2.999999983422908

(This is from running `decode(encode(3, 32))`)

> Given an integer n, what is the number of bits required to represent every integer in the range -n..n ?

(log n) + 1

It is not. (There are no square roots, for instance.)

Not really. Dirac's trick works entirely at a depth of two logs, using sqrt like unary to increment the number. It requires O(n) symbols to represent the number n, i.e. O(2^n) symbols to represent n bits of precision. This thing has arbitrary nesting depth of logs (or exps), and can represent a number to n bits of precision in O(n) symbols.

It was. It's a variant of Dirac's solution to representing any number using sqrt, log, and the number 2.

> Does that mean that the 8 bits version has numbers larger than this?

Yes. Not just a bit larger but an even more ridiculous leap. Notice that you're iterating exponents. That last one (7 bits) was 2^65536 so the next one (8 bits) will be 2^2^65536.

Python objects to 2^65536 complaining that the base 10 string to represent the integer contains more than 4300 digits so it gave up.

> Doesn't seem very useful

By that logic we should just use fixed point because who needs to work with numbers as large as 2^1023 (64 bit IEEE 754). These things aren't useful unless you're doing something that needs them, in which case they are. I could see the 5 or 6 bit variant of such an iterated scheme potentially being useful as an intermediary representation for certain machine learning applications.

Who said anything about practical purposes?