Math.log(17197) produces inconsistent results between javac, jit, Math and StrictMath on various architectures.
Xerxes Rånby
xerxes at zafena.se
Mon May 24 12:55:02 UTC 2010
Hi
Im hoping to find someone who can enlighten me how to resolve a bug
where some hotspot JITs
fails the hotspot/test/compiler/6539464 jtreg regression test.
The testcase looks like:
public class Test {
static double log_value = 17197;
static double log_result = Math.log(log_value);
public static void main(String[] args) throws Exception {
for (int i = 0; i < 1000000; i++) {
double log_result2 = Math.log(log_value);
if (log_result2 != log_result) {
throw new InternalError("Math.log produces inconsistent results: " + log_result2 + " != " + log_result);
}
}
}
}
When running this testcase using various jvms / architectures i get varying results of the calculated log_result2 and log_result which
ARCH+JVM combination log_result (javac) log_result2 (jit) passes regression test?
ia32+OpenJDK Server VM (build 14.0-b16, mixed mode) 9.752490228984199 9.752490228984199 yes
arm+OpenJDK Shark VM (build 16.0-b13, mixed mode) 9.75249022898412 9.752490228984199 no
x86_64+OpenJDK 64-Bit Server VM (build 14.0-b16, mixed mode) 9.75249022898412 9.752490228984199 no
While trying to figure out whats the correct result for the log(17197) calculation i tested what StrictMath.log outputs:
StrictMath.log(17197) = 9.75249022898412
And in order to get an independent mathematically correct opinion of what log(17197) equals i asked wolfram alpha:
http://www.wolframalpha.com/input/?i=log%2817197%29
log(17197) = 9.7524902289841994797298917760120602447583441794533189705223...
or in short 9.752490228984199
So we have a situation where javac, jit, Math and StrictMath generates inconsistent results.
How do we resolve this situation?
Quoting the Math package java doc:
"If a method always has an error less than 0.5 ulps, the method always
returns the floating-point number nearest the exact result; such a
method is correctly rounded. A correctly rounded method is
generally the best a floating-point approximation can be; however,
it is impractical for many floating-point methods to be correctly
rounded. Instead, for the Math class, a larger error
bound of 1 or 2 ulps is allowed for certain methods"
Would this quotation imply that both log(17197) calculation results above are correct ( 9.752490228984199 and 9.75249022898412 )?
If both calculations are correct then I propose that we should change the hotspot/test/compiler/6539464 jtreg regression test to make all
JVM's pass the test when they are within +- 1 ulps from the mathematically correct answer of:
9.7524902289841994797298917760120602447583441794533189705223...
Cheers and have a great day!
Xerxes
More information about the core-libs-dev
mailing list