On Aug 13, 2005, at 9:04 AM, [EMAIL PROTECTED] wrote:
This just shows that you've hit the limit for floating-point accuracy.
The first few instances round down to 0.0562, but the final example
rounds up to 0.0562000000000001 .
Right, except that there actually must be a difference between the
floating point representation of 0.0562 and 0.056200000000000028,
because
when I explicitly send "0.056200000000000028" over to java instead of
0.0562, I get different results from my calculations!
Then I think that means Java uses a longer floating-point
representation on your machine than Perl does. 0.056200000000000028 in
perl will be chopped off at its floating-point limit and then
stringified to send to Java, whereas "0.056200000000000028" is already
a string, so is sent in its literal form, and apparently Java gives it
a more exact representation.
I still think that when Java is expecting a float, though, that it's a
mistake for Inline::Java to get the stringified form and run it through
unpack(U*). It would be better to get the numified form, no matter
what the *original* form is, and encode that in a way that the server
on the other side can translate easily to a Java float. That would
line up better with what perl subroutines/statements do when they
expect to work with a number.
I agree that it's
essentially noise, and I'm sure it would not be a problem if I weren't
trying to get the two implementations to always have the same result.
As
this library is used in a financial application, it does have some
economic significance, albeit rather small.
Yeah, I think you're right to try to track this down.
-Ken
