I’ll likely be making a package later, but this may already be useful for someone. I though about posting under performance category, but so far decided against, since I’m not (yet) asking for tuning advice, but this would of course help others, with performance; memory-bandwidth.

I’ll first show the (potential) downsides. Likely fixed by B. ~~when bug found~~.

A.

```
julia> decode_8(encode_8((-0.0, 12.0, 3.0, 4.0, 12.0, 3.0, 5.0, 1/3)))
(0.0, 12.0, 3.0, 4.0, 12.0, 3.0, 5.0, 0.3333333333333333)
```

You do not get signed zero back (and that’s before I bring Posits into the mix, they neither support, so you may want to get used to live without them). Will they be missed?

My goal (one of) is representing 1/3 exactly in floats (posits), and that seems possible by scaling all numbers by 3 (so binary base-2 * 3 = base-6 floats).

As people may know 0.3 (like 1/3, and 0.1) isn’t exact, but/so when I compress, I get:

```
julia> decode_8(encode_8((-0.0, 12.0, 3.0, 4.0, 12.0, 3.0, 5.0, 0.3)))
(1.7763568394002505e-15, 12.0, 3.0, 4.0, 12.0, 3.0, 5.0, 0.3000000000000001)
```

That’s too bad. Code so far:

```
julia> function encode_8(tuple; scale = 3.0)
(a, b, c, d, e, f, g, h) = tuple .* scale; mid = (a + b + c + d + e + f + g + h) / 8
(mid, b - mid, c - mid, d - mid, e - mid, f - mid, g - mid, h - mid)
end
julia> decode_8((mid, b, c, d, e, f, g, h); scale = 3.0) = ((mid - b - c - d - e - f - g - h), b + mid, c + mid, d + mid, e + mid, f + mid, g + mid, h + mid) ./ scale
```

B.

```
julia> using SoftPosit
julia> function encode_8p(tuple; scale = 5.0)
(a, b, c, d, e, f, g, h) = tuple .* scale; mid = (a + b + c + d + e + f + g + h) / 8
Posit8.((mid, b - mid, c - mid, d - mid, e - mid, f - mid, g - mid, h - mid))
end
julia> encode_8p((-0.0, 12.0, 3.0, 4.0, 12.0, 3.0, 5.0, 0.3); scale=3.0)
(Posit8(15.0), Posit8(20.0), Posit8(-5.5), Posit8(-2.75), Posit8(20.0), Posit8(-5.5), Posit8(0.25), Posit8(-14.0))
```

EDIT: I figured out the bug from “below”, it’s caused by above. Even thought the numbers seem sensible, Posit8 may not have enough precision. If I take out the averaging stuff, and simply scale it should work.

~~Can’t see the bug:~~

```
julia> function decode_8p((mid, b, c, d, e, f, g, h); scale = 3.0)
(mid, b, c, d, e, f, g, h) = Float64.((mid, b, c, d, e, f, g, h)); ((mid - b - c - d - e - f - g - h), b + mid, c + mid, d + mid, e + mid, f + mid, g + mid, h + mid) ./ scale
end
julia> decode_8p(encode_8p((-0.0, 12.0, 3.0, 4.0, 12.0, 3.0, 5.0, 0.3)))
(0.8333333333333334, 11.666666666666666, 3.1666666666666665, 4.083333333333333, 11.666666666666666, 3.1666666666666665, 5.083333333333333, 0.3333333333333333)
```

C.

I believe(ed) that Posit8 has 2 significant decimal digits, but that’s just max (or I uncovered a bug in SoftPosit.jl, possibly only conversion routine).

So even with no scaling (scale = 1.0 should disable it), I get less accurate than that for last number 0.3:

```
julia> encode_8p((-0.0, 12.0, 3.0, 4.0, 12.0, 3.0, 5.0, 0.3); scale=1.0)
(Posit8(0.0), Posit8(12.0), Posit8(3.0), Posit8(4.0), Posit8(12.0), Posit8(3.0), Posit8(5.0), Posit8(0.3125))
julia> encode_8p((-0.0, 12.0, 3.0, 4.0, 12.0, 3.0, 5.0, 0.3); scale=3.0)
(Posit8(0.0), Posit8(32.0), Posit8(9.0), Posit8(12.0), Posit8(32.0), Posit8(9.0), Posit8(15.0), Posit8(0.875))
The error is larger with the scaling:
julia> 0.3*3-0.875
0.02499999999999991
julia> 0.3-0.3125
-0.012500000000000011
```

@JeffreySarnoff, a potential solution is (your) `using IntervalArithmetic`

.jl. That means the floats take twice the space, I was aiming for 8 Float64 stored in one 64-bit register.

Another possibility if people are bothered by precision loss is using Posit16. I think currently your package has [min, max], or does it use midpoint? In either case, does it assume the same type or both numbers. Could we use say Posit16 for the midpoint(s) and Posit8 for the the range? For 64-bit float (or Float32) down to 16+8=24 bits, if not just 2 bytes.