[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
## Fwd: Quadratic and cubic equations

**From**: |
Andrew Haley |

**Subject**: |
Fwd: Quadratic and cubic equations |

**Date**: |
Thu, 8 Jan 2004 17:05:15 +0000 |

Sascha Brawer writes:
>* ---------------- Begin Forwarded Message ----------------*
>* Subject: Re: Quadratic and cubic equations*
>* Date Sent: Wednesday, January 7, 2004 3:17 PM*
>* From: Sascha Brawer <address@hidden>*
>* To: Brian Gough <address@hidden>*
>* CC: Mark Wielaard <address@hidden>, Michael Koch <address@hidden>*
>* *
>* Hi Brian*
>* *
>* we have a problem with solving a specific quadratic equation in GNU*
>* Classpath. For your convenience, I've re-written the problematic equation*
>* as a patch to the GSL test suite (gsl/poly/test.c); see below.*
>* *
>* I suspect that the problem is the test for (disc == 0) in gsl/poly/*
>* solve_quadratic.c, line 61. With the Java version of your code, we get a*
>* very small negative number in gcj (the Java front-end for the GCC) on IA-*
>* 32, and exactly 0.0 with some other Java Virtual Machines.*
>* *
>* 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?*
I don't think so, no. The problem is that 0.1 cannot be represented
exactly, so it's a matter of whether the discriminant ends up being a
very small positive number, a small negative number, or zero.
solveQuadratic isn't wrong: its argument is.
It looks to me like this is a test of exact java strictfp compliance.
gcj fails, because it isn't strictfp compliant.
Andrew.