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

[Thirumurthi, Ashok]

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

From: Eli Friedman [mailto:eli.friedman at gmail.com]
Sent: Thursday, September 05, 2013 4:38 PM
To: Thirumurthi, Ashok
Cc: lldb-dev at cs.uiuc.edu
Subject: Re: [llvm] r189624 - Change default # of digits for APFloat::toString

On Wed, Sep 4, 2013 at 7:21 AM, Thirumurthi, Ashok <ashok.thirumurthi at intel.com<mailto:ashok.thirumurthi at intel.com>> wrote:
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,

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20130905/c852c9cc/attachment.html>