Proposal for Decimal64 and Decimal128 value-based classes

[Raffaello Giulietti]

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