[llvm] r189624 - Change default # of digits for APFloat::toString

Hi Eli,

I noticed that your commit introduces a regression in the LLDB test suite because expression evaluation of a floating point constant like 2.234f results in a value like 2.23399997. I suspect that this occurs because 2.234f is really just the closest number to 2.23399997 that can be represented using floating point precision. I noticed that your commit increases the default number of digits in the precision of APFloat. I can see how that's useful when performing intermediate computation, but I would have expected APFloat::toString to cleverly avoid reality.

The attached black magic fixes the regressions in the IRInterpreter used for expression evaluation. However, I'm wondering if the correct fix is to revert your commit (i.e. in favor of mode to select the default precision as nominal precision versus active precision). Cheers,

- Ashok

TestExpr.patch (1012 Bytes)

What APFloat::toString really needs to do by default is consistently print
the least number of digits necessary to re-parse to the same value. Using
a fixed number of digits is never going to what we want. Unfortunately,
that patch is a lot more complicated, and I don't really have the time or
expertise to push it through. If you're interested, I've attached my
work-in-progress, based on the Dragon4 algorithm from "How to Print
Floating-Point Numbers Accurately" by Steele and White.

-Eli

floattostringwip.txt (11.9 KB)

I agree here that floating point numbers should never be watered down when displaying them, we should always print out the most accurate version of it. For tests that want an exact number, use a number that works well for floating point like any negative power of 2 (0.5, .25, .125, etc). Numbers like 1.25 will always be able to be perfectly represented, so I would fix the test cases to use better numbers.

Greg

Thanks for the perspective, Eli,

I see now that I can trigger similar failures in LLDB independent of the algorithm used to select the fixed precision. I’ll withdraw my LLDB patch in favor of an xfail test. Were you thinking of filing a Bugzilla report to capture your WIP? Cheers,

  • Ashok

http://llvm.org/bugs/show_bug.cgi?id=17135

-Eli