DEC64 (2014)
dec64.com
dec64.com
And that contains links to prior discussions
https://news.ycombinator.com/item?id=16514962
"If you want a default decimal floating-point type, the only defensible choice is the decimal128 type standardized by IEEE 754. It has a fully-defined arithmetic, specified by experts who have spent their careers thinking about the issues involved, and is wide enough to exactly represent the US national debt in every currency used on earth.
There are situations where other decimal floating-point types are appropriate, but if you do not understand the tradeoffs you are making, you should be using decimal128."
and
"I would be remiss not to note that Intel has made available a well-tested complete implementation of IEEE 754 decimal64 and decimal128 under 3-clause BSD: http://www.netlib.org/misc/intel/ "
No need to use the worse solution, which is dec64, unless you have some very specific goals.
This is just plain wrong. The IEEE decimal float types are now in SQL as DECFLOAT, coming to C and C++, I could go on...
https://raw.githubusercontent.com/libdfp/libdfp/master/READM...
"libdfp
The "Decimal Floating Point C Library" User's Guide for the GNU/Linux OS and GLIBC 2.10+
Contributed by IBM Corporation Copyright (C) 2010 - 2014 Free Software Foundation"
Seems he was right: even IBM didn't do a hardware implementation after Power 6 IIRC.
The hardware does seem to be of questionable value; I heard rumours that the POWER hardware didn't actually beat the Intel software implementation running on an x86. That doesn't mean that the datatype is worthless.
And it sure as hell doesn't mean that this DEC64 type, which has arbitrarily incompatible parameters but adds nothing, and is late to the game, is better!
> There are 255 possible representations of zero. They are all considered to be equal.
3 x 10^0
or
30 x 10^-1
If you're scared of normalizing before comparisons, or somesuch, nothing stops you normalizing around operations instead, like standard binary floats. Only you'd probably be shooting yourself in the foot, since you'd probably end up normalizing more and making the ‘integers are fast’ claim fail.
(In fairness, for small integers, the operators over normalized values are closed — they always return normalized values)
> (In fairness, for small integers, the operators over normalized values are closed — they always return normalized values)
Normally normalization refers to using the smallest possible exponent; in this light small integers are unnormalized.
Correct is "These two items are not numbers, so the numeric concept of equality can't be conclusively applied." This argument gives you NaN != NaN.
Useful is "We consider everything that's escaped the plane of numbers to be equivalent because they all require the same special handling." This gives you Nan = NaN.
That looks conclusive to me, though.
> This gives you Nan = NaN.
Problem is, there are multiple representations identified as "NaN". The question whether one NaN should be considered equal to another NaN is different from whether a NaN should equal to itself.
Whether a NaN is equal to a different NaN depends on the kind of equality; some equalities don't care about certain differences.
The C == equality allows the integer 1 to equal 1.0, in spite of a different representation; it is not simply a bitwise equality. (This happens by way of conversion of 1 to 1.0).
However, a thing should equal to itself under every applicable equality. That is non-negotiable.
There is a sense in which eq(x, x) can be false, if we consider argument passing to work by copy, and argument position to be part of identity. Then x is not x, because one is the left x and one is the right x they are in different stack locations or machine registers or whatever. Common Lisp allows for this kind of chicanery in its definition of "implementation identity" (embodied in its eq function). Numbers are not required to be eq, even to themselves. (eq 0 0) could yield false, the idea being that each copy of 0 could be a distinct object. Though that sort of stinks, it's not what is at pay here. These NaNs have type double, and ordinary values of that type are equal to themselves when copied to different argument positions of the equality operation.
[1] Note that this comment also applies to IEEE 754 decimal fp.
(1) https://docs.microsoft.com/en-au/dotnet/csharp/language-refe...
https://en.wikipedia.org/wiki/Logarithmic_number_system
main advantages:
- no multiple representations of the same number
- multiplication/division with complexity of addition and subtraction
- Drop-in replacement for signed integer types for loop iteration, array indexes, etc (Exact integer operations for 56 (55?) bit addition and subtraction with 1 cycle overhead; similar efficiency for multiplication)
-Drop in replacement for financial fixed point types (which need to be exact in base-10)
There's billions of lines of code in circulation dealing with fixed-decimal currency formats.
The choices have always been:
* Scale things up and down (do your math in cents and convert back to dollars at the last minute), which is an easy opportunity for off-by-2-orders-of-magnitude bugs * Use floating points and pray nobody notices the all but guaranteed errors * Use something like BCD and have to explain it to everyone * Deal with some custom format or language-specific type, kissing portability goodbye, and depending on implementation, possibly poor performance
A well-established decimal-friendly type, whether this, decimal128, or something else, provides a go-to solution to a very common problem.