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