Proposal for Decimal64 and Decimal128 value-based classes

Suminda Sirinath Salpitikorala Dharmasena sirinath1978m at gmail.com
Tue Mar 30 01:13:54 UTC 2021


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
>


More information about the core-libs-dev mailing list