This is the mail archive of the
mailing list for the GCC project.
Re: Fourth Draft "Unsafe fp optimizations" project description.
- To: Geert Bosch <bosch at gnat dot com>
- Subject: Re: Fourth Draft "Unsafe fp optimizations" project description.
- From: Linus Torvalds <torvalds at transmeta dot com>
- Date: Sun, 12 Aug 2001 22:20:44 -0700 (PDT)
- cc: <dewar at gnat dot com>, <gcc at gcc dot gnu dot org>, <toon at moene dot indiv dot nluug dot nl>
On Mon, 13 Aug 2001, Geert Bosch wrote:
> On Sun, 12 Aug 2001, Linus Torvalds wrote:
> Hmm. As far as I know, the library routines at least in glibc do not add
> any accuracy.
> The library routines _do_ add:
> - "errno" handling
> - extended range by reduction of the argument size
> but not accuracy.
> The way argument reduction is done affects accuracy for arguments
> whose absolute value is larger than half pi.
Yes. However, the intel hardware does do this correctly for the range of
inputs that it handles, so the accuracy of the hw should be fine within
that range. The i387 (at least in the PPro core) uses an internal value of
PI accurate to 66 bits, which is two bits more than you can do with
If you want more details, please check out the "Pentium Processor User's
Manual: Vol 3: Architecture and Programming Manual", which actually has a
separate Appendix G ("Report on Transcendental Functions") on the accuracy
of the functions. It's kind of sad, really: they never did this for the
i486, but with the Pentium Intel wanted to get respectability in the math
world, and did all this extra work. Then came the "fdiv" bug...
They never bothered to re-do the pretty scatter plots etc for the PPro
Anyway, for those who do not have the manuals, the bottom line is that
they actually are pretty careful, and do reduction in microcode. For all
transcendental functions Intel claims, and I quote:
"On the Pentium microprocessor, the worst error case on all
transcendental functions is less than 1 ulp when rounding in
nearest mode, and less than 1.5 ulps when rounding in other
And realize that this is true in _extended_ precision, with 64 bits of
So don't worry too much about plain doubles. The thing is accurate.
Assuming they don't have a fdiv-like bug ;)
The scatter plots in the manuals etc also show verification for a total
of a claimed 28 million points used for accuracy testing of "fsin", and 4
million used for monotonicity testing. Again, quoting
"For all cases tested, the actual error was found to lie below the
bound obtained by the theoretical error analysis. Figure G1
through Figure G-22 are ulp plots that illustrate this
characterization information. .."
All typos and errors likely mine.
So I seriously doubt that you'd get better accuracy in the library
routines even if you tried _really_ hard. So I still maintain that the
only thing that a x86-based library routine can do is
- reduce the (completely worthless) range of |x| > 2**63, where you have
accuracy only in a very theoretical way.
- set errno etc
Now, the range |x| > 2**63 may be worthless from an accuracy standpoint
(the difference between adjacent fp numbers is so big that trying to do
sine on consecutive numbers just gives noise), but obviously returning a
number not in the range [-1,1] for sine is to be considered very suspect
indeed. And -ffast-math _will_ do so - never mind that the argument is
arguably completely bogus.
I think that ridiculous arguments can get ridiculous results. Garbage in,
garbage out. But hey, maybe somebody has an algorithm that cares.