r/cpp•
RandomGuy256

Any update on the decimal proposal?

Hello,

Does anybody know if there has been any update on the decimal proposal?

The last document that I found about it is this one: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3871.html

Like calendar, I believe decimal would be a really good and useful addition to the standard library, especially for some areas like finance.

It would be great to see it in a future standard version.

Posted Apr 18, 2018, 12:34 PM UTC · edited

1416
Fazer2•

I have seen these questions about state of different proposals appear here and on Slack. Is there any centralized place to see it for all of them?

12
bames53•

I wonder if finance really wants a floating point type with decimal radix, or if a fixed point type would equally (or better) serve their needs.

One thing that might be worth putting in the standard library is a generic fixed point type of arbitrary radix, similar to the std::chrono duration types. So finance could have a fixed point type that's exact to 1/100th or 1/1000th, with well defined rounding. Or maybe this should be part of a generic units library.

9
TomSwirlymodern C++, DSP, Cython•

Having written rather too much financial software I can say for sure that fixed point is far more popular than floating.

In particular, the issue with floating point, decimal or not, is that if you exceed your precision in intermediate calculations, then it will just throw away the right-most digits silently, and you'll never know that you were off by a few cents - and it's extremely hard to detect that this will happen.

If you use fixed point numbers, it's significantly easier to detect that your next operation will overflow - more, if you do overflow, most of the errors will be gross mistakes (often adding two positives and getting a negative) which hopefully your other safeguards will catch.

6
tavi_•

What do you think, would decimal_for_cpp be too simpistic for financial stuff? https://github.com/vpiotr/decimal_for_cpp "Values are stored internally using 64-bit integer, so maximum number of digits is 18. Precision is user-defined, so you can use this data type for currency rates."

2
RasterTragedy•

Nah, the radix conversion causes rounding issues. Gotta have a radix that's a multiple of ten, or you're gonna have trouble representing 10¢

3
bames53•

By arbitrary radix I mean that you'd specify the radix. So if you want something that can exactly represent hundredths of dollars you'd specify that, e.g. similar to the way std::chrono allows you to have durations that exactly represent tenths, or sixtieths, or any fraction of a second; no rounding or approximation.

4
RasterTragedy•

If that was the direction taken, I think it'd be best to have a dedicated std::decimal type anyway, as an alias for std::fp<10> or whatever (or maybe std::fp<30> so that 1/3 has a terminating representation too (although I don't know if the different rounding from base10 math would make base30 math unacceptable to the finance guys (also also 30 is closer to 32 than 10 is to 16, so base-30 is more memory efficient--but I don't know if this practically matters, especially given that if you were to have five-bit digits, you'd either have digits spanning words or you'd have bits of words just dangling off the end; not part of any digit, not big enough to use, just sitting there and wasting space)).

Edit: If we're going the "base divisible by ten and three" route, then the best bet is probably base240; it's more efficient^1 than either base10 or base30 (10: 83.0% eff, 30: 98.3%, 240: 98.8%) and, at eight bits/digit, base240 works great with machine word sizes. (Unless you're working on something with <8b word width, I guess. The existence of such a thing would not surprise me, but it would hurt me.)

^1 log2(base)/ceil(log2(base))

2
ReversedGif•

I think you're overcomplicating this. Just because you're storing fixed point numbers doesn't mean you can't use base-2(56).

The way it would work would likely be that it's internally store "value*100" in an int64_t or something like that.

3
[deleted]•

[deleted]

1