yet another Java oddity

[Mike Miller]

I have recently discovered that std::pow can behave slightly
differently when the JVM is loaded into Octave on 32-bit Linux
(reproduced on RHEL, Fedora, and Debian). I have not yet seen any
differences on a 64-bit system.

The result is behavior like this:

octave:1> 1e-5 == 10^-5
ans =  1
octave:2> javaObject ("java.lang.String");
octave:3> 1e-5 == 10^-5
ans = 0
octave:4> test chop
  ***** assert (chop (e, 3), 2.72)
!!!!! test failed
assert (chop (e, 3),2.72) expected
 2.7200
but got
 2.7200
values do not match

Can anyone reproduce on Linux, or Windows even, and is this something
we need to address? Either by addressing the underlying bug/feature or
by tweaking those particular routines that are failing.

Please note this is not strictly an Octave problem, I wrote a small
C++ program that demonstrates the same behavior by calling std::pow
before and after initializing the JVM.

I did a little bit of digging and I wonder if this has to do with the
embedded math library in the JVM (fdlibm) somehow overriding standard
libm functions. Do any Java experts have any other insights into this?

-- 
mike