Applications using Decimal versus double . .

Question

I wanted to see if folks were using decimal for financial applications instead of double. I have seen lots of folks using double all over the place with unintended consequences . .

Do you see others making this mistake . . .

Answer 1

We did unfortunately and we regret it. We had to change all doubles to decimals. Decimals are good for financial applications. You can look at this article A Money type for the CLR:

A convenient, high-performance money structure for the CLR which handles arithmetic operations, currency types, formatting, and careful distribution and rounding without loss.

Answer 2

Yes, using float or double for financials is a common mistake, leading to much, much pain. decimal is the most obvious choice in this scenario.

For general knowledge, a good discussion of each is here (float/double) and here (decimal).

Answer 3

This is not as obvious as you may think. I recently had the controller of a large corporation tell me that he wanted his financial reports to match what Excel would generate, which is maintaining calculated results internally at maximum precision and only rounding at the last minute for display purposes. This means that you can't always match the Excel answers by manual calculations using only displayed values. His explanation was that there were multiple algorithms for generating the results, each one doing rounding at a different place using decimal values, therefore potentially generating conflicting answers, but the Excel method always generated the same answer.

I personally think he's wrong, but with so many financial people using Excel without understanding how to use it properly for financial calculations, I'll bet there's a lot of people agreeing with this controller.

I don't want to start a religious war, but I'd love to hear other opinions on this.

Answer 4

If it is "scientific" measurement (I mean weight, length, area etc) use double.

If it is financial, or has anything to do with law (e.g. the area of a property) then use decimal.

The hard part is rounding.

If the tax is 2.4% do you round in the details or after the sum?

Most of the time yo have to do both (AND fix the difs)

Answer 5

I've run into this a few times. Many languages have nothing of the sort built in, and to someone who doesn't understand the problem it seems like just another hassle, especially if it looks like it works as intended without it.

Answer 6

I have always used Decimal. At least when I had a language that supports it. Otherwise, rounding errors will kill you.

Answer 7

I totally agree on correctness issues of floating point vs decimal mentioned above, but many financial applications are performance critical.

In such cases you will consider to use float/double as decimal has great impact on performance in systems where decimal types are not supported in hardware. And still it is possible to wrap floating point types in higher level classes (e.g. Tax, Commission, Balance, Dividend, Quote, Tick, etc...) that represent domain model and encapsulate all rounding logic as well as valid operators on these types and their interactions. And yes - in some projects I have implemented custom rounding functions to squeeze up to 20% more out of calculations compared to .NET or win32 methods.

Another thing to consider is whether you pass your objects out of process, as serializing decimals which are usually 4 integers and passing them over the wire is much more CPU intensive (esp if not supported) and results in significantly more bandwidth and larger memory footprint.