> 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! 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. There is another way I could solve my problem that would be less sensitive to this sort of issue-- there is a technique when rounding floating point number to add a small "tweak" value so that numbers whose floating point representation is slightly below the "true" value always round up. So if I had a number whose floating point representation was 0.00049999999999967 and I was trying to round it to the nearest 0.00001, I might add something like 0.0000000000001 so that it rounds to 0.00050. We actually use this technique in both the perl and java implementations, and it does improve the consistency between them, but the problem is that the tweak value we are using is a constant and turns out to be too small in some cases and falls below the limit of floating point accuracy. Actually figuring out what the appropriate tweak value should be is non-trivial, and of course would make the calculations slightly more expensive, but it would certainly make my two implementations agree. Nevertheless, it seems like it would be a good thing for Inline::Java to be as consistent as possible with perl. Ben
