Inexact results from str::float::from_str

[SimonSapin]

Some inputs to std::float::from_str give a value that prints as an integer, but does not compare equal to it:

rusti> std::float::from_str("0.67e3").get()
670
rusti> std::float::from_str("0.67e3").get() == 670f
false
rusti> std::float::to_str_hex(670f)
~"29e"
rusti> std::float::to_str_hex(std::float::from_str("0.67e3").get())
~"29e.00000000002"

For comparison, Python does not have this issue:

>>> float('.67e3') == 670
True

[SimonSapin]

As jensnockert points out on IRC, 0.67e3 should parse to an integer float, so 29e.00000000002 is definitely wrong.

[auroranockert]

It should be exactly equal, since 670.0 is exactly representable in IEEE 754. #7030 is probably the same issue.

Ps. Even with a float RHS, Python gives the correct answer

>>> float('.67e3') == 670.0
True

[krdln]

This line is responsible, I think.
https://github.com/mozilla/rust/blob/master/src/libstd/num/strconv.rs#L588
Maybe calculation of exponential part should be before fraction calculation?

[auroranockert]

No idea, parsing floats is non-trivial. considering Java, PHP &c. have had severe DOS issues related to parsing floats, I think we should just borrow known-good code.

[Kimundi]

Yeah the current implementation just uses an very naive approach for float parsing and emitting.

The problem is that doing it proper is both hard and slow. To get an optimum result for parsing/printing a float from/to a base-n string representation requires bignum fractionals. (where optimum == "shortest unambigious string representation in base n" in a roundtrip float -> string -> float)

There exist algorithms specifically tailored to base 10 that can get around that by only requiring bignum ints, or even regular fixed sized integers, and working with bases 2, 4, 8, 16 and 32 is trivial, so I guess we'd ultimately want to incorporate all those techniqes by having different code paths to take, depending on input and base.

[pnkfelix]

visiting for bug triage, email from 2013-08-26.

It would be nice to fix this. I haven't looked at the rust implementation in strconv.rs yet. But I believe that Will Clinger's paper from PLDI 1990 is a pretty common reference for this, see

• http://www.cesura17.net/~will/Professional/Research/Papers/howtoread.pdf (and the associated retrospective from 2003)
• There's also David Gay's immediate followup work: http://www.ampl.com/REFS/abstracts.html#rounding
• (Of course there's also material in Knuth Volume 2, Seminumerical Algorithms.)

And yes, I think these algorithms are specially tailored to base 10, as Kimundi noted.

[emberian]

Triage. This is still a problem. The papers pnkfelix links look really nice.

[huonw]

cc #6220

[pnkfelix]

This needs to be properly triaged.

Nominating (I suspect it will be flagged as merely P-high, as that was what was done with #7030).

[pnkfelix]

Assigning P-high, not 1.0.

[IvanUkhov]

Hello,

From a discussion on the #rust IRC channel today:

fn main() {
    let a = from_str::<f32>("3.141592").unwrap();
    let b = 3.141592f32;
    println!("{}", a == b); // false
}

So, the implementations of string parsing in the compiler and in from_str differ. It seems many people find this inconsistency rather confusing.

Regards,
Ivan

[huonw]

Closing as a forward-dupe of #24557, since that issue has more info.