RE: Sine and Cosine Accuracy

["Dave Korn" <dave dot korn at artimi dot com>]

----Original Message----
>From: Scott Robert Ladd
>Sent: 26 May 2005 17:32

> Paul Koning wrote:
>>  Scott> Yes, but within the defined mathematical ranges for sine and
>>  Scott> cosine -- [0, 2 * PI) -- the processor intrinsics are quite 
>> Scott> accurate. 
>> 
>> Huh?  Sine and consine are mathematically defined for all finite
>> inputs.
> 
> Defined, yes. However, I'm speaking as a mathematician in this case, not
> a programmer. Pick up an trig book, and it will have a statement similar
> to this one, taken from a text (Trigonometry Demystified, Gibilisco,
> McGraw-Hill, 2003) randomly grabbed from the shelf next to me:
> 
> "These trigonometric identities apply to angles in the *standard range*
> of 0 rad <= theta < 2 * PI rad. 

  It's difficult to tell from that quote, which lacks sufficient context,
but you *appear* at first glance  to be conflating the fundamental
trignometric *functions* with the trignometric *identities* that are
generally built up from those functions.  That is to say, you appear to be
quoting a statement that says

" Identities such as
            sin(x)^2 + cos(x)^2 === 1
  are only valid when 0 <= x <= 2*PI"

and interpreting it to imply that 

"           sin(x)
  is only valid when 0 <= x <= 2*PI"

which, while it may or may not be true for other reasons, certainly is a
non-sequitur from the statement above.

  And in fact, and in any case, this is a perfect illustration of the point,
because what we're discussing here is *not* the behaviour of the
mathematical sine and cosine functions, but the behaviour of the C runtime
library functions sin(...) and cos(...), which are defined by the language
spec rather than by the strictures of mathematics.  And that spec makes *no*
restriction on what values you may supply as inputs, so gcc had better
implement sin and cos in a way that doesn't require the programmer to have
reduced the arguments beforehand, or it won't be ANSI compliant.

  Not only that, but if you don't use -funsafe-math-optimisations, gcc emits
libcalls to sin/cos functions, which I'll bet *do* reduce their arguments to
that range before doing the computation, (and which might indeed even be
clever enough to use the intrinsic, and can encapsulate the knowledge that
that intrinsic can only be used on arguments within a more limited range
than are valid for the C library function which they are being used to
implement).

  When you use -funsafe-math-optimisations, one of those optimisations is to
assume that you're not going to be using the full range of arguments that
POSIX/ANSI say is valid for the sin/cos functions, but that you're going to
be using values that are already folded into the range around zero, and so
it optimises away the libcall and the reduction with it and just uses the
intrinsic to implement the function.  But the intrinsic does not actually
implement the function as specified by ANSI, since it doesn't accept the
same range of inputs, and therefore it is *not* a suitable transformation to
ever apply except when the user has explicitly specified that they want to
live dangerously.  So in terms of your earlier suggestion:

----------------<quote>----------------
May I be so bold as to suggest that -funsafe-math-optimizations be
reduced in scope to perform exactly what it's name implies:
transformations that may slightly alter the meanding of code. Then move
the use of hardware intrinsics to a new -fhardware-math switch.
----------------<quote>----------------

... I am obliged to point out that using the hardware intrinsics *IS* an
unsafe optimisation, at least in this case!

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....