Hi,

Thanks for taking the time to respond and the clarification on the working of the exponent sign/bias.

I am trying to avoid any method not entirely embedded in the library such as a home-baked compression method as it would make the data harder to use for external users not having that specific filter in their version of the library. All in all, I think I can achieve nearly what I want with the n-bits.

To be more specific, I have in memory an array of IEEE 4-byte floats. I know I can afford to store them only has IEEE 2-byte floats. I know my numbers are all positive so could skip the sign bit. And I know they are all in the range [0, 1], meaning that I don’t need large exponents.

My numbers, on disk, with an offset of 0 and just a simple reduction in the number of mantissa and exponent bits, would look like:

```
3 2 1 0
???????? ???????? SEEEEEMM MMMMMMMM
```

With an exponent bias of 15 this would be identical to an IEEE half-float.

For the (overall) sign bit, would it work to “bit-shift” it out of the result by setting an offset such that there isn’t enough space “on the left” for the sign bit? Could I set an offset of 17 and get:

```
3 2 1 0
EEEEEMMM MMMMMMM? ???????? ????????
```

i.e. would the library be able to decompress this correctly? (and make me gain 1 bit out of every 16)

As for the sign of the exponent, your correction of my statement about the sign being instead represented as a bias, means that I should be able to play with the bias value and trim off another bit.

Going for

```
3 2 1 0
EEEEMMMM MMMMMM?? ???????? ????????
```

and a bias of 0.

If I am not mistaken that would decompress into numbers in the range of binary exponents [-14, 0], which is all the precision I need for my numbers in the (decimal) range [0,1]. And would save me an extra bit.

Would you expect this to be supported correctly by the library’s n-bit filter?

Thanks again,

M.