Unfortunately this website doesn't talk much about the shortcomings of DEC64. Just to start, numbers in DEC64 have multiple representations, meaning even a simple equality check can take tens of cycles. Don't get me wrong, it's a cool way to store numbers, and it does have purpose, but it is not suited for general use like IEEE754 is.
I checked out the reference implementation and although there are some heuristics to make comparing numbers faster, you're completely right that the worst case scenario is quite complicated: https://github.com/douglascrockford/DEC64/blob/master/dec64....
That code is certainly not written by someone with x86 optimization experience. Using high-byte registers (e.g. ah which he rewrites as r0_h) is an awful idea on any Pentium Pro or more recent processor.
IEEE754 also has multiple representations along with imprecise representations of integers, it’s limits (+Inf, -Inf, NaN) and simple decimals (0.1 + 0.2 != 0.3). For now, the biggest benefit is that we have hardware acceleration for IEEE754 everywhere, not that it is particularly good for any use case or that it is without weakness. But when we get FPGAs in commodity CPUs, the pros and cons value of IEEE754 change rapidly. Custom arithmetic formats could become more common.
nan != nan severely bothers me, when it's the same object on both sides with exactly the same bit pattern. It's the work of imbeciles who are either unfamiliar with the concept of identity, or else don't understand why it's important and should be respected.
It feels like an argument between useful and correct.
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.
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.
This is true, but hardly important. Multiple representations hurt because they waste space, not because they're transiently evil.
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.
