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

[Eli Friedman]

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

-Eli


On Thu, Sep 5, 2013 at 2:01 PM, Thirumurthi, Ashok <
ashok.thirumurthi at intel.com> wrote:

>  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> 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/20130906/a1080234/attachment.html>