public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Scott Robert Ladd <scott.ladd@coyotegulch.com>
To: Dave Korn <dave.korn@artimi.com>
Cc: 'Paul Koning' <pkoning@equallogic.com>,
	 rth@redhat.com,  gcc@gcc.gnu.org
Subject: Re: Sine and Cosine Accuracy
Date: Thu, 26 May 2005 17:40:00 -0000	[thread overview]
Message-ID: <42960605.1060607@coyotegulch.com> (raw)
In-Reply-To: <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

  parent reply	other threads:[~2005-05-26 17:24 UTC|newest]

Thread overview: 86+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-26 16:05 Scott Robert Ladd
2005-05-26 16:09 ` Andrew Haley
2005-05-26 16:33   ` Scott Robert Ladd
2005-05-26 17:14     ` Andrew Haley
2005-05-26 17:01   ` Paolo Carlini
2005-05-26 17:23 ` Richard Henderson
2005-05-26 17:24   ` Scott Robert Ladd
2005-05-26 17:27     ` Paul Koning
2005-05-26 17:27       ` Scott Robert Ladd
2005-05-26 17:29         ` Dave Korn
2005-05-26 17:37           ` David Daney
2005-05-26 17:56             ` Dave Korn
2005-05-26 17:40           ` Scott Robert Ladd [this message]
2005-05-26 18:12             ` Paul Koning
2005-05-26 18:32               ` Scott Robert Ladd
2005-05-26 18:50                 ` Paul Koning
2005-05-26 19:14                   ` Andrew Pinski
2005-05-26 19:35                     ` Scott Robert Ladd
2005-05-29  6:22                   ` Geoffrey Keating
2005-05-31 14:34                     ` Paul Koning
2005-05-31 22:58                       ` Geoff Keating
2005-05-29 12:07                 ` Roger Sayle
2005-05-30 15:34                   ` Vincent Lefevre
2005-05-29  2:22         ` Kai Henningsen
2005-05-29 18:16         ` Marc Espie
2005-05-29 20:58           ` Georg Bauhaus
2005-05-30 15:19             ` Gabriel Dos Reis
2005-05-30 15:19             ` Marc Espie
2005-05-30 17:26               ` Scott Robert Ladd
2005-05-30 17:18                 ` Marc Espie
2005-05-30 18:11                   ` Scott Robert Ladd
2005-05-30 17:31               ` Scott Robert Ladd
2005-05-31  3:10                 ` chris jefferson
2005-05-31 12:17                   ` Andrew Haley
2005-05-31 12:46                   ` Scott Robert Ladd
2005-05-31 13:02                     ` Andrew Haley
2005-05-31 13:34                 ` Vincent Lefevre
2005-05-30 15:35             ` Bernhard R. Link
2005-05-30 18:59               ` Scott Robert Ladd
2005-05-30 19:16               ` Georg Bauhaus
2005-05-30 19:17                 ` Bernhard R. Link
2005-05-30 19:54                   ` Georg Bauhaus
2005-05-30 20:04                     ` Gabriel Dos Reis
2005-05-26 17:35       ` Kevin Handy
2005-05-26 17:41         ` Paul Koning
2005-05-26 20:26           ` Joseph S. Myers
2005-05-26 21:15     ` Gabriel Dos Reis
2005-05-26 21:17       ` Scott Robert Ladd
2005-05-26 23:25         ` Gabriel Dos Reis
2005-05-27  0:18           ` Scott Robert Ladd
2005-05-27  0:54             ` Gabriel Dos Reis
2005-05-27 11:29           ` Marcin Dalecki
2005-05-27  9:36         ` Marcin Dalecki
2005-05-27 10:48       ` Marcin Dalecki
2005-05-26 21:33     ` Richard Henderson
2005-05-27  0:05       ` Scott Robert Ladd
2005-05-27  0:43         ` Gabriel Dos Reis
2005-05-27  0:54           ` Scott Robert Ladd
2005-05-28 11:26             ` Russ Allbery
2005-05-27 13:56     ` Vincent Lefevre
2005-05-29  3:36   ` Kai Henningsen
2005-05-26 17:53 Morten Welinder
2005-05-26 18:10 ` Scott Robert Ladd
2005-05-26 18:22   ` Dave Korn
2005-05-26 18:49     ` Scott Robert Ladd
2005-05-26 19:28       ` Dave Korn
2005-05-26 18:38 Morten Welinder
2005-05-26 20:58 ` Andrew Haley
2005-05-26 23:31 Uros Bizjak
2005-05-26 23:52 ` Paul Koning
2005-05-26 23:56 ` Gabriel Dos Reis
2005-05-26 23:57   ` Steven Bosscher
2005-05-27 15:09   ` Olivier Galibert
2005-05-27 15:28     ` Vincent Lefevre
2005-05-27 18:27     ` Marcin Dalecki
2005-05-26 23:59 Menezes, Evandro
2005-05-27 15:19 ` Vincent Lefevre
2005-05-27  0:39 Menezes, Evandro
2005-05-27  0:54 ` Scott Robert Ladd
2005-05-27  0:54 Menezes, Evandro
2005-05-27  0:54 ` Scott Robert Ladd
2005-05-27 12:42 ` Scott Robert Ladd
2005-05-28  4:32 Menezes, Evandro
2005-05-28  5:02 ` Scott Robert Ladd
2005-05-28 10:44 ` Gary Funck
2005-05-28  6:42 Menezes, Evandro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=42960605.1060607@coyotegulch.com \
    --to=scott.ladd@coyotegulch.com \
    --cc=dave.korn@artimi.com \
    --cc=gcc@gcc.gnu.org \
    --cc=pkoning@equallogic.com \
    --cc=rth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).