Re: Document libm accuracy goals

["Carlos O'Donell" <carlos at redhat dot com>]

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