Re: what did I just see..?

[BillKSmith]

In practice, floating-point errors are seldom a problem. Look at your output carefully and see how small the error really is. The default print format can be annoying (as you have discovered). You can avoid this by using printf to round to your required precision.

[LanX]

> In practice, floating-point errors are seldom a problem

Sorry, I must disagree.

I know of a case where fiscal authorities rejected a calculation because it was 1 cent off. Which led to a missed deadline and penalty payments, IIRC.

If you need cent accuracy then calculate in cents. Never floats!

PS: And if you do accounting, inform yourself about the required precision and rounding rules.

[Your Mother]

I got a threatening letter from American Express for my Amazon.com corporate card—which I hadn’t used in a full year—telling me to pay up on my outstanding balance or else! The amount I owed: $0.00. :P

[BillKSmith]

I knew a man with the same problem. He solved it with a check for $0.00. I do not think it was cashed.

[LanX]

Scandalous!

I hope you learned the lesson and payed your debts.

[stevieb]

I now have a brand new understanding of the term "nickel and dime-ing" ;)

[BillKSmith]

All your suggestions are true. My word 'seldom' probably does not apply to financial calculations. It may not be possible to exactly duplicate the calculations on the statement you receive from your financial institution. The printed decimal numbers on that statement are not exactly the same as the binary numbers in the bank's computer. It simply is not possible to recover every bit of those numbers. Any calculation that you do is flawed to start with. I have noticed that even Quicken's calculation of price/share never exactly agrees with my statement.

[LanX]

Financial calculations can be quite hairy AFAIK,

And for very good reasons.

They have special rounding rules and fixed precision like a tenth or hundreth of a cent.

Like

1 Euro = 1.95583 Deutsch Mark

But it's all integer in nature.

And bank rules may not be fiscal rules.

The only way I can think of to handle such systems transparently in Perl is using objects with overloaded operators. (With internal integers)