Re: Bit-exact floating-point computations

Christian Bau <>
28 Jan 2002 01:03:23 -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: Christian Bau <>
Newsgroups: comp.compilers
Date: 28 Jan 2002 01:03:23 -0500
Organization: Compilers Central
References: 02-01-015 02-01-029 02-01-054 02-01-066 02-01-080 02-01-095
Keywords: arithmetic
Posted-Date: 28 Jan 2002 01:03:23 EST

Francois-Rene Rideau wrote:
> Christian Bau <> writes:
> >> "Write Once, Run Anywhere"?
> >> Without bit-exact correctness, it's but a shameful lie.
> >
> > 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.
> Java does the right thing here: because the only future-proof way of
> defining sin(1.0e300) is the bit-exact correct result. Standardizing
> a kluge is the best way to build heaps of rubbish in the future so as
> to be backward compatible with ancient Java applications when all modern
> processors of the day (say in 2010) compute sin(1.0e300) without problem.
> An acceptable compromise would be do define a large interval inside which
> bit-exact correctness is guaranteed, and outside of which warranties are
> less stringent.
> Allowing spurious discrepancy for the sake of speed is just Wrong(TM).
> Standardizing on wrong answers is Evil(TM).

I am trying desperately here to make you understand what I wrote:
There is nothing wrong with giving a specification of the sin ()
function that will always give the same result for the same
argument. No problem at all demanding that sin (1.0e300) should give
the same result on any processor. The stupid thing is demanding that
sin (1.0e300) should return the almost, but not completely guaranteed
correctly rounded result, because that result is absolutely

PS. When I said there is nothing wrong with a specification that
demands reproducible results, there have been arguments against
it. The best argument is that if you run your code on two
implementations that are both of good quality but not identical, and
you get different results, then this is often just a sign that there
is something wrong with your code.

Post a followup to this message

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