Proposal for Decimal64 and Decimal128 value-based classes

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Proposal for Decimal64 and Decimal128 value-based classes

Raffaello Giulietti
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
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for Decimal64 and Decimal128 value-based classes

Suminda Sirinath Salpitikorala Dharmasena
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 <
[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for Decimal64 and Decimal128 value-based classes

Joe Darcy
In reply to this post by Raffaello Giulietti
Hi Raffaello,

On 3/29/2021 1:14 PM, Raffaello Giulietti 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.

Fun project!

>
> 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.

Quite right; those differences were recently (if belatedly) documented
in JDK 17 (8261366: Add discussion of IEEE 754 to BigDecimal).

> * BigDecimal is not a final class, so is not (and can never be)
> value-based.

Yep; as discussed in "Effective Java" the non-final-ness of the class
was recognized as a mistake after it was in the platform, but it is not
something we are likely to change now. As an aside, a happy accident of
the ability of BigDecimal to be subclassed was allowing easier
adaptation to changes in toString output that had an unexpectedly large
behavioral compatibility impact in JDK 5.0.


> * 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.

Assuming you have DecimalN <-> BigDecimal conversions, the BigDecimal
type should be usable for testing at least. For in-range values not near
the exponent range, the scale (exponent) and significand for finite and
nonzero values should be the same for the basic arithmetic operations
and square root in DecimalN and BigDecimal.

(Around the limits of the exponent range, there are subnormal and
"supernormal" results where the rounding of the significand interacts
with the exponent computation. This would make it a bit tricky to
offload BigDecimal computations in range of, say, a Decimal128 to a
hardware implementation where one was available.)

Fixed-size decimal computations have an interesting design space to
explore in terms of trading off memory compactness and computational
cost. For example, the IEEE 754 spec details two different encodings of
three decimal digits in 10 bits. However, it is not strictly necessary
for each operation to produce results whose internal storage maps to an
"interchange format," in the terminology of 754. It would be possible to
keep the significand encoded as normal integers and only produce an
interchange representation on something akin to a serialization event.

I understand hardware implementations of FPUs will use these sort of
techniques and also have architectural-invisible bits indicating what
kind of value a floating-point number is. For example, the beginning of
many math library functions starts with "Handle NaN cases," ... "Handle
infinity case" ... "Handle zero case" ... Sometimes the handling falls
out naturally and doesn't require explicit testing, but in the cases
that does not occur, it can be cheaper to have the "isFoo" bit already
computed.


> * 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.)
>
At least for the time being, I don't think the OpenJDK (at least the
main project) would be the best home for such code. As you're noted,
post Valhalla having such a type in the JDK becomes more interesting
from a performance perspective.

Thanks,

-Joe

Reply | Threaded
Open this post in threaded view
|

Re: Proposal for Decimal64 and Decimal128 value-based classes

Joe Darcy
In reply to this post by Suminda Sirinath Salpitikorala Dharmasena
On 3/29/2021 6:13 PM, Suminda Sirinath Salpitikorala Dharmasena wrote:
> 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.

FYI, if one is need of such code in C today, you can look at the
SoftFloat library (http://www.jhauser.us/arithmetic/SoftFloat.html):

> Berkeley SoftFloat is a free, high-quality software implementation of
> binary floating-point that conforms to the IEEE Standard for
> Floating-Point Arithmetic. SoftFloat is completely faithful to the
> IEEE Standard, while at the same time being relatively fast. All
> functions dictated by the original 1985 version of the standard are
> supported except for conversions to and from decimal. The latest
> release of SoftFloat implements five floating-point formats:
> half-precision, single-precision, double-precision,
> double-extended-precision, and quadruple-precision. All required
> rounding modes, exception flags, and special values are supported.
> Fused multiply-add is also implemented for all formats except
> double-extended-precision.

HTH,

-Joe

Reply | Threaded
Open this post in threaded view
|

Re: Proposal for Decimal64 and Decimal128 value-based classes

Brian Goetz-2
In reply to this post by Raffaello Giulietti
Overall, I'd be happy to see Decimal types that are aimed at "reasonable
precision" in addition to the infinite precision that BD offers.  (After
Valhalla, of course.)



