Re: Force currency view

If this is any part of an actual system, and not just a programming assignment, you will be well served to stay away from floating point numbers when adding currencies. See What Every Scientist Should Know About Floating-Point Arithmetic or search the monastery for floating point accuracy.

One thing that you can do is do your calculations in cents, and only do the conversion for display purposes ($cents / 100).

Update: Update to more long-lived link. Thanks to HalNineThousand below.

--MidLifeXis

Comment on Re: Force currency view

Replies are listed 'Best First'.
Re^2: Force currency view by HalNineThousand (Beadle) on Feb 08, 2011 at 19:15 UTC
Your first link ("What Every Scientist...") has gone 404. I found another copy of it elsewhere. While you can still read the one at sun.com in the Google cache, I figure that's not reliable since Oracle is re-arranging a lot, so I have a full like to it here. (I'm printing the full link as is for reference.) www.math.umd.edu/~jkolesar/mait613/floating_point_math.pdf	[reply]
Re^2: Force currency view by bibliophile (Prior) on Feb 08, 2011 at 14:45 UTC
Wish I could double-upvote this! -Bib	[reply]
Re^2: Force currency view by locked_user sundialsvc4 (Abbot) on Feb 08, 2011 at 19:13 UTC
For the same reasons, it is wise to use “currency” field-types in your SQL database if it has them ... and if its implementation of that field-type is not merely “in name only.” For example, in the well-known case of Microsoft Access (JET), currency is implemented as a scaled integer: the value is multiplied by 10,000, so that there is a fixed 4-digit accuracy. Since Perl does not (AFAIK...) have direct support for such a data-type, you might not wish to do a long series of calculations involving currency in Perl, whereas a `CALC SUM()` query (since it is being carried out by the SQL engine) would retain accuracy. Ironically enough, there are countless examples out there of spreadsheets which have numeric-precision issues of this type.