If you want a default decimal floating-point type, the only defensible choice is the decimal128 type standardized by IEEE 754. It has a fully-defined arithmetic, specified by experts who have spent their careers thinking about the issues involved, and is wide enough to exactly represent the US national debt in every currency used on earth.
There are situations where other decimal floating-point types are appropriate, but if you do not understand the tradeoffs you are making, you should be using decimal128.
I made a few notes the last time I saw this type come up somewhere:
- It has significantly less exponent range than IEEE decimal64 (it effectively throws away almost three bits in order to have the exponent fit in a byte; 2^56 is ~7.2E16, which means that it can represent some, but not all, 17-digit significands; the effective working precision is 16 digits, which actually requires only ~53.15 bits).
- Even if you weren’t going to use those extra bits for exponent, they could be profitably used for other purposes.
- Lack of infinity is a mild annoyance.
- Rounding is biased for add/sub/mul, broken for divide.
- It's not significantly more computationally efficient than the IEEE formats, despite handwaving by the author.
----
Edit: I would be remiss not to note that Intel has made available a well-tested complete implementation of IEEE 754 decimal64 and decimal128 under 3-clause BSD: http://www.netlib.org/misc/intel/
I don't know how much effort Intel is allocating to this project; I sent a bug report to the author listed on that page in 2015. The bug was acknowledged and fixed, with a new release out in "several days", but nothing yet.
There are situations where other decimal floating-point types are appropriate, but if you do not understand the tradeoffs you are making, you should be using decimal128.
I don't agree with everything in Jens Nockert's "silly review", but he's right about a lot of things: http://blog.aventine.se/2014/03/09/a-silly-review-of-dec64.h...
I made a few notes the last time I saw this type come up somewhere:
- It has significantly less exponent range than IEEE decimal64 (it effectively throws away almost three bits in order to have the exponent fit in a byte; 2^56 is ~7.2E16, which means that it can represent some, but not all, 17-digit significands; the effective working precision is 16 digits, which actually requires only ~53.15 bits).
- Even if you weren’t going to use those extra bits for exponent, they could be profitably used for other purposes.
- Lack of infinity is a mild annoyance.
- Rounding is biased for add/sub/mul, broken for divide.
- It's not significantly more computationally efficient than the IEEE formats, despite handwaving by the author.
----
Edit: I would be remiss not to note that Intel has made available a well-tested complete implementation of IEEE 754 decimal64 and decimal128 under 3-clause BSD: http://www.netlib.org/misc/intel/