[Please don’t move to numerics, at least yet, I would like to know if regular users would use such a package.]
First I want to tell new users like @pppoe5 that Julia already supports checked overflow of integers in a package, the reason it’s not the default (or BigInt), is that it’s considered slower, but I don’t think it has to be. Why do I think I can do integers better, that default in Julia, when Python fails at doing it fast, and also improve on Float64 (e.g. the default for all numbers in JavaScript)?
Problem statement: How is it that
0.1 + 0.2 = 0.30000000000000004?
How far would 15-bit numbers get us? They got us to the moon (and back) the first time around with: Apollo Guidance Computer - Wikipedia
My proposal in not a binary fixed point, nor decimal numbers, that would fix the above number (Decimal64/32 is already supported with Julia package), the standard is too slow, I propose base 300 by default.
That means 0.01, 0.02 up to 54.61 is accurate (in 15 bits but I would support basically all Float64 numbers accurate too, and more), in my proposal, this is not the full proposal, but with similar properties:
julia> decompress(n::Float16) = n / 300
julia> compress(n::Float64) = Float16(n * 300)
1/3 (and 0.1) would also be accurate, but in Float16 0.02% off.
Now back to integers, having 54 max is rather limiting, but in my proposal up to 2²⁶ on the fast path is good enough for most. But wait, that wouldn’t fit into 15-bit numbers…? Yes, and no.
I intend to encode 4 numbers into 64 bits. That could be 4*15-bit + plus 1 bit to signal fast path, and three left over to maybe have a shared exponent.
But another fast path would have the first number be 26-bit integer, and the rest have fewer bits. My goal is to be able to encode any place on earth (and some value, e.g. temp), in 64-bits, e.g. latitude, longitude and height.
My believe is that even though decoding (but more so encoding) isn’t always fast, I could get it fast enough, and the 4 times memory bandwidth will make it up.
But what about full Float64? and four of those? A bit-pattern would indicate exceptional numbers would be stored elsewhere, and the 64-bits would be a pointer to it. Then the speed is no longer deterministic, but neither does IEEE guarantee that (though is often single cycle), and I would point to four Float64, or even four BigFloat?