Re: Bit-exact floating-point computations

David Chase <>
24 Jan 2002 13:55:24 -0500

          From comp.compilers

Related articles
re: Compiler bugs (David Chase) (2002-01-03)
Re: Compiler bugs (Christian Bau) (2002-01-05)
Re: Compiler bugs (David Chase) (2002-01-14)
Bit-exact floating-point computations (Francois-Rene Rideau) (2002-01-17)
Re: Bit-exact floating-point computations (Christian Bau) (2002-01-18)
Re: Bit-exact floating-point computations (Francois-Rene Rideau) (2002-01-24)
Re: Bit-exact floating-point computations (David Chase) (2002-01-24)
Re: Bit-exact floating-point computations (Christian Bau) (2002-01-28)
Re: Bit-exact floating-point computations (2002-01-30)
| List of all articles for this month |

From: David Chase <>
Newsgroups: comp.compilers
Date: 24 Jan 2002 13:55:24 -0500
Organization: The World : : Since 1989
References: 02-01-015 02-01-029 02-01-054 02-01-066 02-01-080
Keywords: arithmetic
Posted-Date: 24 Jan 2002 13:55:24 EST

Christian Bau wrote:

> But this is a totally different thing: To get bit identical results
> (for sine, cosine and so on) you don't need the ridiculous precision
> that Java prescribes. What you want is that sin (1.0e300) produces the
> same result on your machine as on mine. That is easily achieved by
> defining the actual code that the sin implementation uses, and by
> defining semantics of + - * / as bit exact as Java does anyway. That
> can still be achieved easily.

That is exactly what Java does. The specification defines the results
as being as if from fdlibm, translated appropriately from C to Java.
You can accomplish this by translating fdlibm from C to Java (easy,
done that) or by correcting the C for the compiler bugs on your
favorite platform (easy, done that, too). This happens to provide
answers within 1 LSB, even for inputs as large as 1.0e300 (*). For
small inputs (0..PI/4) this also appears to be as fast as or faster
than hardware, especially if the inputs have their range checked (so
as to determine whether they are in the range where the hardware
actually provides an approximate answer). So, what you propose as
being different from what Java does, is exactly what Java does.

Furthermore, fdlibm is the only freely available source code that I
know of that does an adequate job of computing these transcendentals.
Replicating the behavior of the Pentium hardware on most other
hardware (i.e., most other hardware with 53-bit mantissa, smaller than
the 68-bit approximation to PI used in the hardware range reduction)
would also be about as slow as what fdlibm does for most inputs, plus
the actual algorithm used by Pentium for in-range calculation of sin
and cos is (to my knowledge) unpublished.

(*) I am running the test now, but the constructive reals run
substantially more slowly when performing 300-digit arithmetic. So
far, the error distributions resemble those seen for smaller

David Chase

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.