On 3/29/2021 4:14 PM, Raffaello Giulietti 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

Reply | Threaded
Open this post in threaded view
|

Re: Proposal for Decimal64 and Decimal128 value-based classes

Paul Sandoz


> On Mar 30, 2021, at 1:03 PM, Brian Goetz <[hidden email]> wrote:
>
> Overall, I'd be happy to see Decimal types that are aimed at "reasonable precision" in addition to the infinite precision that BD offers.  (After Valhalla, of course.)
>

Yes, me too.

Raffaello, as an experiment you could develop such classes as primitive classes compiled against recent builds of Valhalla.

I would caution against unduly biasing towards "business applications”, as I think with primitive classes and other possible features Java can become a better platform for scientific or engineering purposes.

As an example we are making progress with the Vector API and in the panama-vector repo we have integrated with code of Intel’s Short Vector Math Library, which may open the possibility for it to be used by the auto-vectorizer too.

Paul.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for Decimal64 and Decimal128 value-based classes

Maurizio Cimadamore
Add me to the list of interested folks.

Such types are useful when interacting with System ABIs, and the Foreign
Linker API needs "well-known" carrier which model these types in Java.
There are also other interesting types to be explored in that domain,
such as Long128, LongDouble (extended precision float) and HalfFloats.

Maurizio

On 30/03/2021 21:54, Paul Sandoz wrote:

>
>> On Mar 30, 2021, at 1:03 PM, Brian Goetz <[hidden email]> wrote:
>>
>> Overall, I'd be happy to see Decimal types that are aimed at "reasonable precision" in addition to the infinite precision that BD offers.  (After Valhalla, of course.)
>>
> Yes, me too.
>
> Raffaello, as an experiment you could develop such classes as primitive classes compiled against recent builds of Valhalla.
>
> I would caution against unduly biasing towards "business applications”, as I think with primitive classes and other possible features Java can become a better platform for scientific or engineering purposes.
>
> As an example we are making progress with the Vector API and in the panama-vector repo we have integrated with code of Intel’s Short Vector Math Library, which may open the possibility for it to be used by the auto-vectorizer too.
>
> Paul.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for Decimal64 and Decimal128 value-based classes

Raffaello Giulietti
In reply to this post by Joe Darcy
Hi Joe,

On 2021-03-30 21:56, Joe Darcy wrote:

> Hi Raffaello,
>
> On 3/29/2021 1:14 PM, Raffaello Giulietti wrote:
>> Hello,
>>
>
> Assuming you have DecimalN <-> BigDecimal conversions, the BigDecimal
> type should be usable for testing at least. For in-range values not near
> the exponent range, the scale (exponent) and significand for finite and
> nonzero values should be the same for the basic arithmetic operations
> and square root in DecimalN and BigDecimal.
>
> (Around the limits of the exponent range, there are subnormal and
> "supernormal" results where the rounding of the significand interacts
> with the exponent computation. This would make it a bit tricky to
> offload BigDecimal computations in range of, say, a Decimal128 to a
> hardware implementation where one was available.)
>

Yes, some of my current tests exploit BigDecimal for crosschecks in the
normal range.


> Fixed-size decimal computations have an interesting design space to
> explore in terms of trading off memory compactness and computational
> cost. For example, the IEEE 754 spec details two different encodings of
> three decimal digits in 10 bits. However, it is not strictly necessary
> for each operation to produce results whose internal storage maps to an
> "interchange format," in the terminology of 754. It would be possible to
> keep the significand encoded as normal integers and only produce an
> interchange representation on something akin to a serialization event.
>

The internal representation is none of the interchange formats.
Similarly to the interchange format's 1'000-based declets, it holds
1'000'000'000-based (30 bits) "declets"/int, in addition to the unbiased
exponent, the sign, the precision and the kind, as you mention below.


