Re: Bit-exact floating-point computations

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.

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