[Bug math/22906] new version of exp doesn't always round correctly

["carlos at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=22906

--- Comment #6 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Ben Woodard from comment #5)
> I've been talking this over with the customer and provided them the data
> that I posted below about the level of performance with the different
> implementations and how close to correctly rounded it is and after showing
> them the comparison of the speeds and the accuracy and in particular showing
> them that at least one of the libraries that they have been using also has
> the same not perfectly rounded to the last bit, characteristic they replied:
> 
> "I believe we are happy with the 1ULP performance and functionality.  
> Although the climate guys may want the 1/2ULP for crlibm, I think this
> should only be an option, not the default math library.   They can
> explicitly link it in if they want it." The climate guys do need last bit
> accuracy which is where the idea of the butterfly effect came from. 
> 
> I believe this case is good for future reference because it demonstrates the
> relative accuracy, states the position, and shows the trade offs being made.

Thank you for that update. I'll leave this as RESOLVED INVALID. However, please
keep us updated if your user requirements change.

Supporting correctly rounded results is currently not in the goals for glibc's
libm, instead like Intel's math library, we aim to try have reasonable accuracy
goals, without high latency spikes.

We haven't entirely abandoned having 3 library variants that were discussed in
the community, but like always, if we can get just 1 variant (the default one)
good enough, then we won't need 2 other variants (-fast-math, -fprecise-math).
Keep in mind that our -fprecise-math variant was also never intended to be
correctly rounded.

-- 
You are receiving this mail because:
You are on the CC list for the bug.