Float::integer_decode cannot be implemented for quadruple precision floating types.

[jkarns275]

This is the definition of integer_decode:

fn integer_decode(self) -> (u64, i16, i8)

The 64 bits allocated for the mantissa is too small, 112 bits would be required to store the mantissa of a IEEE 754 quadruple-precision float. The exponent requires 15 bits, so i16 is enough, and naturally i8 is enough for the sign.

I ran into this issue while working on bindings to the GCC __float128 type (aka libquadmath). Would changing the u64 meant for the mantissa to a u128 be too much of a breaking change? If not, I will implement it in the next couple of days.

[cuviper]

It would definitely be a breaking change to change the current signature.

But we could add an alternate like fn integer_decode_ex(self) -> (u128, i16, i8) (insert name bikeshedding here), with a default implementation that just extends from integer_decode. Your __float128 implementation would have to be lossy on the non-ex version, I guess.

I think you actually need i32 for negative exponents, since our definition as mantissa * 2^exponent forces an extra mantissa shift. e.g. integer_decode_64 does this:

    // Exponent bias + mantissa shift
    exponent -= 1023 + 52;

Another option is to add full flexibility in a separate trait, something like:

trait FloatDecode {
    type Mantissa;
    type Exponent;
    type Sign;

    fn decode(&self) -> (Self::Mantissa, Self::Exponent, Self::Sign);
    // perhaps individual `decode_mantissa` etc. too
}

This would allow arbitrary types, like IEEE 754 octuple precision or a bigint-based float.

[jkarns275]

I like the idea of a FloatDecode trait, but it would effectively deprecate the current integer_decode method (which may be perfectly fine). I will work on an impl of the FloatDecode trait in the next couple of days, and ask for some feedback in this thread.

Also, I don't quite understand why an i32 is needed for the exponent. The way I'm thinking about it is that the exponent range for f128 is -16382..=16383, which neatly fits in an i16 with room to spare.

[cuviper]

The minimum exponent is only -16382 when you're interpreting the mantissa as 1.xxxx... But since we're returning the mantissa as an integral 1xxxx... value, the exponent needs a further negative bias.

e.g. f64::MIN_POSITIVE decodes as (4503599627370496, -1074, 1), even though the IEEE 754 exponent range is -1022..=1023.

For quadfloat, I think the MIN_POSITIVE exponent will be -16382 - 112 = -16494.

[jkarns275]

Ah I see. It still seems like an i16 will work, since the i16 range is aprox. -32000 - 32000

[cuviper]

i16 range is aprox. -32000 - 32000

... yes, indeed it is. I was thinking +/-16k, silly me.🤦🏼‍♂️

[jkarns275]

On the brightside, we now know for sure an i16 would be enough!

[vks]

Would changing the u64 meant for the mantissa to a u128 be too much of a breaking change?

It would also raise the minimal required Rust version from 1.8 to 1.26, so I think a new function is probably the better option.

[cmpute]

Just an idea if the interface for integer_decode is to be redesigned. It seems cleaner to me to return a (signed_mantissa, exp) rather than (mantissa, exp, sign). I personally have many cases where I need to multiply the sign back to mantissa in order for some comparison.

[jkarns275]

@cmpute I strongly disagree with that idea. There are three components to IEEE floating point numbers - the mantissa, exponent, and sign; this function gives you them.

If you need to do a multiplication, you should do it yourself rather than asking the function to do a potentially unnecessary operation. This would also make code particularly ugly in cases where the sign was key, e.g. lots of if mantissa > 0 { 1 } else { -1 } which is much uglier than mantissa * sign.

[cmpute]

@jkarns275 In order to get a signed mantissa, what you actually need is mantissa as i64 * sign as i64, and I personally don't find any situation where a separate sign variable is needed, because you need two or three branches for the sign anyway. But I agree with that it requires additional multiplication and it's better to comply with the standard.

[tgross35]

This might be a bit more relevant since f16 and f128 are now unstably available. Instead of always returning u128, it may be nicer to somehow put this into an associated type. This would also allow for the transmutation functions available in std, which softfloat libraries need:

trait FloatRepr {
    type Int;
    fn to_bits(self) -> Self::Int;
    fn from_bits(Self::Int) -> Self;
    fn decode(self) -> (Self::Int, i16, i8);
}

The exponent portion would also need to be an associated type if supporting numbers larger than f128 might be desired down the line (e.g. binary256 has a 19 bit exponent). Likely not much need for this though.

Edit: One other thing that would be useful for soft float libraries is associated constants for representation properties. E.g. mantissa bits, exponent bits, exponent bias, etc. (as is used in compiler-builtins https://github.com/rust-lang/compiler-builtins/blob/7a84ce4a90cd2d22494daead50f9026b5ca52140/src/float/mod.rs)

[cuviper]

An associated type makes it more difficult to deal with the decoded result generically. Instead of just T: FloatRepr, you also need T::Int: ... for all the operations you want to do with that. We could tighten that with something like type Int: PrimInt, but then it rules out something like a hypothetical BigFloat.