Ben,
If you try it with print instead of unpack you will get the same result.
I don't think it's an unpack problem.
Patrick
On 8/12/05, Benjamin Holzman <[EMAIL PROTECTED]> wrote:
> 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: [email protected]; [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
>
>
>
--
=====================
Patrick LeBoutillier
Laval, Québec, Canada
