# Would you accept a compressed number format to replace Float64 and integers if you had to opt into a package?

**URL:** https://discourse.julialang.org/t/would-you-accept-a-compressed-number-format-to-replace-float64-and-integers-if-you-had-to-opt-into-a-package/88122
**Category:** General Usage
**Created:** [October 2, 2022, 2:01pm UTC](https://discourse.julialang.org/t/would-you-accept-a-compressed-number-format-to-replace-float64-and-integers-if-you-had-to-opt-into-a-package/88122 "2022-10-02T14:01:02Z")
**Posts on this page:** 1
**Page:** 1

<div class="post-metadata">

### Author: ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)
#### Post date: [October 2, 2022, 2:01pm UTC](https://discourse.julialang.org/t/would-you-accept-a-compressed-number-format-to-replace-float64-and-integers-if-you-had-to-opt-into-a-package/88122/1 "2022-10-02T14:01:02Z")

</div>

[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)?

> **[Why is 0.1 + 0.2 Not Equal to 0.3 in Most Programming Languages?](https://betterprogramming.pub/why-is-0-1-0-2-not-equal-to-0-3-in-most-programming-languages-99432310d476)**
>
> It equals 0.30000000000000004

> **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](https://en.wikipedia.org/wiki/Apollo_Guidance_Computer)

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
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?