| **DONOTDELETE** |
| (Unregistered) |
| 08/22/03 11:21 AM |
some more on that
|
i read a complaint about slow floating-point performance somewhere in sun bugbase. the response was: the old version was fast, but wrong (i.e. not precise enough) - and thats right - what for are fast, but wrong results? have you checked the outcome of your benchmark against the strictfp-results - not just the time?
in my version of jdk1.3.1-01 the Math-class is already strictfp.
As far as i remember the 'wrong' results came from 'wrong' angle-normalization in trigonometric functions, originating from some architecture-'problem' in intel fpu. You should really try to find the bug-report...
| **DONOTDELETE** |
| (Unregistered) |
| 11/03/03 04:38 AM |
|
Re: some more on that
|
For example:
http://developer.java.sun.com/developer/bugParade/bugs/4857011.html
Which has a really good reply I would say, so I'm not sure what Jeff means with " submitted some bug reports to Sun about this serious performance regression, but received no meaningful response".
"
Example in there: The value of sine for the floating-point number Math.PI is around
1.2246467991473532E-16
while the computed value for the algorithm used in java 1.3.1 is
1.2246063538223773E-16
^
In other words, the returned result is only accurate to about 5 digits
instead of the full 15-17 digit precision of double. Instead of a 1/2
ulp or 1 ulp error, the error is about 1.64e11 ulps, over *ten
billion* ulps."
Accurate to the fifth digit only in that example is not very good, but as they also say, might be enough in some circumstances, but hardly something to aim for in a math lib!
The x87 FPU fsin and fcos gives these bad results and maybe that C-program uses them and gives the same bad results (old instructions, designed before "modern" algorithms, see bug report)
| **DONOTDELETE** |
| (Unregistered) |
| 01/04/06 07:46 AM |
|
Re: some more on that
|
Quote:
For example:
http://developer.java.sun.com/developer/bugParade/bugs/4857011.html
"
Example in there: The value of sine for the floating-point number Math.PI is around
1.2246467991473532E-16
while the computed value for the algorithm used in java 1.3.1 is
1.2246063538223773E-16
^
In other words, the returned result is only accurate to about 5 digits
instead of the full 15-17 digit precision of double. Instead of a 1/2
ulp or 1 ulp error, the error is about 1.64e11 ulps, over *ten
billion* ulps."
We have: sin(pi)=1.2246063538223773E-16 in jre 1.3.1
sin(pi)=1.2246467991473532E-16 in jre 1.4
We know that exact value of sin(pi) is zero.
So, the value we had in jre 1.3 for sin(pi) is better than jre 1.4???