On 31/03/2021 23:54, Dan Smith wrote:
On Mar 31, 2021, at 3:27 PM, Maurizio Cimadamore
wrote:
What I'd be curious though, is if the @ValueBased annotation could be enhanced to say
_which_ primitive class default you want (and then javac could enforce extra checks if
you pick the "val" defa
> On Mar 31, 2021, at 3:27 PM, Maurizio Cimadamore
> wrote:
>
> What I'd be curious though, is if the @ValueBased annotation could be
> enhanced to say _which_ primitive class default you want (and then javac
> could enforce extra checks if you pick the "val" default). If something like
> thi
The IEEE decimal floating-point is usable for currency calculations, but
it is not intended to be limited to such calculations. A type targeted
at currency calculations would focus more on fixed-point rounding,
rounding to a given digit position (scale in BigDecimal terminology), as
opposed to
The issue is to simulate SQL DECIMAL arithmetic using IEEE Decimal
Consider the division 20 / 3. Using Decimal64:
20 / 3 -> 6.7
Using DECIMAL(38, 6), or many other reasonable combinations:
20 / 3 -> 6.67
We could expose a richer API in Decimal, similar
On 31/03/2021 21:43, Raffaello Giulietti wrote:
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 k
My understanding is that IEEE decimal floating point is intended for currency.
A large fraction of numeric values stored in databases are currency. It's not
obvious to me why an e-commerce web site would not want to use Decimal128 to
represent prices, extensions, taxes, discounts, totals, etc.
Hi Douglas,
yes, different vendors have different limits on the precision, the most
extreme probably being PostgreSQL.
But apart from that, the arithmetic is different.
A better option is to implement some optimized fixed precision classes
like SQLDecimal38 and SQLDecimal65 + a more general
Understood. The problem is that right now the only appropriate type for
non-integer SQL numbers is BigDecimal. It's too big and too slow and lots of
users avoid it.
Decimal128 supports 34 significant digits. The max precision of SQL numeric
types varies from vendor to vendor. In SQL Server it
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 u
Hi,
I think there's a misunderstanding about the nature of IEEE 754
Decimal (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 t
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
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 differe
to:paul.san...@oracle.com><mailto:paul.san...@oracle.com>>
Cc: core-libs-dev
mailto:core-libs-dev@openjdk.java.net><mailto:core-libs-dev@openjdk.java.net>>
Subject: Re: Proposal for Decimal64 and Decimal128 value-based classes
Message-ID:
<64334a24-0e4c-57b8-b666-447ca3508...@orac
021 22:12:32 -0400
From: Brian Goetz mailto:brian.go...@oracle.com>>
To: Raffaello Giulietti
mailto:raffaello.giulie...@gmail.com>>, Paul
Sandoz
mailto:paul.san...@oracle.com>>
Cc: core-libs-dev
mailto:core-libs-dev@openjdk.java.net>>
Subject: Re: Proposal for Decima
On Tue, 30 Mar 2021 at 22:02, Maurizio Cimadamore
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 o
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 f
> On Mar 30, 2021, at 4:05 PM, Raffaello Giulietti
> wrote:
>
> Hi Paul,
>
>
> On 2021-03-30 22:54, Paul Sandoz wrote:
>>> On Mar 30, 2021, at 1:03 PM, Brian Goetz wrote:
>>>
>>> Overall, I'd be happy to see Decimal types that are aimed at "reasonable
>>> precision" in addition to the inf
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
Hi Paul,
On 2021-03-30 22:54, Paul Sandoz wrote:
On Mar 30, 2021, at 1:03 PM, 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.)
Yes, me too.
Raffae
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
Valhal
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
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 pr
> On Mar 30, 2021, at 1:03 PM, 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.)
>
Yes, me too.
Raffaello, as an experiment you could develop suc
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 Decimal12
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 lo
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 BigDecima
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 comput
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.giulie...@gmail.com> wrote:
> Hello,
>
> I'm experimenting with a
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 MathC
29 matches
Mail list logo
