----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....