public inbox for java-prs@sourceware.org
help / color / mirror / Atom feed
* [Bug libgcj/16122] gij - Incorrect result due to computations in extended precision on x86
[not found] <bug-16122-5724@http.gcc.gnu.org/bugzilla/>
@ 2006-02-14 15:45 ` aph at gcc dot gnu dot org
2006-02-14 17:03 ` vincent at vinc17 dot org
1 sibling, 0 replies; 6+ messages in thread
From: aph at gcc dot gnu dot org @ 2006-02-14 15:45 UTC (permalink / raw)
To: java-prs
------- Comment #4 from aph at gcc dot gnu dot org 2006-02-14 15:45 -------
A bit more explanation.
The problem is caused by the fact that 9007199254740994.0 + 0.9999847412109375
is carried out in extended precision, and the result is rounded to
9007199254740995. In double precision, the result of this calculation is
rounded to 9007199254740994.
When the extended-precision value is rounded to double for storing, it is
rounded (again) to 9007199254740996.
So, double rounding leads gij to return a value of d that is 2.0, whereas it
should be 0.0.
Note however, that the true accurate value for d, calculated at infinite
precision, is 1-(2^-16). So, the absolute error for gcj is 1+(2^-16) and the
absolute error with correct rounding is 1-(2^-16). (I'm not surprised this
hasn't been reported as a problem with any real applications!)
It might be worth setting the floating-point precision of gcj to double, but
that would only fix the double-precision case, and I presume we'd still have
the same double rounding problem for floats.
And in any case, I do not know if libcalls would be affected by being entered
with the FPU in round-to-double mode. We might end up breaking things.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16122
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug libgcj/16122] gij - Incorrect result due to computations in extended precision on x86
[not found] <bug-16122-5724@http.gcc.gnu.org/bugzilla/>
2006-02-14 15:45 ` [Bug libgcj/16122] gij - Incorrect result due to computations in extended precision on x86 aph at gcc dot gnu dot org
@ 2006-02-14 17:03 ` vincent at vinc17 dot org
1 sibling, 0 replies; 6+ messages in thread
From: vincent at vinc17 dot org @ 2006-02-14 17:03 UTC (permalink / raw)
To: java-prs
------- Comment #5 from vincent at vinc17 dot org 2006-02-14 17:03 -------
(In reply to comment #4)
> Note however, that the true accurate value for d, calculated at infinite
> precision, is 1-(2^-16). So, the absolute error for gcj is 1+(2^-16) and the
> absolute error with correct rounding is 1-(2^-16). (I'm not surprised this
> hasn't been reported as a problem with any real applications!)
Note that some algorithms may be sensitive to this difference. I give an
example in <http://www.vinc17.org/research/publi.en.html#Lef2005b> (The
Euclidean division implemented with a floating-point division and a floor); the
effect of extended precision is dealt with in Section 5.
A second problem is the reproducilibity of the results on various
architectures. Under probabilistic hypotheses, there should be something like 1
case over 2048 that is incorrectly rounded (in the real world, this is much
less).
> It might be worth setting the floating-point precision of gcj to double, but
> that would only fix the double-precision case, and I presume we'd still have
> the same double rounding problem for floats.
Yes, however doubles are nowadays used much more often than floats, IMHO. I
think that fixing the problem for the doubles would be sufficient (as it is
probably too difficult to do better), though not perfect.
> And in any case, I do not know if libcalls would be affected by being entered
> with the FPU in round-to-double mode. We might end up breaking things.
The only glibc function for which problems have been noticed is pow in corner
cases. See <http://sources.redhat.com/bugzilla/show_bug.cgi?id=706>. And it is
also inaccurate when the processor is configured in extended precision; so in
any case, users shouldn't rely on it. I'd be interested in other cases, if any.
More information here: <http://www.vinc17.org/research/extended.en.html>
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16122
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug libgcj/16122] New: gij - Incorrect result due to computations in extended precision on x86
@ 2004-06-21 20:24 debian-gcc at lists dot debian dot org
2004-06-22 6:04 ` [Bug libgcj/16122] " pinskia at gcc dot gnu dot org
` (3 more replies)
0 siblings, 4 replies; 6+ messages in thread
From: debian-gcc at lists dot debian dot org @ 2004-06-21 20:24 UTC (permalink / raw)
To: java-prs
[forwarded from http://bugs.debian.org/255525]
3.3.4 release and 3.4.1 branch, bug submitter writes:
Concerning the following Java source:
------------------------------------------------------------------
// $Id: test.java 3734 2004-06-21 15:36:52Z lefevre $
public class test {
public static void main(String[] args) throws Exception {
test t = new test();
t.doTest();
}
volatile double x, y, z, d;
public void doTest() {
x = 9007199254740994.0; /* 2^53 + 2 */
y = 1.0 - 1/65536.0;
z = x + y;
d = z - x;
System.out.println("z = " + z);
System.out.println("d = " + d);
}
}
------------------------------------------------------------------
I've compiled it with "gcj -C test.java" (GCC 3.3.4).
Both IBM's and Sun's JVM give the correct result:
greux:~/wd/src/fp> /global/greux/lefevre/IBMJava2-131/jre/bin/java test
z = 9.007199254740994E15
d = 0.0
greux:~/wd/src/fp> /usr/local/j2re1.4.1/bin/java test
z = 9.007199254740994E15
d = 0.0
but not gij:
greux:~/wd/src/fp> /usr/bin/gij test
z = 9.007199254740996E15
d = 2.0
gij should switch the FPU of the x86 processor
(Pentium III in my case) to rounding in double precision to avoid the
effect of the "double rounding" (you may find some information about
this effect here: <http://www.srware.com/linux_numerics.txt>).
--
Summary: gij - Incorrect result due to computations in extended
precision on x86
Product: gcc
Version: 3.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
GCC host triplet: i486-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16122
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2006-02-14 17:03 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <bug-16122-5724@http.gcc.gnu.org/bugzilla/>
2006-02-14 15:45 ` [Bug libgcj/16122] gij - Incorrect result due to computations in extended precision on x86 aph at gcc dot gnu dot org
2006-02-14 17:03 ` vincent at vinc17 dot org
2004-06-21 20:24 [Bug libgcj/16122] New: " debian-gcc at lists dot debian dot org
2004-06-22 6:04 ` [Bug libgcj/16122] " pinskia at gcc dot gnu dot org
2004-06-22 6:05 ` vincent at vinc17 dot org
2004-06-22 9:58 ` vincent at vinc17 dot org
2004-06-22 16:56 ` mckinlay at redhat dot com
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).