|re: Compiler bugs firstname.lastname@example.org (David Chase) (2002-01-03)|
|Re: Compiler bugs email@example.com (Christian Bau) (2002-01-05)|
|Re: Compiler bugs firstname.lastname@example.org (David Chase) (2002-01-14)|
|Bit-exact floating-point computations fare+NOSPAM@tunes.org (Francois-Rene Rideau) (2002-01-17)|
|Re: Bit-exact floating-point computations email@example.com (Christian Bau) (2002-01-18)|
|Re: Bit-exact floating-point computations firstname.lastname@example.org (Francois-Rene Rideau) (2002-01-24)|
|Re: Bit-exact floating-point computations email@example.com (David Chase) (2002-01-24)|
|Re: Bit-exact floating-point computations firstname.lastname@example.org (Christian Bau) (2002-01-28)|
|Re: Bit-exact floating-point computations email@example.com (2002-01-30)|
|From:||Christian Bau <firstname.lastname@example.org>|
|Date:||28 Jan 2002 01:03:23 -0500|
|References:||02-01-015 02-01-029 02-01-054 02-01-066 02-01-080 02-01-095|
|Posted-Date:||28 Jan 2002 01:03:23 EST|
Francois-Rene Rideau wrote:
> Christian Bau <email@example.com> 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.
Return to the
Search the comp.compilers archives again.