On 02/08/2013 03:54 PM, Mike Miller wrote:
On Thu, Feb 7, 2013 at 1:27 PM, Daniel J Sebald wrote:
On 02/07/2013 09:32 AM, John W. Eaton wrote:
That's odd. Does the JVM set some FPU flags that are different from the
default that could affect the values that std::pow computes?
I was just about to email to propose that could be happening. Perhaps
there
is a bug in Java that isn't fully restoring the state of the CPU
registers
when it returns. Could be a machine specific problem.
tl;dr - Yes, Java does in fact modify the FPU control word which ends
up reducing the floating point precision that Octave normally
calculates with. I think the right way to handle this is to restore
the FPU flags so that values are computed consistently whether Java is
loaded or not. I will work on a changeset that restores the expected
precision on i386.
As Jordi said, nice detective work there.
Details:
From some searching and looking through the openjdk source, I gather
that the Java spec requires all floating point operations to be either
single or double, even intermediate results [1]. What this translates
to in the openjdk implementation (and probably others) is that they
disable the long double format at the hardware level in the x87 FPU
control word; this does not apply to x86_64. This is almost certainly
the source of all of the differences I have been observing, I will
soon have standalone C examples to confirm each of the effects.
Yeah, I suppose it's aiming to be device independent, so all one or all
the other, and no worries about the various combinations of address
length and register length.