Benjamin,
It looks to me like a stringification problem in Perl. I think that
for a double scalar variable, Perl stores the value internally both as
a double and as a string, and uses the correct one depending on the
context. Here is a small test I tried out:
$ perl -e'print 0.056200000000000028 . "\n"'
0.0562
It seems to me that when Perl internally needs to convert
0.056200000000000028 to a string, it converts it as "0.0562".
Therefore whenever Inline::Java uses that scalar in string context,
(namely while encoding it to send toJava), it gets "0.0562".
Your patch of using sprintf("%0.18", $arg) seems interesting and fixes
the issue because it creates a new string from the double
representation instead of using the internal string representation. I
may include that in a future release, but in the meantime it looks to
me like that small patch is the best way to go for you if it solves
your problem.
Patrick
On 8/12/05, Benjamin Holzman <[EMAIL PROTECTED]> wrote:
> Sorry, I should have mentioned that I am using Inline-Java-0.49
>
> > -----Original Message-----
> > From: Benjamin Holzman [mailto:[EMAIL PROTECTED]
> > Sent: Friday, August 12, 2005 9:48 AM
> > To: [email protected]
> > Cc: [EMAIL PROTECTED]
> > Subject: Rouding issue in Inline::Java
> >
> > 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
