commit-classpath
[Top][All Lists]
Advanced

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

[commit-cp] [bugs #7123] Bad results for QuadCurve2D.solveQuadratic


From: Grzegorz B. Prokopski
Subject: [commit-cp] [bugs #7123] Bad results for QuadCurve2D.solveQuadratic
Date: Thu, 11 Nov 2004 01:09:39 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.7.3) Gecko/20041007 Galeon/1.3.17 (Debian package 1.3.17-2)

This mail is an automated notification from the bugs tracker
 of the project: classpath.

/**************************************************************************/
[bugs #7123] Latest Modifications:

Changes by: 
                Grzegorz B. Prokopski <address@hidden>
'Date: 
                Thu 11/11/04 at 05:45 (America/Montreal)

------------------ Additional Follow-up Comments ----------------------------
Regardless whether there's strictfp used or not having FPU
in  80-bit mode is not allowed by java specs.  There used to
be a proposal to introduce a special keyword "whatever math 
platform has"-like, but it didn't get thru.  Instead the
"default" requirements have been relaxed (to pretty much
exactly match x86 with FPU in 64bit presision mode, at
least for doubles) and stricfp keywork added (but none of
the free JVMs implements it anyway AFAIK)

Can you please try it with SableVM (on x86)?  I am 99% sure
it'd work the same as Sun's VM.  I'll fix it if it didn't.







/**************************************************************************/
[bugs #7123] Full Item Snapshot:

URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=7123>
Project: classpath
Submitted by: Sascha Brawer
On: Wed 01/07/04 at 13:58

Category:  None
Severity:  3 - Ordinary
Resolution:  None
Privacy:  Public
Assigned to:  brawer
Status:  Open
Platform Version:  Red Hat 8.x


Summary:  Bad results for QuadCurve2D.solveQuadratic

Original Submission:  The method java.awt.geom.QuadCurve2D.solveQuadratic 
sometimes does not return the right results for the following equation:

  (x^2)/10 + 20x + 1000 = 0

Expected result: -100

This equation is tested by Mauve; see gnu.testlet.java.awt.geom.QuadCurve2D.

The problem occurs with various versions of gcj, compiling for IA-32. However, 
it does NOT occur when executing the same Mauve testlet on jamvm, using the 
same implementation for java.awt.geom.QuadCurve2D.

It turned out that a small Java test program for computing the equation's 
discriminant gives a very small negative number when run on gcj/IA-32, but 
exactly zero when run on jamvm or the Sun J2SE 1.4.1_01.


Follow-up Comments
------------------


-------------------------------------------------------
Date: Thu 11/11/04 at 05:45         By: Grzegorz B. Prokopski <gadek>
Regardless whether there's strictfp used or not having FPU
in  80-bit mode is not allowed by java specs.  There used to
be a proposal to introduce a special keyword "whatever math 
platform has"-like, but it didn't get thru.  Instead the
"default" requirements have been relaxed (to pretty much
exactly match x86 with FPU in 64bit presision mode, at
least for doubles) and stricfp keywork added (but none of
the free JVMs implements it anyway AFAIK)

Can you please try it with SableVM (on x86)?  I am 99% sure
it'd work the same as Sun's VM.  I'll fix it if it didn't.


-------------------------------------------------------
Date: Wed 11/10/04 at 22:07         By: Sven de Marothy <smarothy>
Having done some testing (see comments in GCC bugzilla), I've determined this 
is not a bug in classpath, but rather a rounding inaccuracy because the 
processor is in 80-bit precision mode and not using 64-bit rounding. 

I'm not sure as to whether this is allowed or not, since the API does not 
specifiy if the method should use strictfp or not.


-------------------------------------------------------
Date: Thu 07/29/04 at 21:16         By: Mark Wielaard <mark>
This is now also tracked in the GCC AWT bugzilla as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16825

-------------------------------------------------------
Date: Wed 07/07/04 at 11:50         By: 0 <None>
Could this bring some clarity to the issue?

http://www.srware.com/linux_numerics.txt

Is the FPU in 80-bit precision mode?

-------------------------------------------------------
Date: Sun 05/23/04 at 09:36         By: 0 <None>
some more on this...
my understanding of (non-) strictfp is, that intermediate results and local 
variables can be of any precision the implementation feels right. So, it would 
be completly legal (and not too agressive) to use the intermediate value of d 
for comparison. With 'agressive optimizer' i originally meant something like 
java -> native compilers (like gnu java), which may introduce this kind of 
optimizing in a late code emitting step, when fine-print semantics of the 
source language are not available.
there is another problem in this innocent function: assuming we find a (single) 
root. what, if some suspicous mind gets the idea to stick this into the 
original polynom to get a zero-result? how to compute this? 
y = a*x*x + b*x +c ? or 
y = (a*x)+b)*x +c ? or the same in a loop?
this would give (upto) 3 different results - some of which may even be zero...
maybe the whole function is even useless altogether - lets assume we let the 
values for a, b and c run from -MAX_DOUBLE to +MAX_DOUBLE and and look at all 
the results. The result-set is large, but it is finite. A large part of it 
gives the trivial 'no root'-cases - that's simple. Then we have a large part of 
trivial 'double-root' cases. 
How large is the remaining part? How much of this is numerically correct? 10^-3 
? 10^-6? 10^-9 ? less ??
Other functions, like sin() or sqrt() are much much better in their outcome.

dvholten


-------------------------------------------------------
Date: Fri 05/21/04 at 22:08         By: Sascha Brawer <brawer>
Actually, the instruction in question is dcmpl or dcmpg, not dsub. But the 
dcmpX arguments must equally be converted to the closest value representable in 
64-bit IEEE 754: 
http://java.sun.com/docs/books/vmspec/2nd-edition/html/Instructions2.doc3.html#dcmpop

-------------------------------------------------------
Date: Fri 05/21/04 at 21:41         By: Sascha Brawer <brawer>
A reply to dvholten's comment that "an aggressive optimizer might use the 
(extended?) precision value": I think this optimization would be a bit too 
aggressive, as it would be in conflict to the JVM specification. The dsub 
instruction mandates value set conversion to IEEE 64-bit.

See 
http://java.sun.com/docs/books/vmspec/2nd-edition/html/Instructions2.doc3.html#dsub

-------------------------------------------------------
Date: Sun 05/16/04 at 22:17         By: 0 <None>
I'm currently hacking this code (see mailing list), and I don't think this is 
much of a problem. 
"Floating point operations are like moving around piles of sand, every time you 
do it, you lose some sand and picke up some dirt." An exact result should never 
be expected.

Anyway, this routine is likely not intended as the end-all of quad solvers, but 
rather as a utility for calculating bezier intersections, in which case it fits 
the bill. 



-------------------------------------------------------
Date: Sat 05/08/04 at 11:59         By: 0 <None>
here is another link to some fp-insights:
http://en.wikipedia.org/wiki/Loss_of_significance

IMO, the way to compute and use the discriminant is suspicious at least - in 
any implementation: to perform some fp-arithmetic, subtract the results and 
compare to (exact) 0 is a guess, nothing more. I think, a systematic search for 
single solutions will produce a large number of slightly wrong results. The 
current way of computing
d = b * b - 4 * a * c
if ( d == 0 ) ...
leaves too much room for different implementations: an aggressive optimizer 
might use the (extended?) precision value of d from top-of-stack, instead of 
reloading (rounded) double-precision d.  in the case, where b*b and 4*a*c is 
almost equal, the further use of d ( or sqrt(d) ) is even more inaccurate.
so, it seems, a 'real good' algorithm is somewhat sophisticated - or just use 
this simpler one with a defined epsilon-constant.

dvholten


-------------------------------------------------------
Date: Sun 05/02/04 at 20:18         By: 0 <None>
This nice article gives lots of insight into floating-point-things.

http://docs.sun.com/source/806-3568/ncg_goldberg.html

hth
dvholten

-------------------------------------------------------
Date: Tue 03/16/04 at 00:08         By: Sascha Brawer <brawer>
Brian Gough (address@hidden) wrote on 2004-01-08:

The coefficient 0.1 does not have an exact representation in binary,
so the number used will depend on the precision and the rounding
mode.  This will cause different results.

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.

 > 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.

-------------------------------------------------------
Date: Wed 01/07/04 at 14:15         By: Sascha Brawer <brawer>
The problematic equation has been re-formulated as a test case for the test 
suite of the GNU Scientific Library. It fails there, too.

See the attached e-mail to Brian Gough <address@hidden>, author of the GNU 
Scientific Library.




CC List
-------

CC Address                          | Comment
------------------------------------+-----------------------------
dvholten --AT-- computer --DOT-- org | 
bjg --AT-- network-theory --DOT-- co --DOT-- uk | Brian Gough, GNU Scientific 
Library
mark                                | 
mkoch                               | 



File Attachments
-------------------

-------------------------------------------------------
Date: Wed 01/07/04 at 14:15  Name: LetterToBrian.txt  Size: 1.58KB   By: brawer
E-Mail sent to Brian Gough, author of GNU Scientific Library
http://savannah.gnu.org/bugs/download.php?item_id=7123&amp;item_file_id=932






For detailed info, follow this link:
<http://savannah.gnu.org/bugs/?func=detailitem&item_id=7123>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/







reply via email to

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