classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bugs #7123] Quadratic and cubic equations


From: Sascha Brawer
Subject: Re: [bugs #7123] Quadratic and cubic equations
Date: Thu, 8 Jan 2004 16:51:28 +0100

Brian Gough <address@hidden> wrote on Thu, 8 Jan 2004 12:18:23
+0000:

>I suspect that GCJ on Intel uses the 80-bit extended-precision
>floating point registers (which are the gcc default, in C also) while
>the other virtual machines probably use strict double-precision.
>
>I don't know much about GCJ but I'm sure the developers are aware of
>the issue, so there may be an option to control it.

Java has a special attribute for classes/methods, fpstrict, which tells a
virtual machine to use IEEE 64-bit precision for all results of
intermediate calculations. (A double method parameter/result or field
load/store must be rounded to 64-bit even without an fpstrict
declaration, IIRC). As far as I know, gcj doesn't yet correctly implement
this, but that is something that wouldn't matter much for Classpath --
the gcj people will certainly fix this bug eventually.

So, an fpstrict declaration would give us the same result everywhere.
However, would this really solve the problem of very small discriminants?
Couldn't it be the case that the calculated discriminant is inside the
IEEE 64-bit range, but so close to zero that the further calculations are
outside the representable range?

Please apologize if my question is stupid. I don't know much about
scientific computing or error propagation; my background is pretty much
limited to <http://citeseer.nj.nec.com/goldberg91what.html>.

> > Could it be that the test for (disc == 0) should actually be replaced by
> > something like (fabs(disc - 0.0) < EPSILON)? If so, which value is
> > appropriate for EPSILON?
>
>The best value is 0, as there is no natural choice for epsilon (it
>introduces an arbitrary constant).
>
>My recommendation: choose test coefficients which are exact in binary
>(e.g. in this case multiply the polynomial by 5) to avoid the problem.

Actually, I don't understand why fixing the test case would help. Of
course, one could remove the testlet from the test suite, but user
programs still would sometimes get bad results for their input.

Do people on the Classpath mailing list have an opinion?

-- Sascha

Sascha Brawer, address@hidden, http://www.dandelis.ch/people/brawer/ 






reply via email to

[Prev in Thread] Current Thread [Next in Thread]