views:

2066

answers:

4

As I started coding my first app I used NSNumber for money values without thinking twice. Then I thought that maybe c types were enough to deal with my values. Yet, I was advised in the iPhone SDK forum to use NSDecimalNumber, because of its excellent rounding capabilities.

Not being a mathematician by temperament, I thought that the mantissa/exponent paradigm might be overkill; still, googlin' around, I realised that most talks about money/currency in cocoa were referred to NSDecimalNumber.

Notice that the app I am working on is going to be internationalised, so the option of counting the amount in cents is not really viable, for the monetary structure depends greatly on the locale used.

I am 90% sure that I need to go with NSDecimalNumber, but since I found no unambiguous answer on the web (something like: "if you deal with money, use NSDecimalNumber!") I thought I'd ask here. Maybe the answer is obvious to most, but I want to be sure before starting a massive re-factoring of my app.

Convince me :)

+1  A: 

I've found it convenient to use an integer to represent the number of cents and then divide by 100 for presentation. Avoids the whole issue.

wisequark
The OP says "the option of counting the amount in cents is not really viable", but that doesn't make sense to me. Just change the amount from representing "the number of cents" to representing "the number of [smallest unit of currency]" and change the multiple for presentation.
James Williams
Yes, what James Williams said. All currencies can be correctly represented as integers.
Ahruman
Not quite. Currencies, yes, as long as you don't need to represent half a cent or whatever. You may then say “so count halves or tenths of a cent”, but what about quarters? Eighths? The only proper solution is NSDecimalNumber (or something like it), which puts off the problem to 10^-128 ¢.
Peter Hosey
HI Wisequark, and thanks for your answer. As a matter of facts it was perfect at the time it was posted, but it made me realise I needed to specify I was after internationalisation; I edited my post to accordingly and made this answer obsolete, my fault. Thank for helping me to focus. Davide
nutsmuggler
+3  A: 

(Adapted from my comment on the other answer.)

Yes, you should. An integral number of pennies works only as long as you don't need to represent, say, half a cent. If that happens, you could change it to count half-cents, but what if you then need to represent a quarter-cent, or an eighth of a cent?

The only proper solution is NSDecimalNumber (or something like it), which puts off the problem to 10^-128¢ (i.e.,
0.0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000001¢).

(Another way would be arbitrary-precision arithmetic, but that requires a separate library, such as the GNU MP Bignum library. GMP is under the LGPL. I've never used that library and don't know exactly how it works, so I couldn't say how well it would work for you.)

[Edit: Apparently, at least one person—Brad Larson—thinks I'm talking about floating-point somewhere in this answer. I'm not.]

Peter Hosey
+10  A: 

Marcus Zarra has a pretty clear stance on this: "If you are dealing with currency at all, then you should be using NSDecimalNumber." His article inspired me to look into NSDecimalNumber, and I've been very impressed with it. IEEE floating point errors when dealing with base-10 math have been irritating me for a while (1 * (0.5 - 0.4 - 0.1) = -0.00000000000000002776) and NSDecimalNumber does away with them.

I disagree with Peter's assessment of NSDecimalNumber. The class doesn't just add another few digits of binary floating point precision, it actually does base-10 math. This gets rid of the errors like the one shown in the example above.

Now, I'm writing a symbolic math application, so my desire for 30+ decimal digit precision and no weird floating point errors might be an exception, but I think it's worth looking at. The operations are a little more awkward than simple var = 1 + 2 style math, but they're still manageable. If you're worried about allocating all sorts of instances during your math operations, NSDecimal is the C struct equivalent of NSDecimalNumber and there are C functions for doing the exact same math operations with it. In my experience, these are plenty fast for all but the most demanding applications (3,344,593 additions/s, 254,017 divisions/s on a MacBook Air, 281,555 additions/s, 12,027 divisions/s on an iPhone).

As an added bonus, NSDecimalNumber's descriptionWithLocale: method provides a string with a localized version of the number, including the correct decimal separator. The same goes in reverse for its initWithString:locale: method.

Brad Larson
I never said it does floating-point. I said it has a finite range, which it does. Quoth the doc: “An instance can represent any number that can be expressed as mantissa x 10^exponent where mantissa is a decimal integer up to 38 digits long, and exponent is an integer from –128 through 127.”
Peter Hosey
Thanks for the answer, and especially for the link to Marcus Zarra, I am already refactoring to convert all my mony value to NSDecimalNumber.
nutsmuggler
+1  A: 

A better question is, when should you not use NSDecimalNumber to deal with money. The short answer to that question is, when you can't tolerate the performance overhead of NSDecimalNumber and you don't care about small rounding errors because you're never dealing with more than a few digits of precision. The even shorter answer is, you should always use NSDecimalNumber when dealing with money.

Tony