On 12/30/19 6:55 PM, David Mertz wrote:
The order he generates is very close to the IEEE total order, the difference are:
> 1) It doesn't seperate -0 for +0, which shouldn't matter for most applications. > 2) It doesn't provide an order between NaNs, but unless you are taking special measures to distinguish the NaNs anyway, that doesn't really matter.
And it also doesn’t distinguish equal but distinct-bit-pattern subnormal values.
This is more in the category of "things that definitely do not matter", but I had forgotten about subnomal floating-point values. How does IEEE totalOrder mandate ordering those vs. equivalent normal numbers?
So yes, my implementation of totalOrder probably has another incompleteness for the IEEE spec. It was THREE LINES of code, and I never claimed the goal was useful even if done correctly.
IEEE BINARY floating point doesn't have subnormal values the equivalent of normal numbers. The binary format has an assumed leading one to the mantissa for exponents greater than 0 (and less than all ones which are the Infinities and NaNs). This assumed one makes multiple representations for most values impossible, it one happens for 0, having +0 and -0. The first level of the ordering is the basic value of the number, which provides a total order for all finite numbers but 0 in the binary format. Other floating point bases, like decimal floating point or hex based, don't have a consistent leading digit, so it isn't omitted, and you could have subnormal values if the leading digit is 0. The clause on handling different representations really just apply to those non-binary formats. -- Richard Damon