std::f32 declares wrong mantissa length

[malu]

static pub MANTISSA_DIGITS: uint = 53u;
I guess that should be 24. Or is there some reasoning behind it that I don't see?
As well as std::f32::DIGITS which should probably be 6 instead of 15.

[lifthrasiir]

Ugh, many constants in std::f32 are indeed incorrect. The FIXME suggests these constants are deprecated once CTFE (#11621) lands, and corresponding traits are actually correct though.

[thestinger]

CTFE isn't going to happen any time soon, and may not happen at all. They're not going to be possible to remove for a long time.

[aturon]

There is a broader problem here: the Float trait defines several methods for various constants that almost follow those in the standard float.h, but:

Float::epsilon says

Returns the smallest positive number that this type can represent

while FLT_EPSILON for float.h says

Minimum int x such that FLT_RADIX**(x-1) is a normalised float

(In particular, Float::epsilon matches FLT_MIN in float.h)

Moreover, Float::digits says

Returns the number of binary digits of exponent that this type supports.

while FLT_DIG for float.h says

This is the number of decimal digits of precision for the float data type. Technically, if p and b are the precision and base (respectively) for the representation, then the decimal precision q is the maximum number of decimal digits such that any floating point number with q base 10 digits can be rounded to a floating point number with p base b digits and back again, without change to the q decimal digits.

Finally, the float types implement the Bounded trait, but provide the minimum positive value for Bounded::min_val. I'm guessing this should be the smallest number above negative infinity. But the Bounded trait does not give specs for min_val.

Does anyone know if these discrepancies, which affect both f32 and f64, are intended? My instinct would be to match float.h, and to fix the original bug by having each of f32 and f64 only supply the constants once (they are currently duplicated).

@bjz, care to weigh in?

[aturon]

Note: this issue and issue 11537 should be resolved together.