On Tuesday, May 14th, 2024 at 1:29 PM, Kostas Savvidis via Boost
On May 13, 2024, at 16:44, Matt Borland via Boost boost@lists.boost.org wrote:
Hello,
For the past year Chris Kormanyos and I have been working on a new library to implement IEEE 754 decimal floating point types. We are pleased to announce the library is now in beta, and can be found at: https://github.com/cppalliance/decimal, and the documentation is at: https://cppalliance.org/decimal/decimal.html
A first look convinces me that you have done a competent job, and that I might use the library, but I have concerns about the accompanying wording.
First, what are Decimal Floating Point Numbers? They are floating point numbers where the significand is stored in base-10 (decimal) instead of base-2 (binary). This means that numbers can be represented exactly ...
This does not mean that real numbers can be represented exactly, only that some DECIMAL fractions can be represented exactly. The advantage (if any) is coming not from storing the significand in base-10 but from the base of the floating exponent being 10: n*10^e where n and e are integers. BTW, there is no requirement to store n and e in decimal.
The way to store n and e are provided by IEEE 754 which offers two encodings: Binary Integer Decimal (BID) and Densely Packed Decimal (DPD). We use the former as it was targeted for software implementations, and the later is for hardware designers.
Similarly, in the Documentation, I see the dubious statement: "... floating point types store the significand ... as binary digits. Famously this leads to rounding errors:" The behaviour of 0.1+0.2 mentioned is not even a rounding error, probably the technical term is "representation error".
I will change the wording.
And also, in the Use Cases section: "The use case for Decimal Floating Point numbers is where rounding errors are significantly impactful such as finance. In applications where integer or fixed-point arithmetic are used to combat this issue Decimal Floating Point numbers can provide a significantly greater range of values."
I dont see how one could say they provide a significantly greater range of values.
I like the example from wikipedia for this: "For example, while a fixed-point representation that allocates 8 decimal digits and 2 decimal places can represent the numbers 123456.78, 8765.43, 123.00, and so on, a floating-point representation with 8 decimal digits could also represent 1.2345678, 1234567.8, 0.000012345678, 12345678000000000, and so on." I will add this to the docs.
Already, somebody replied that "This is a really needed library for native C++ big number math" ??? Sorry, but no. What DFP promise to do is correct elementary arithmetic with decimal fractions. As such, it is not clear who possibly needs math special functions in decimal... but ok, the standard says so.
The answer is two-fold. One of the goals of the library is that it will seamlessly plug into boost.math so you have a huge companion library from the start. By providing an implementation of say beta you will be able to use the beta distribution from boost.math without worrying about implicit conversions to binary floating point and back (which are disallowed by default anyway). Second, our longer term goal is ISO standardization so by providing a complete reference implementation we hope our proposal will be more compelling.
Instead, how do I do fixed-point arithmetic with Decimal Floating Point, i.e. what are the facilities in this library for calculating mortgage interest in dollars and cents, rounding the cents correctly at each stage? As it is, the doc is completely silent about this.
I can add a section on simple financial calculations. A trading firm that uses the library adopted it because the precision of a bitcoin (1 bitcoin = 100,000,000 Satoshis) exceeded what their in-house fixed-point arithmetic library could represent. They said the basic math operations, and functionality of <charconv> are what they need for now. Derivatives pricing calculations will need the aforementioned special functions and boost.math integration (The CDF of the normal distribution requires erf).
Finally, no references in the documentation, a good review of the state-of-the-art might be:
Decimal Floating-Point: Algorism for Computers Michael F. Cowlishaw https://www.cs.tufts.edu/~nr/cs257/archive/mike-cowlishaw/decimal-arith.pdf
Will add to the docs.
Cheers, Kostas
Thanks for the feedback, Matt