This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Document libm accuracy goals
- 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