This is the mail archive of the
`libc-alpha@sourceware.org`
mailing list for the glibc project.

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |

Other format: | [Raw text] |

*From*: "Carlos O'Donell" <carlos at redhat dot com>*To*: "Joseph S. Myers" <joseph at codesourcery dot com>*Cc*: libc-alpha at sourceware dot org*Date*: Thu, 28 Nov 2013 17:23:08 -0500*Subject*: Re: Document libm accuracy goals*Authentication-results*: sourceware.org; auth=none*References*: <Pine dot LNX dot 4 dot 64 dot 1311281756120 dot 23291 at digraph dot polyomino dot org dot uk> <5297A811 dot 7040008 at redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1311282103260 dot 22976 at digraph dot polyomino dot org dot uk>

On 11/28/2013 04:09 PM, Joseph S. Myers wrote: > On Thu, 28 Nov 2013, Carlos O'Donell wrote: > >> Could you please add an entry to the FAQ for the libm goals and >> specifically call out monotonicity? > > https://sourceware.org/glibc/wiki/FAQ#What_are_the_accuracy_goals_for_libm_functions.3F Looks good to me. I suggest putting it into a new libm section of the FAQ? I filled out "Why are libm functions slow on some inputs?" You can move that too if you want. >>> +@item >>> +For the IBM @code{long double} format, as used on PowerPC GNU/Linux, >> >> Is it sufficient to say "PowerPC GNU/Linux" when we mean both the 32-bit >> and 64-bit runtimes? > > I think so. If a future update to ELFv2 moves 64-bit LE away from IBM > long double, this text could always be changed then. Sounds good to me then. >>> +@item >>> +@Theglibc{} does not aim for functions to satisfy other properties of >>> +the underlying mathematical function, such as monotonicity, where not >>> +implied by the above goals. >> >> Aside from montonicity what other properties might we call out explicitly >> here as things we don't plan to satisfy? > > I don't think there are other properties to call out. For IBM long double > you have e.g. properties such as sin^2 + cos^2 = 1 - where we don't > guarantee that sin and cos will do the range reduction the same, and for > cases that don't fit in 106 bits the range reduction may not be accurate > (it's not that accurate range reduction for discontiguous mantissas is > hard, but the code doesn't attempt it). But I expect that in fact the > range reduction will be done compatibly for both functions, so that sin^2 > + cos^2 = 1 to high precision even if the sin and cos values relate to > some argument other than the exact input. I was thinking more along the lines of smoothness and differentiability, or integrals equaling to specific values whose error we might control. However your "such as" is sufficient to cover everything. I was simply trying to come up with any other useful property we might call out. Note that Math in Java guarantees semi-monotonic results, they write "whenever the mathematical function is non-decreasing, so is the floating-point approximation, likewise, whenever the mathematical function is non-increasing, so is the floating-point approximation. Not all approximations that have 1 ulp accuracy will automatically meet the monotonicity requirements." [1] Cheers, Carlos. [1] http://docs.oracle.com/javase/7/docs/api/java/lang/Math.html

**References**:**Document libm accuracy goals***From:*Joseph S. Myers

**Re: Document libm accuracy goals***From:*Carlos O'Donell

**Re: Document libm accuracy goals***From:*Joseph S. Myers

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |