Re: Sine and Cosine Accuracy

[Geoffrey Keating <geoffk at geoffk dot org>]

Paul Koning <pkoning@equallogic.com> writes:

> After some off-line exchanges with Dave Korn, it seems to me that part
> of the problem is that the documentation for
> -funsafe-math-optimizations is so vague as to have no discernable
> meaning. 
> 
> For example, does the wording of the documentation convey the
> limitation that one should only invoke math functions with a small
> range of arguments (say, -pi to +pi)?  I cannot see anything remotely
> resembling that limitation, but others can.
> 
> Given that, I wonder how we can tell whether a particular proposed
> optimization governed by that flag is permissible.  Consider:
> 
> `-funsafe-math-optimizations'
>      Allow optimizations for floating-point arithmetic that (a) assume
>      that arguments and results are valid and (b) may violate IEEE or
>      ANSI standards.  
> 
> What does (b) mean?  What if anything are its limitations?  Is
> returning 1.2e27 as the result for a sin() call authorized by (b)?  I
> would not have expected that, but I can't defend that expectation
> based on a literal reading of the text...

I believe that (b) is intended to include:

- adding extra precision or range unspecified by the program
- spurious overflow and/or underflow
- a limited general reduction in precision (no more than a few ulp)
- limited ranges of elementary functions
- complete loss of precision in unusual cases (where 'unusual' is not
  well-defined), for instance with complex numbers
- applying simplifications to expressions that would be allowable
  if precision and range were unlimited
- all these might vary between compiler versions, so results are not stable

and probably many other things that I don't remember right now.

The only real limitation on -funsafe-math-optimizations is that it
still has to build SPEC.