<div dir="ltr">On Wed, Sep 4, 2013 at 7:21 AM, Thirumurthi, Ashok <span dir="ltr"><<a href="mailto:ashok.thirumurthi@intel.com" target="_blank">ashok.thirumurthi@intel.com</a>></span> wrote:<br><div class="gmail_extra">
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi Eli,<br>
<br>
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.<br>

<br>
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,<br>
<br></blockquote><div><br></div><div>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.</div>
</div><br></div><div class="gmail_extra">-Eli</div></div>