Re: Bit-exact floating-point computations

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


David Chase

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