DEC64 Type (Decimal Floating Point)

[benaadams]

As proposed by Douglas Crockford https://github.com/douglascrockford/DEC64

Presentation on it: https://youtu.be/PSGEjv3Tqo0?t=27m5s

[terrajobst]

@joshfree, what are your thoughts on this?

[AlgorithmsAreCool]

For those not familiar with DEC64 here are some other readings:
DEC64 Web site

HN discussion on DEC64
Reddit discussion on DEC64

That aside, i'm not clear on the advantage? Numerical stability? Safety? Precision?

[joshfree]

@terrajobst I haven't heard of DEC64 before; the HN and Reddit thread are not very positive.

[benaadams]

Spec might need work, also is the Decimal64 IEEE 754, ISO/IEC/IEEE 60559:2011 version https://en.wikipedia.org/wiki/Decimal64_floating-point_format

[benaadams]

Not sure the IEEE version is much better; a lot of the HN and Reddit complaints were about the 255 representations of zero (and 16 representations of 1, 15 representations of 10 etc), however in the IEEE version

Because the significand is not normalized, most values with less than 16 significant digits have multiple possible representations; 1×102=0.1×103=0.01×104, etc. Zero has 768 possible representations (1536 if you include both signed zeros).

[benaadams]

@AlgorithmsAreCool a smaller faster version of Decimal that as a bonus supports CAS operations for atomic lock free calculations.

DEC64 has the fast path that if you precision is the same for all numbers in your problem domain (e.g. always 4 decimal digits for currency) then it is a quick op.

From the C++ proposal to adopt IEEE 754 Decimal post C++ 11 (didn't make it into C++ 11)

In many areas, especially in finance, exact values need to be processed and the inputs are commonly decimal. Unfortunately, decimal values cannot, in general, be represented accurately using binary floating points even when the decimal values only uses a few digits. Instead, the values become an approximation. As long as the values are carefully processed the original decimal value can be restored from a binary floating point (assuming reasonable restrictions on the number of decimal digits). However, computations and certain conversions introduce subtle errors (e.g. double to float and back to double, even if float is big enough to restore the original decimal value). As a result, the processing of exact decimal values using binary floating points is very error prone.

The use of decimal floating points avoids many of the problems caused by binary floating points. In particular, computations which need to accurately process decimal numbers can use decimal floating points. Decimal floating points provide a useful and sufficient compromise for these domains. Since they use a fixed size representation computations which are normally exact can introduce inaccuracies when the number of necessary digits becomes too big but for actual applications this is rarely a problem. Also, decimal floating points cannot represent the result of all operations exactly. For example, the result of a division with a prime other than 2 and 5 will, in general, be rounded. In the contexts where exact results are needed the corresponding operations aren’t needed.

[fanoI]

A thing I've not understood Dec64 is more faster that IEEE Decimal64? In any case why not implement the IEEE one that is a standard and maybe in future it will be hardware accelerated (on some IBM not x86 workstation is already so)?

[stephentoub]

@tannergooding, do we have any plans to do anything here, or can this be closed?

[tannergooding]

This issue can likely be closed. Any work on future numeric types should be first prototyped on corefxlab under dotnet/corefxlab#2635, which tracks prototyping some of the existing standardized types such as:

• IEEE binary16 (half-precision), binary128 (quad-precision), and binary{k} (arbitrary precision)
• IEEE decimal32, decimal64, decimal128, and decimal{k}
• Int128/UInt128

[tannergooding]

As for DEC64 in particular, I am skeptical that it is worth supporting. Unlike the IEEE decimal floating-point types, it is not "officially" standardized but like the IEEE types, it would need to be emulated in software. Looking at the format, it looks like it would also have its own problems as it (much like any floating-point format, including the IEEE ones or our own System.Decimal) makes various trade-offs in its internal representation.

[stephentoub]

thanks.