> I understand hardware implementations of FPUs will use these sort of
> techniques and also have architectural-invisible bits indicating what
> kind of value a floating-point number is. For example, the beginning of
> many math library functions starts with "Handle NaN cases," ... "Handle
> infinity case" ... "Handle zero case" ... Sometimes the handling falls
> out naturally and doesn't require explicit testing, but in the cases
> that does not occur, it can be cheaper to have the "isFoo" bit already
> computed.
>
>
>> 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.)
>>
> At least for the time being, I don't think the OpenJDK (at least the
> main project) would be the best home for such code. As you're noted,
> post Valhalla having such a type in the JDK becomes more interesting
> from a performance perspective.
>

They are already more compact and faster than BigDecimal even on the
current, pre-Valhalla release, so they would make sense even today, were
they ready for review.

(I'm spending my free time on this, so I just wanted to make sure I'm
not wasting energy for something that will sit on my computer only.)


Greetings
Raffaello
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for Decimal64 and Decimal128 value-based classes

Raffaello Giulietti
In reply to this post by Brian Goetz-2
There's no strict need for Valhalla, as they are more compact and faster
than BigDecimal even today.


On 2021-03-30 22:03, Brian Goetz wrote:

> Overall, I'd be happy to see Decimal types that are aimed at "reasonable
> precision" in addition to the infinite precision that BD offers.  (After
> Valhalla, of course.)
>
>
>
> On 3/29/2021 4:14 PM, Raffaello Giulietti 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.
>>
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for Decimal64 and Decimal128 value-based classes

Raffaello Giulietti
In reply to this post by Paul Sandoz
Hi Paul,


On 2021-03-30 22:54, Paul Sandoz wrote:

>
>
>> On Mar 30, 2021, at 1:03 PM, Brian Goetz <[hidden email]> wrote:
>>
>> Overall, I'd be happy to see Decimal types that are aimed at "reasonable precision" in addition to the infinite precision that BD offers.  (After Valhalla, of course.)
>>
>
> Yes, me too.
>
> Raffaello, as an experiment you could develop such classes as primitive classes compiled against recent builds of Valhalla.
>

I guess the most recent builds of Valhalla are those resulting from
building from the source code in the git repo. Or are you recommending
the official ea releases instead?

I ask because I plan to use the latest release from the git repo and
keeping it current, not the ea release.


> I would caution against unduly biasing towards "business applications”, as I think with primitive classes and other possible features Java can become a better platform for scientific or engineering purposes.
>
> As an example we are making progress with the Vector API and in the panama-vector repo we have integrated with code of Intel’s Short Vector Math Library, which may open the possibility for it to be used by the auto-vectorizer too.
>
> Paul.
>

As far as I can tell, scientific computation will make use of binary
floating point numbers for a long time. Decimal floating point numbers
are still limited to biz and fin applications.

Does Intel's lib operates on decimal formats as well?


Greetings
Raffaello
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for Decimal64 and Decimal128 value-based classes

Raffaello Giulietti
In reply to this post by Maurizio Cimadamore
Ciao Maurizio,

thanks for your interest.


On 2021-03-30 23:01, Maurizio Cimadamore wrote:
> Add me to the list of interested folks.
>

Will do.


> Such types are useful when interacting with System ABIs, and the Foreign
> Linker API needs "well-known" carrier which model these types in Java.
> There are also other interesting types to be explored in that domain,
> such as Long128, LongDouble (extended precision float) and HalfFloats.
>  > Maurizio
>
> On 30/03/2021 21:54, Paul Sandoz wrote:
>>
>>> On Mar 30, 2021, at 1:03 PM, Brian Goetz <[hidden email]> wrote:
>>>
>>> Overall, I'd be happy to see Decimal types that are aimed at
>>> "reasonable precision" in addition to the infinite precision that BD
>>> offers.  (After Valhalla, of course.)
>>>
>> Yes, me too.
>>
>> Raffaello, as an experiment you could develop such classes as
>> primitive classes compiled against recent builds of Valhalla.
>>
>> I would caution against unduly biasing towards "business
>> applications”, as I think with primitive classes and other possible
>> features Java can become a better platform for scientific or
>> engineering purposes.
>>
>> As an example we are making progress with the Vector API and in the
>> panama-vector repo we have integrated with code of Intel’s Short
>> Vector Math Library, which may open the possibility for it to be used
>> by the auto-vectorizer too.
>>
>> Paul.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for Decimal64 and Decimal128 value-based classes

Paul Sandoz
In reply to this post by Raffaello Giulietti


> On Mar 30, 2021, at 4:05 PM, Raffaello Giulietti <[hidden email]> wrote:
>
> Hi Paul,
>
>
> On 2021-03-30 22:54, Paul Sandoz wrote:
>>> On Mar 30, 2021, at 1:03 PM, Brian Goetz <[hidden email]> wrote:
>>>
>>> Overall, I'd be happy to see Decimal types that are aimed at "reasonable precision" in addition to the infinite precision that BD offers.  (After Valhalla, of course.)
>>>
>> Yes, me too.
>> Raffaello, as an experiment you could develop such classes as primitive classes compiled against recent builds of Valhalla.
>
> I guess the most recent builds of Valhalla are those resulting from building from the source code in the git repo. Or are you recommending the official ea releases instead?
>

I would recommend building from the git repo if you can, since that will allow for the most relevant feedback.


> I ask because I plan to use the latest release from the git repo and keeping it current, not the ea release.
>
>
>> I would caution against unduly biasing towards "business applications”, as I think with primitive classes and other possible features Java can become a better platform for scientific or engineering purposes.
>> As an example we are making progress with the Vector API and in the panama-vector repo we have integrated with code of Intel’s Short Vector Math Library, which may open the possibility for it to be used by the auto-vectorizer too.
>> Paul.
>
> As far as I can tell, scientific computation will make use of binary floating point numbers for a long time. Decimal floating point numbers are still limited to biz and fin applications.
>

Ok.


> Does Intel's lib operates on decimal formats as well?
>

No.

Paul.

Reply | Threaded
Open this post in threaded view
|

Re: Proposal for Decimal64 and Decimal128 value-based classes

Brian Goetz-2
In reply to this post by Raffaello Giulietti
They'll find a natural home in JDBC, since SQL has a native decimal type.

On 3/30/2021 7:05 PM, Raffaello Giulietti wrote:
>
> As far as I can tell, scientific computation will make use of binary
> floating point numbers for a long time. Decimal floating point numbers
> are still limited to biz and fin applications.

Reply | Threaded
Open this post in threaded view
|

Re: Proposal for Decimal64 and Decimal128 value-based classes

Stephen Colebourne-2
In reply to this post by Maurizio Cimadamore
On Tue, 30 Mar 2021 at 22:02, Maurizio Cimadamore
<[hidden email]> wrote:
> There are also other interesting types to be explored in that domain,
> such as Long128, LongDouble (extended precision float) and HalfFloats.

