Re^4: Numeric Comparisons Randomly Giving the Wrong Result

What about this situation - assuming you can get a large loan in Galactic Credits, at 0% APR, for a year:

use strict;
use warnings;
use diagnostics;

my $amount = 1e9;
my $months = 12;

my $repayment = $amount/$months;
print "Monthly repayment = $repayment\n";

use integer;
$repayment = $amount/$months;
print "Monthly repayment = $repayment\n";
[download]

prints out:

Monthly repayment = 83333333.3333333
Monthly repayment = 83333333

which is not the same thing!

On a different, but related note, increasing the loan to 1e12 Galactic Credits, gives this:

Monthly repayment = 83333333333.3333
Monthly repayment = 0

That's because the loan amount is too big to hold in an integer (on my machine anyway):

perl -le'use POSIX;print for SHRT_MAX, INT_MAX, LONG_MAX, FLT_MAX, DBL
+_MAX;'
32767
2147483647
2147483647
3.40282346638529e+38
1.79769313486232e+308
[download]

So use the integer pragma with caution!

Comment on Re^4: Numeric Comparisons Randomly Giving the Wrong Result Select or Download Code

Replies are listed 'Best First'.
Re^5: Numeric Comparisons Randomly Giving the Wrong Result by Corion (Patriarch) on Sep 30, 2010 at 14:52 UTC
If you do fancy calculations, like repeatedly adding fractional parts of things, you need to give deep thought to all your calculations anyway, whether they are in floating point or integer numbers. I don't see where that part of my statement collides with your example.	[reply]
Re^6: Numeric Comparisons Randomly Giving the Wrong Result by mjscott2702 (Pilgrim) on Sep 30, 2010 at 14:56 UTC
It doesn't, and I agree with you 100.00000%. I was just pointing out that simply enabling the integer pragma isn't a one-stop solution - in fact, it reinforces your point about always giving deep thought to your calculations anyway.	[reply]
Re^5: Numeric Comparisons Randomly Giving the Wrong Result by halfcountplus (Hermit) on Sep 30, 2010 at 14:51 UTC
Sure, but the point is that altho you see a number ending with ".33333" printed out, it may not have that exact value in memory, and if further calculations are performed, that could become apparent. Similarly, of course, decimal numbers cannot truly represent the fraction 1/3. The "galactic credits" example is a bit disingenuous -- when was the last time you wrote a check for $833.3333 to pay your mortgage? Again, money has a fixed precision of two decimal places and needs to be kept there. If rounding is an issue, use tenths of a cent as an integer unit and write a rounding function. This could be as simple as >=/< 5, since integers are round down (so what would have been 4.9999999 tenths of a cent will be 4, anything more will be five). If you think it is more appropriate to round up (the bank wants at least what it is owned, ie, $8.34) you should still limit the precision with integers, otherwise you will end up with numbers like 1000.00000001 due to the floating point issues that motivated the original post, and if those are rounded up and collated you could be looking at whole dollars of error.	[reply]
Re^6: Numeric Comparisons Randomly Giving the Wrong Result by mjscott2702 (Pilgrim) on Oct 01, 2010 at 10:59 UTC
OK, so the example was a bit artificial. But the point still holds, especially for a financial/scientific application. Ever watch Brewster's Millions?	[reply]