Proposal for Decimal64 and Decimal128 value-based classes
Raffaello Giulietti
raffaello.giulietti at gmail.com
Wed Mar 31 20:13:55 UTC 2021
Hi,
I think there's a misunderstanding about the nature of IEEE 754
Decimal<n> (e.g., Decimal64), the subject of this thread, and the nature
of SQL DECIMAL(p, s).
SQL DECIMAL(p, s) represent *fixed* point decimal numbers, with an
overall maximum precision p and a scale s, the number of digits to the
right of the decimal point (both parameters can be selected freely
inside some ranges). For example, DECIMAL(2, 1) can represent only the
values
-9.9, -9.8, ..., 9.8, 9.9
and that's it.
Thus, the sum 6.6 + 7.7 overflows, as well as the product 2.9 * 4.
IEEE decimals are *floating* point decimal numbers. A hypothetical
decimal of precision 2 can represent values of the form c*10^q, where
integer c meets |c| < 100 (that is, max two digits) and integer q is
limited in some range. It covers the values above and much more, for
example, 0.012 (=12*10^(-3)) and -3.4E2 (=-34*10^1).
The sum 6.6 + 7.7 produces 14 because the mathematical result 14.3 is
rounded to the closest number of precision 2 (assuming
RoundingMode.HALF_EVEN). By the same token, the product 2.9 * 4 produces
12, which is 11.6 rounded to 2 digits.
But really, the position of the decimal point is floating.
IEEE decimals and SQL decimals are fundamentally different and ave
different arithmetic, so I wouldn't recommend using the proposed classes
for JDBC.
On the positive side, SQL decimals, are easier to implement if the
maximum allowed p in DECIMAL(p, s) is reasonable, say 38. But that's
another topic.
Greetings
Raffaello
More information about the core-libs-dev
mailing list