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:   inline@perl.org
> > 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

Reply via email to