[nyrikki]

Decimal128 has exact rounding of decimal rules and preserves trailing zeros.

I don’t think Decimal64 has the same features, but it has been a while.

But unless you hit the limits of 34 decimal digits of significand, Decimal128 will work for anything you would use fixed point for, but much faster if you have hardware support like on the IBM cpus or some of the sparc cpus from Japan.

OPAP Agg functions as an example are an application.

[jcranmer]

> I don’t think Decimal64 has the same features, but it has been a while.

Decimal32, Decimal64, and Decimal128 all follow the same rules, they just have different values for the exponent range and number of significant figures.

Actually, this is true for all of the IEEE 754 formats: the specification is parameterized on (base (though only 2 or 10 is possible), max exponent, number of significant figures), although there are number of issues that only exist for IEEE 754 decimal floating-point numbers, like exponent quantum or BID/DPD encoding stuff.

[nyrikki]

You are correct, the problem is that Decimal64 has 16 digits of significand, while items like apportioned per call taxes need to be calculated with six digits past the decimal before rounding which requires about 20 digits.

Other calculations like interest rates take even more and cobol requires 32 digits.

As decimal128 format supports 34 decimal digits of significand, and has emulated exact rounding, it can meet that standard.

While items is more complex, requiring ~15-20% more silicon space in the ALU plus larger dataset size, compared to arbitrary precision libraries like BigNum it is more efficient for business applications.

This looks like a digestible cite:

https://speleotrove.com/decimal/decifaq1.html