Re: Proposal for Decimal64 and Decimal128 value-based classes
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" default). If something like this was feasible (cc'ing Dan), maybe some of the friction here could be removed? You mean annotate a class with "pretend this class's name represents a value type" and then implement the associated null checks in javac, even though we don't actually have value types yet? I'd expect that to run into a number of problems related to the fact that the language model hasn't actually been updated to include primitive classes or value types yet. Plus the lack of features like reference types (Foo.ref) would be limiting for programmers who need them. Plus binary incompatibility—value types need special encoding in class files, and those class files aren't legal yet; when they are, you risk mismatches. In this case I think the straightforward approach of just completing and delivering the Valhalla features is better than trying to spin off a small taste of them early. You are right - there are more aspects to this than just null checks - binary compatibility seems especially problematic. Thanks for the explanation! Maurizio
Re: Proposal for Decimal64 and Decimal128 value-based classes
> 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 > this was feasible (cc'ing Dan), maybe some of the friction here could be > removed? You mean annotate a class with "pretend this class's name represents a value type" and then implement the associated null checks in javac, even though we don't actually have value types yet? I'd expect that to run into a number of problems related to the fact that the language model hasn't actually been updated to include primitive classes or value types yet. Plus the lack of features like reference types (Foo.ref) would be limiting for programmers who need them. Plus binary incompatibility—value types need special encoding in class files, and those class files aren't legal yet; when they are, you risk mismatches. In this case I think the straightforward approach of just completing and delivering the Valhalla features is better than trying to spin off a small taste of them early.
Re: [External] : Re: Proposal for Decimal64 and Decimal128 value-based classes
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 floating-point rounding which is primarily rounding to a fixed precision. In a currency setting, rounding to a given scale would mean rounding to whole dollars (pounds, euros, etc.), cents, mills, or other particular fractional quantity. -Joe On 3/31/2021 2:24 PM, Douglas Surber wrote: 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. On Mar 31, 2021, at 2:17 PM, Raffaello Giulietti wrote: 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 variable precision SQLDecimal. But, as I mentioned, this is something different than Decimal. Greetings Raffaello On 2021-03-31 22:53, Douglas Surber wrote: 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 is 38. In MySQL it is 65. So there are a huge range of values representable in SQL that are not representable in Decimal128. BUT, for the vast majority of applications that might be tempted to use Decimal128, those non-representable numbers don't occur. Currency amounts exceeding 34 decimal digits of precision are an almost non-existent minority. Very few apps will pay the price of using BigDecimal even though it would support huge numbers exactly. Instead they find workarounds that are more efficient. Decimal128 would be a substantial improvement for those apps. Douglas On Mar 31, 2021, at 1:13 PM, Raffaello Giulietti wrote: 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 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
Re: [External] : Re: Proposal for Decimal64 and Decimal128 value-based classes
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 to BigDecimal's. It is doable, but beyond IEEE and my current plan. In addition, I find that the point issued by Maurizio about the best name for the Valhalla primitive class is important enough for the community at large to warrant a rumination pause. Let me ponder about how to enrich the API to support SQL for a couple of days or so. In the meantime, the Valhalla guys may come up with a good solution to better assist migration of @ValueBased classes to truly primitive classes without disrupting existing code that depends on them, as described by Maurizio in his previous post. On 2021-03-31 23:24, Douglas Surber wrote: 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. On Mar 31, 2021, at 2:17 PM, Raffaello Giulietti wrote: 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 variable precision SQLDecimal. But, as I mentioned, this is something different than Decimal. Greetings Raffaello On 2021-03-31 22:53, Douglas Surber wrote: 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 is 38. In MySQL it is 65. So there are a huge range of values representable in SQL that are not representable in Decimal128. BUT, for the vast majority of applications that might be tempted to use Decimal128, those non-representable numbers don't occur. Currency amounts exceeding 34 decimal digits of precision are an almost non-existent minority. Very few apps will pay the price of using BigDecimal even though it would support huge numbers exactly. Instead they find workarounds that are more efficient. Decimal128 would be a substantial improvement for those apps. Douglas On Mar 31, 2021, at 1:13 PM, Raffaello Giulietti wrote: 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 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
Re: Proposal for Decimal64 and Decimal128 value-based classes
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 knows?) if I could use Decimal128 tomorrow, but I understand your concerns in defending the interests of the community at large (which includes myself). Well, I think the problem with a lot of these things is consistency. Decimal128.val is not horrible, although it is the wrong default (think of Decimal128[] which you would probably want flattened?). The worse aspect is if _some_ of these types are added before, and some after, so you have to remember to use Decimal128.val, but HalfFloat is ok (as it has been added after Valhalla). Considering that these things can happen, I'd be reluctant to go ahead and add these types now. 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 this was feasible (cc'ing Dan), maybe some of the friction here could be removed? Maurizio 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
Re: [External] : Re: Proposal for Decimal64 and Decimal128 value-based classes
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. > On Mar 31, 2021, at 2:17 PM, Raffaello Giulietti > wrote: > > 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 variable precision SQLDecimal. > But, as I mentioned, this is something different than Decimal. > > > Greetings > Raffaello > > > > On 2021-03-31 22:53, Douglas Surber wrote: >> 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 is 38. In MySQL it is >> 65. So there are a huge range of values representable in SQL that are not >> representable in Decimal128. BUT, for the vast majority of applications that >> might be tempted to use Decimal128, those non-representable numbers don't >> occur. Currency amounts exceeding 34 decimal digits of precision are an >> almost non-existent minority. >> Very few apps will pay the price of using BigDecimal even though it would >> support huge numbers exactly. Instead they find workarounds that are more >> efficient. Decimal128 would be a substantial improvement for those apps. >> Douglas >>> On Mar 31, 2021, at 1:13 PM, Raffaello Giulietti >>> wrote: >>> >>> 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 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
Re: [External] : Re: Proposal for Decimal64 and Decimal128 value-based classes
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 variable precision SQLDecimal. But, as I mentioned, this is something different than Decimal. Greetings Raffaello On 2021-03-31 22:53, Douglas Surber wrote: 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 is 38. In MySQL it is 65. So there are a huge range of values representable in SQL that are not representable in Decimal128. BUT, for the vast majority of applications that might be tempted to use Decimal128, those non-representable numbers don't occur. Currency amounts exceeding 34 decimal digits of precision are an almost non-existent minority. Very few apps will pay the price of using BigDecimal even though it would support huge numbers exactly. Instead they find workarounds that are more efficient. Decimal128 would be a substantial improvement for those apps. Douglas On Mar 31, 2021, at 1:13 PM, Raffaello Giulietti wrote: 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 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
Re: [External] : Re: Proposal for Decimal64 and Decimal128 value-based classes
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 is 38. In MySQL it is 65. So there are a huge range of values representable in SQL that are not representable in Decimal128. BUT, for the vast majority of applications that might be tempted to use Decimal128, those non-representable numbers don't occur. Currency amounts exceeding 34 decimal digits of precision are an almost non-existent minority. Very few apps will pay the price of using BigDecimal even though it would support huge numbers exactly. Instead they find workarounds that are more efficient. Decimal128 would be a substantial improvement for those apps. Douglas > On Mar 31, 2021, at 1:13 PM, Raffaello Giulietti > wrote: > > 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 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
Re: Proposal for Decimal64 and Decimal128 value-based classes
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
Re: Proposal for Decimal64 and Decimal128 value-based classes
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 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
Re: Proposal for Decimal64 and Decimal128 value-based classes
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 > 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 >
Re: Proposal for Decimal64 and Decimal128 value-based classes
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
Re: Proposal for Decimal64 and Decimal128 value-based classes
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 mailto:douglas.sur...@oracle.com>> 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, core-libs-dev-requ...@openjdk.java.net<mailto:core-libs-dev-requ...@openjdk.java.net><mailto:core-libs-dev-requ...@openjdk.java.net> wrote: Date: Tue, 30 Mar 2021 22:12:32 -0400 From: Brian Goetz mailto:brian.go...@oracle.com><mailto:brian.go...@oracle.com>> To: Raffaello Giulietti mailto:raffaello.giulie...@gmail.com><mailto:raffaello.giulie...@gmail.com>>, Paul Sandoz mailto: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...@oracle.com<mailto:64334a24-0e4c-57b8-b666-447ca3508...@oracle.com><mailto:64334a24-0e4c-57b8-b666-447ca3508...@oracle.com>> 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 lance.ander...@oracle.com<mailto:lance.ander...@oracle.com>
Re: Proposal for Decimal64 and Decimal128 value-based classes
+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, core-libs-dev-requ...@openjdk.java.net<mailto:core-libs-dev-requ...@openjdk.java.net> wrote: Date: Tue, 30 Mar 2021 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 Decimal64 and Decimal128 value-based classes Message-ID: <64334a24-0e4c-57b8-b666-447ca3508...@oracle.com<mailto:64334a24-0e4c-57b8-b666-447ca3508...@oracle.com>> 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.
Re: Proposal for Decimal64 and Decimal128 value-based classes
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 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
Re: Proposal for Decimal64 and Decimal128 value-based classes
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.
Re: Proposal for Decimal64 and Decimal128 value-based classes
> 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 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.
Re: Proposal for Decimal64 and Decimal128 value-based classes
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 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.
Re: Proposal for Decimal64 and Decimal128 value-based classes
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. 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
Re: Proposal for Decimal64 and Decimal128 value-based classes
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.
Re: Proposal for Decimal64 and Decimal128 value-based classes
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
Re: Proposal for Decimal64 and Decimal128 value-based classes
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 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.
Re: Proposal for Decimal64 and Decimal128 value-based classes
> 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 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.
Re: Proposal for Decimal64 and Decimal128 value-based classes
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
Re: Proposal for Decimal64 and Decimal128 value-based classes
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
Re: Proposal for Decimal64 and Decimal128 value-based classes
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
Proposal for Decimal64 and Decimal128 value-based classes
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
Re: Proposal for Decimal64 and Decimal128 value-based classes
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 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 >
Proposal for Decimal64 and Decimal128 value-based classes
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
