Hi Benjamin,
When sending to Java, what's the prototype for the method you're
calling? If it's a number (float or double or whatever), then I agree,
it shouldn't be using SvPV, it should use SvNV to get the numerical
value directly. I've never looked at the internals of how Inline::Java
does this, though.
-Ken
On Aug 12, 2005, at 8:48 AM, Benjamin Holzman wrote:
I have encountered a rounding problem when sending floating-point
numbers
from perl to java using Inline::Java. This is on CentOS 4 on an Intel
pentium 4 with jdk 1.3.10 and perl 5.6.2. We have a math library with
dual
implementations; one in perl and one in java, and we have been seeing
sporadic differences. I have tracked the problem down to this: if I
take a
number like 0.056200000000000028 in perl and then send it to java using
Inline::Java, java just gets 0.0562, which leads to small differences.
I
confirmed that unpack "U*", $x yields the same values (48, 46, 48, 53,
54,
50) for $x = 0.0562 as well as $x = 0.056200000000000028, indicating
that,
at least to perl, there is no difference between these numbers.
However, if
$x = "0.056200000000000028", I get 48, 46, 48, 53, 54, 50, 48, 48, 48,
48,
48, 48, 48, 48, 48, 48, 48, 48, 48, 50, 56, as you might expect. If I
hack
Inline::Java::Class::CastArgument to sprintf("%0.18f", $arg) when
$proto is
'double', the differences between the perl library and the java
library go
away. I find this somewhat confusing, because I would have thought
that on
the same machine, perl's (c's) representation of a floating point
number and
java's would have agreed. Can anyone shed some light on what is going
on
here, and also what the most appropriate remedy might be?
Thanks,
Benjamin Holzman
