80-bit reals give you roughly 19 decimal digits of precision. Thus, for a given number, 20 digits should usually be enough to ensure that the literal gets mapped to the closest representable number. The following program shows that this is not always the case. Here, 23 digits is needed to get the closest representable number to pi^2, even though the approximation to pi^2 itself is only accurate to 18 digits! Test case: void main() { // Approximations to pi^2, accurate to 18 digits: real closest = 0x9.de9e64df22ef2d2p+0L; real next = 0x9.de9e64df22ef2d3p+0L; // A literal with 23 digits maps to the correct // representation. real dig23 = 9.86960_44010_89358_61883_45L; assert (dig23 == closest); // 22 digits should also be (more than) sufficient, // but no... real dig22 = 9.86960_44010_89358_61883_5L; assert (dig22 == closest); // Fails; should pass assert (dig22 == next); // Passes; should fail }
Actually 19 digits works. The thing that's wrong is that the compiler uses _all_ provided digits. Instead, according IEEE754, it should only take the first 19 digits, performing decimal rounding of the l9th digit if more digits are provided. It's a problem in DMC's standard library implementation of strtold(). I once found a case where adding more decimal digits made the number smaller(!)
Floating-point parsing also fails on this much shorter number: 4294967295.0 parses to: 4294967296.0 When parsed using: double val = to!(double)(numStr); Also fails with formattedRead.
Maxime: What you're describing looks like a bug in Phobos, while this report is about a bug in DMD. You should probably create a new report for that one.
@Lars: If she is using DMD on Windows, the root cause might in fact be the same.
(In reply to comment #4) > @Lars: If she is using DMD on Windows, the root cause might in fact be the > same. It turned out to be a problem with my code. I apologize for not testing thorougly enough before commenting. My comment should be removed from this thread if possible.
Digital Mars C (i.e. snn.lib) uses an older method to convert strings to floating point numbers. Newer, slightly more accurate methods have become available since it was written, but I've never gotten around to implementing them. This error is likely related to that. If the error doesn't occur with DMD on other platforms, like Linux, then this is almost certainly the culprit. Note that the DMD compiler itself uses the C runtime conversion routine for its lexer.