Hi Ken!
The way it works is that it just calls unpack("U*", $arg) and concatenates
the result with '.', then sends it over a socket to the java server (this is
why my original post included the results of unpack). I'm not sure how
things are reassembled on the java side, but that doesn't really seem to be
the problem. After investigating a bit more, I don't think it actually has
anything to do with stringification:
DB<1> x unpack "U*", 0.056200000000000028
0 48
1 46
2 48
3 53
4 54
5 50
DB<1> x unpack "U*", 0.056200000000000038
0 48
1 46
2 48
3 53
4 54
5 50
DB<1> x unpack "U*", 0.056200000000000048
0 48
1 46
2 48
3 53
4 54
5 50
DB<1> x unpack "U*", 0.056200000000000058
0 48
1 46
2 48
3 53
4 54
5 50
6 48
7 48
8 48
9 48
10 48
11 48
12 48
13 48
14 48
15 48
16 48
17 49
Ben
-----Original Message-----
From: Ken Williams [mailto:[EMAIL PROTECTED]
Sent: Friday, August 12, 2005 3:33 PM
To: Benjamin Holzman
Cc: inline@perl.org; [EMAIL PROTECTED]
Subject: Re: Rouding issue in Inline::Java
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
