http://llvm.org/bugs/show_bug.cgi?id=17135
-Eli On Thu, Sep 5, 2013 at 2:01 PM, Thirumurthi, Ashok < [email protected]> 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:[email protected]] > *Sent:* Thursday, September 05, 2013 4:38 PM > *To:* Thirumurthi, Ashok > *Cc:* [email protected] > *Subject:* Re: [llvm] r189624 - Change default # of digits for > APFloat::toString**** > > ** ** > > On Wed, Sep 4, 2013 at 7:21 AM, Thirumurthi, Ashok < > [email protected]> 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**** >
_______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