Perhaps it would be beneficial to have a GitHub repo where designs for
these could be fleshed out. Kind of like a JSR would do. (For example,
Valhalla and OopenJDK will need to agree on naming conventions for the
various methods - for example I prefer plus() but others prefer add().
Stephen
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for Decimal64 and Decimal128 value-based classes

Douglas Surber
In reply to this post by Raffaello Giulietti
+1

JDBC would support this immediately. All it would take is the addition of a couple of lines in some appendices to require that conforming implementations of getObject(int, Class), setObject(int, Object, SQLType), etc support Decimal64 and Decimal128. No change to the API required. Driver vendors could add this support the instant the types are available, no need to wait for a change in the JDBC spec.

This would be a huge win for many Java apps. A large fraction of Java apps deal with money in some form. Binary floats are inappropriate for money and BigDecimal is too big and too slow.

Rather than waiting on Valhala I would prefer that this project be fast tracked and added to OpenJDK ASAP.

Thanks for doing this.

Douglas

On Mar 30, 2021, at 10:10 PM, [hidden email]<mailto:[hidden email]> wrote:

Date: Tue, 30 Mar 2021 22:12:32 -0400
From: Brian Goetz <[hidden email]<mailto:[hidden email]>>
To: Raffaello Giulietti <[hidden email]<mailto:[hidden email]>>, Paul Sandoz
<[hidden email]<mailto:[hidden email]>>
Cc: core-libs-dev <[hidden email]<mailto:[hidden email]>>
Subject: Re: Proposal for Decimal64 and Decimal128 value-based classes
Message-ID: <[hidden email]<mailto:[hidden email]>>
Content-Type: text/plain; charset=utf-8; format=flowed

They'll find a natural home in JDBC, since SQL has a native decimal type.

On 3/30/2021 7:05 PM, Raffaello Giulietti wrote:

As far as I can tell, scientific computation will make use of binary
floating point numbers for a long time. Decimal floating point numbers
are still limited to biz and fin applications.


Reply | Threaded
Open this post in threaded view
|

Re: Proposal for Decimal64 and Decimal128 value-based classes

Lance Andersen-3
Agree this could be beneficial to JDBC users.  To officially support this in JDBC would require an MR but as Douglas indicates  the work required to the JDBC spec would be minimal

Best
Lance

On Mar 31, 2021, at 10:23 AM, Douglas Surber <[hidden email]<mailto:[hidden email]>> wrote:

+1

JDBC would support this immediately. All it would take is the addition of a couple of lines in some appendices to require that conforming implementations of getObject(int, Class), setObject(int, Object, SQLType), etc support Decimal64 and Decimal128. No change to the API required. Driver vendors could add this support the instant the types are available, no need to wait for a change in the JDBC spec.

This would be a huge win for many Java apps. A large fraction of Java apps deal with money in some form. Binary floats are inappropriate for money and BigDecimal is too big and too slow.

Rather than waiting on Valhala I would prefer that this project be fast tracked and added to OpenJDK ASAP.

Thanks for doing this.

Douglas

On Mar 30, 2021, at 10:10 PM, [hidden email]<mailto:[hidden email]><mailto:[hidden email]> wrote:

Date: Tue, 30 Mar 2021 22:12:32 -0400
From: Brian Goetz <[hidden email]<mailto:[hidden email]><mailto:[hidden email]>>
To: Raffaello Giulietti <[hidden email]<mailto:[hidden email]><mailto:[hidden email]>>, Paul Sandoz
<[hidden email]<mailto:[hidden email]><mailto:[hidden email]>>
Cc: core-libs-dev <[hidden email]<mailto:[hidden email]><mailto:[hidden email]>>
Subject: Re: Proposal for Decimal64 and Decimal128 value-based classes
Message-ID: <[hidden email]<mailto:[hidden email]><mailto:[hidden email]>>
Content-Type: text/plain; charset=utf-8; format=flowed

They'll find a natural home in JDBC, since SQL has a native decimal type.

On 3/30/2021 7:05 PM, Raffaello Giulietti wrote:

As far as I can tell, scientific computation will make use of binary
floating point numbers for a long time. Decimal floating point numbers
are still limited to biz and fin applications.



[cid:E1C4E2F0-ECD0-4C9D-ADB4-B16CA7BCB7FC@home]



Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
[hidden email]<mailto:[hidden email]>



Reply | Threaded
Open this post in threaded view
|

Re: Proposal for Decimal64 and Decimal128 value-based classes

Maurizio Cimadamore
In reply to this post by Douglas Surber

On 31/03/2021 15:23, Douglas Surber wrote:
> Rather than waiting on Valhala I would prefer that this project be fast tracked and added to OpenJDK ASAP.

There is a catch here.

While in principle, we can add these as value-based classes, and migrate
to Valhalla later, there is a biggie difference between doing it
before/after.

When it comes to "migrated" primitive classes, there is a choice in how
to interpret the "old" utterances of the class name. Let's say that
class Foo is migrated to be a primitive class; does that mean that all
uses of Foo in existing program will automatically get flattening? Or
will references to Foo be interpreted in a conservative fashion, so  as
to allow the same operations as before? One important difference in
semantics is assignment to `null` which is prohibited under flattened
semantics, but allowed under "indirect" (or by reference, if you will)
semantics.

In other words, under the current plan, if Decimal128 is added now and
migrated later, utterances of Decimal128 will behave like they used to
pre-Valhalla, and, to take advantage of flattening you would need to
opt-in with some keyword (e.g. Decimal128.val).

To me this is kind of a strong argument against going with these classes
now (as much as I understand how useful they'd be even w/o Valhalla) -
and preserving the "good" name (Decimal128) for the flattened case seems
worth, IMHO, waiting few more cycles.

Maurizio

Reply | Threaded
Open this post in threaded view
|

Re: Proposal for Decimal64 and Decimal128 value-based classes

Douglas Surber
I'm sure this would be a huge disruption, but I'll throw it out anyway. I'd be perfectly happy if assigning null to a Decimal64/128 container was not allowed, whether it is a reference or a value.

I haven't followed the progress of Valhalla closely. It would be reasonable to delay Decimal64/128 until Valhalla so long as that isn't more than a very few cycles. My concern is that Valhalla is a challenging project. I would not want Decimal64/128 to get hung up because Valhalla is delayed or even worse canceled.

Douglas

> On Mar 31, 2021, at 8:01 AM, Maurizio Cimadamore <[hidden email]> wrote:
>
>
> On 31/03/2021 15:23, Douglas Surber wrote:
>> Rather than waiting on Valhala I would prefer that this project be fast tracked and added to OpenJDK ASAP.
>
> There is a catch here.
>
> While in principle, we can add these as value-based classes, and migrate to Valhalla later, there is a biggie difference between doing it before/after.
>
> When it comes to "migrated" primitive classes, there is a choice in how to interpret the "old" utterances of the class name. Let's say that class Foo is migrated to be a primitive class; does that mean that all uses of Foo in existing program will automatically get flattening? Or will references to Foo be interpreted in a conservative fashion, so  as to allow the same operations as before? One important difference in semantics is assignment to `null` which is prohibited under flattened semantics, but allowed under "indirect" (or by reference, if you will) semantics.
>
> In other words, under the current plan, if Decimal128 is added now and migrated later, utterances of Decimal128 will behave like they used to pre-Valhalla, and, to take advantage of flattening you would need to opt-in with some keyword (e.g. Decimal128.val).
>
> To me this is kind of a strong argument against going with these classes now (as much as I understand how useful they'd be even w/o Valhalla) - and preserving the "good" name (Decimal128) for the flattened case seems worth, IMHO, waiting few more cycles.
>
> Maurizio
>

Reply | Threaded
Open this post in threaded view
|

Re: Proposal for Decimal64 and Decimal128 value-based classes

Raffaello Giulietti
In reply to this post by 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
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for Decimal64 and Decimal128 value-based classes

Raffaello Giulietti
In reply to this post by Raffaello Giulietti
Ciao Maurizio,

admittedly, yours is a fairly convincing argument to wait for the
completion of Valhalla, or at least JEP 401.

Personally, I wouldn't mind having to denote the primitive class as
Decimal128.val in some future (2022? 2023? who knows?) if I could use
Decimal128 tomorrow, but I understand your concerns in defending the
interests of the community at large (which includes myself).


Greetings
Raffaello


> On 31/03/2021 15:23, Douglas Surber wrote:
>> Rather than waiting on Valhala I would prefer that this project be fast tracked and added to OpenJDK ASAP.
>
> There is a catch here.
>
> While in principle, we can add these as value-based classes, and migrate
> to Valhalla later, there is a biggie difference between doing it
> before/after.
>
> When it comes to "migrated" primitive classes, there is a choice in how
> to interpret the "old" utterances of the class name. Let's say that
> class Foo is migrated to be a primitive class; does that mean that all
> uses of Foo in existing program will automatically get flattening? Or
> will references to Foo be interpreted in a conservative fashion, so  as
> to allow the same operations as before? One important difference in
> semantics is assignment to `null` which is prohibited under flattened
> semantics, but allowed under "indirect" (or by reference, if you will)
> semantics.
>
> In other words, under the current plan, if Decimal128 is added now and
> migrated later, utterances of Decimal128 will behave like they used to
> pre-Valhalla, and, to take advantage of flattening you would need to
> opt-in with some keyword (e.g. Decimal128.val).
>
> To me this is kind of a strong argument against going with these classes
> now (as much as I understand how useful they'd be even w/o Valhalla) -
> and preserving the "good" name (Decimal128) for the flattened case seems
> worth, IMHO, waiting few more cycles.
>
> Maurizio

12