f32 formatter produces strange results

[emilio]

Test-case:

fn main() {
    let f = 2147483648.0f32;
    println!("{} | {}", f, f as f64)
}

I expected both to produce the same number, since that number is a perfectly representable f32 value.

This bit me because I was investigating an issue where values close to integer limits were treated as negative.

Seeing 2147483600 (in range for an i32) rather than the actual value 2147483648 (out of range for an i32) made it all really confusing.

Anyhow, I'll fix Firefox to do the proper bounds check, but it would've been nice to avoid the extra confusion time :)

[nagisa]

The bytes put into the binary are correct, so it is indeed an issue in formatting routines.

[ExpHP]

This is because the floating point formatter prefers rounder numbers as long as it roundtrips back to the same float. For large floating point numbers, a more accurate string representation can be obtained by adding a precision (even a precision of 0 forces the value to be precise up to the decimal point).

fn main () {
    println!("{}", 1e100);
    println!("{:.0}", 1e100);
}

10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
10000000000000000159028911097599180468360808563945281389781327557747838772170381060813469985856815104

I seem to recall that, when this feature was added to rust, the author of the PR described it as an "optimization." (as in, simply printing zeros is much faster than drilling down into the decimal representation of the float; though at the time I wasn't sure why anyone would want to optimize the printing of such large numbers!) (Nope, I can't find anything like that. I think I recalled wrong.)

[emilio]

I think that's very confusing behavior, fwiw.

[ExpHP]

It's basically applying the same logic to digits before the decimal as it does to those after. The issue is, rust actually shows all the digits before the decimal.

I am wishing more and more that this could just get formatted to 2.1474836e9.

[scottmcm]

a more accurate string representation can be obtained

nitpick: a more precise string representation, not a more accurate one.

[workingjubilee]

@rustbot modify labels: +A-floating-point, +A-fmt

[KodrAus]

We discussed this in the recent Libs meeting and would be open to try fixing this up. It is confusing behavior to treat digits before the decimal the same as those after.