By: Michael S (already5chosen.delete@this.yahoo.com), December 19, 2020 10:48 am
Room: Moderated Discussions
rwessel (rwessel.delete@this.yahoo.com) on December 19, 2020 7:54 am wrote:
> dmcq (dmcq.delete@this.fano.co.uk) on December 19, 2020 3:41 am wrote:
> > rwessel (rwessel.delete@this.yahoo.com) on December 18, 2020 6:57 pm wrote:
> > > anon (an.delete@this.n.com) on December 18, 2020 8:29 am wrote:
> > > > I read that C2X (the next C language revision) will add support for decimal floating point.
> > > > I know that POWER and SPARC CPUs have hardware support for decimal FP,
> > > > but are there any plans to include it on future x86 or ARM CPUs?
> > > >
> > > > Also, which languages have native support (without libraries) for decimal FP right now?
> > > > I know of COBOL, PL/I, Ada, C# and F#. Any others?
> > >
> > >
> > > The ("floating") decimal type in C# and F# bear no resemblance
> > > to the IEEE decimal format, and little to anything
> > > we'd normally consider an FP format. The .NET format is
> > > a 96 bit binary integer with a decimal scale (10**0
> > > to 10**-28). Useful for currency, to be sure, but not meaningfully related to IEEE decimal FP.
> >
> > Oracle's number format is base 100 and adjusted so comparisons
> > work easily as strings. It does have an exponent,
> > but yep, oveall no resemblance. And databases are an especially important place for decimal numbers.
>
>
> As I've frequently* pointed out, there's not actually any need for decimal numbers, but decimal scaling *is*
> important. For something like a database column, that scaling factor is probably best stored in the attributes
> for the column. (at least for most purposes). For computational purposes it makes sense to store the scale
> explicitly, but for a storage format you'd generally want to normalize** the number first.
>
>
> *Not to worry, it's a bit of a hobbyhorse for me.
>
> **Not quite the same definition as for FP, but scaling and rounding so that the (computational)
> scale factor (exponent) is the same as that of the storage format.
About a year ago a spent significant part of my evening/night hours looking at speed of decimal scaling of products of quad-precision integers on modern x86-64 hardware. Conclusion - it can be quite fast. No special hardware/instructions required.
If existing [quad-precision, i.e IEEE 754 decimal128 BID] decimal FP libraries are slow that's only because they are not coded competently.
> dmcq (dmcq.delete@this.fano.co.uk) on December 19, 2020 3:41 am wrote:
> > rwessel (rwessel.delete@this.yahoo.com) on December 18, 2020 6:57 pm wrote:
> > > anon (an.delete@this.n.com) on December 18, 2020 8:29 am wrote:
> > > > I read that C2X (the next C language revision) will add support for decimal floating point.
> > > > I know that POWER and SPARC CPUs have hardware support for decimal FP,
> > > > but are there any plans to include it on future x86 or ARM CPUs?
> > > >
> > > > Also, which languages have native support (without libraries) for decimal FP right now?
> > > > I know of COBOL, PL/I, Ada, C# and F#. Any others?
> > >
> > >
> > > The ("floating") decimal type in C# and F# bear no resemblance
> > > to the IEEE decimal format, and little to anything
> > > we'd normally consider an FP format. The .NET format is
> > > a 96 bit binary integer with a decimal scale (10**0
> > > to 10**-28). Useful for currency, to be sure, but not meaningfully related to IEEE decimal FP.
> >
> > Oracle's number format is base 100 and adjusted so comparisons
> > work easily as strings. It does have an exponent,
> > but yep, oveall no resemblance. And databases are an especially important place for decimal numbers.
>
>
> As I've frequently* pointed out, there's not actually any need for decimal numbers, but decimal scaling *is*
> important. For something like a database column, that scaling factor is probably best stored in the attributes
> for the column. (at least for most purposes). For computational purposes it makes sense to store the scale
> explicitly, but for a storage format you'd generally want to normalize** the number first.
>
>
> *Not to worry, it's a bit of a hobbyhorse for me.
>
> **Not quite the same definition as for FP, but scaling and rounding so that the (computational)
> scale factor (exponent) is the same as that of the storage format.
About a year ago a spent significant part of my evening/night hours looking at speed of decimal scaling of products of quad-precision integers on modern x86-64 hardware. Conclusion - it can be quite fast. No special hardware/instructions required.
If existing [quad-precision, i.e IEEE 754 decimal128 BID] decimal FP libraries are slow that's only because they are not coded competently.