Hmm, yeah, it looks like you're right. Devel::Peek confirms that the number has been stringified. I think a better fix would be to somehow convince unpack to use the NV field. Maybe I can just do $a = $arg + 0; instead of sprintf. I am going to give that a try.
Thanks, Ben -----Original Message----- From: Patrick LeBoutillier [mailto:[EMAIL PROTECTED] Sent: Friday, August 12, 2005 1:34 PM To: Benjamin Holzman Cc: inline@perl.org; [EMAIL PROTECTED] Subject: Re: Rouding issue in Inline::Java 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
