Proposal for Decimal64 and Decimal128 value-based classes

[Raffaello Giulietti]

Hi,

the intent of this proposal is to have numerical classes for *business 
and financial applications*, not to implement the IEEE 754-2019 spec for 
the sake of full coverage.

The goal is to have numerical classes that are lighter-weight and more 
efficient in terms of storage space and computation time wrt BigDecimal 
*and* to adhere to a widespread standard whose model is familiar to many 
programmers.

Perhaps some extended precision decimal format could be handy. On the 
other hand, I don't see why binary floating point numbers would be a 
useful option in this area.


Greetings
Raffaello



> This would be interesting to have.
> 
> It would be better if the full set of numbers b16-256 and d32-128 are
> implemented so there is full coverage of all IEEE 754 numbers.
> 
> 
> On Tue, 30 Mar 2021 at 01:45, Raffaello Giulietti <
> raffaello.giulietti at gmail.com> wrote:
> 
>> Hello,
>>
>> I'm experimenting with an implementation of Decimal64 and Decimal128,
>> two standard IEEE 754-2019 formats supporting, well, decimal floating
>> point numbers of up to 16 resp 34 decimal digits.
>>
>> While BigDecimal can simulate most finite number computations on these
>> formats by passing MathContext.DECIMAL64 and MathContext.DECIMAL128,
>> resp., to the arithmetic operations, this approach has some shortcomings
>> wrt to the standard:
>> * Like the binary formats (float and double in Java), the standard
>> mandates signed zeroes, signed infinities and NaNs for the decimal
>> formats as well, while BigDecimal has neither.
>> * BigDecimal is not a final class, so is not (and can never be)
>> value-based.
>> * BigDecimal needs support from BigInteger (another non final, non
>> value-based class).
>>
>> On the other hand, classes Decimal64 and Decimal128:
>> * Are value-based and can be declared to be primitive in a future
>> version of OpenJDK, once Valhalla is completed.
>> * Require 12 and 20 bytes, resp, of storage in the Valhalla model of
>> primitive objects and have no references to other identity or primitive
>> objects.
>> * Support the signed zeroes, the infinities and the NaNs.
>> * Currently support the 4 fundamental operations (+ - * /) according to
>> the standard and will support remainder, square root, comparisons, etc.
>> and the conversions listed in the standard.
>> * Could be extended to support the (rather cumbersome) exceptions
>> handling of the standard.
>> * There's no plan to support transcendental functions, as the aim is to
>> have numerical classes for business applications, not scientific or
>> engineering purposes.
>> * Are faster than the (incomplete) simulation with BigDecimal, 1x-5x in
>> the current incarnations.
>>
>>
>> I would be glad to contribute the code to the OpenJDK provided there is
>> a genuine interest from the community and a reviewer willing to sponsor
>> my effort. (I guess the best candidate for this role would be Joe Darcy
>> from what I can read in this mailing list.)
>>
>>
>> Greetings
>> Raffaello
>>