Re: Bit-exact floating-point computations

Christian Bau <christian.bau@cbau.freeserve.co.uk>
18 Jan 2002 21:01:44 -0500

          From comp.compilers

Related articles
re: Compiler bugs chase@world.std.com (David Chase) (2002-01-03)
Re: Compiler bugs christian.bau@cbau.freeserve.co.uk (Christian Bau) (2002-01-05)
Re: Compiler bugs chase@world.std.com (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 christian.bau@cbau.freeserve.co.uk (Christian Bau) (2002-01-18)
Re: Bit-exact floating-point computations fare@tunes.org (Francois-Rene Rideau) (2002-01-24)
Re: Bit-exact floating-point computations chase@world.std.com (David Chase) (2002-01-24)
Re: Bit-exact floating-point computations christian.bau@cbau.freeserve.co.uk (Christian Bau) (2002-01-28)
Re: Bit-exact floating-point computations nmm1@cus.cam.ac.uk (2002-01-30)
| List of all articles for this month |
From: Christian Bau <christian.bau@cbau.freeserve.co.uk>
Newsgroups: comp.compilers
Date: 18 Jan 2002 21:01:44 -0500
Organization: Compilers Central
References: 02-01-015 02-01-029 02-01-054 02-01-066
Keywords: arithmetic
Posted-Date: 18 Jan 2002 21:01:44 EST

Francois-Rene Rideau wrote:
>
> Yes: people computing distributed physical models (physical
> simulations, virtual reality, remote robot control), and like being
> able to rely on programs doing identical computations in parallel and
> getting the exact same result, instead of having to propagate
> computation results from a centralized server through the network,
> which can be VERY expensive in terms of latency, etc. Also, people who
> need 100% reproducible results in their computations.
>
> I'm not currently one of these people, but have been working with some
> of them, who have been badly bitten by floating-point discrepancy
> between JVM implementations in the past.
>
> "Write Once, Run Anywhere"?
> Without bit-exact correctness, it's but a shameful lie.
>
> I agree that some people prefer faster approximate results, and should
> be able to declare it for better performance -- but the default should
> be to get exact (albeit possibly much slower) results.


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. Java on the other hand demands that sin
(1.0e300) actually gives the exact result, almost correctly
rounded. That is much harder and much much less useful.


Post a followup to this message

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