0.9f32 != "0.9".parse().unwrap()

[seanmonstar]

fn main() {
    assert_eq!(0.9f32, "0.9".parse().unwrap());
}

[edwardw]

Hmm, it has to do with default numeric types, 0.9f64 works:

fn main() {
    assert_eq!(0.9f64, "0.9".parse().unwrap());
}

[shepmaster]

Is this not just normal floating point wonkyness? Here's what happens if you print a hex representation of the values:

use std::mem::transmute;

fn main() {
    let lit: f32 = 0.9;
    let prs: f32 = "0.9".parse().unwrap();

    let lit_int: u32 = unsafe{transmute(lit)};
    let prs_int: u32 = unsafe{transmute(prs)};

    println!("{:x}", lit_int);
    println!("{:x}", prs_int);
}

outputs:

3f666666
3f666667

If you do the same for f64, the output is 3feccccccccccccd for both.

[shepmaster]

Another example of (expected) floating point excitement:

fn main() {
    let lit: f32 = 0.9;
    let sum: f32 = 0.3 + 0.3 + 0.3;
    assert_eq!(lit, sum)
}

[seanmonstar]

Yea, floats are wonky. However, this means there's 2 parsing implementations. 1 the compiler uses, and 1 the stdlib uses, and they differ somehow.

[Diggsey]

Both parsers should give the representable float closest to the exact value.

[nagisa]

However, this means there's 2 parsing implementations. 1 the compiler uses, and 1 the stdlib uses, and they differ somehow.

The compiler uses LLVM to parse literals and we can’t quite depend on LLVM for our standard library.

[steveklabnik]

Is this a dup of #7648 ?

[seanmonstar]

@steveklabnik seems like it!