> 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.
Which naively might make one think that there's no difference in the
floating point representation of those numbers. However, the fact that
using these numbers from perl results in a different outcome than when I
ship them over to java leads me to believe that there is actually
something here. It must be some sort of a guard bit issue, but this is
territory I'm not terribly familiar with. Maybe I should just go ahead
and use the sprintf trick, since that seems to work, but I wish I
understood the issue better.
Thanks,
Ben
>
> 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: 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
>>
>>
>>
>
>
> --
> ====================Patrick LeBoutillier
> Laval, Québec, Canada
>
>
