This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Sine and Cosine Accuracy
- From: Scott Robert Ladd <scott dot ladd at coyotegulch dot com>
- To: Dave Korn <dave dot korn at artimi dot com>
- Cc: 'Paul Koning' <pkoning at equallogic dot com>, rth at redhat dot com, gcc at gcc dot gnu dot org
- Date: Thu, 26 May 2005 13:23:17 -0400
- Subject: Re: Sine and Cosine Accuracy
- References: <SERRANOiVklUVhjNIjm00000179@SERRANO.CAM.ARTIMI.COM>
Dave Korn wrote:
> 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
Perhaps I didn't say it as clearly as I should, but I do indeed know the
difference between the implementation and definition of the
trigonometric identifies.
The tradeoff is between absolute adherence to the C standard and the
need to provide fast, accurate results for people who know their math.
What I see is a focus (in some areas like math) on complying with the
standard, to the exclusion of people who need speed. Both needs can be met.
> 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.
The sin() and cos() functions, in theory, implement the behavior of the
mathematical sine and cosine identities, so the two can not be
completely divorced. I believe it is, at the very least, misleading to
claim that the hardware intrinsics are "unsafe".
> 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.
I'm not asking that the default behavior of the compiler be non-ANSI;
I'm asking that we give non-perjorative options to people who know what
they are doing and need greater speed. The -funsafe-math-optimizations
encompasses more than hardware intrinsics, and I don't see why
separating the hardware intrinsics into their own option
(-fhardware-math) is unreasonable, for folk who want the intrinsics but
not the other transformations.
..Scott