opCmp / opEquals do not actually support partial orders

[Ivan Kazmenko]

On Tuesday, 17 July 2018 at 21:18:12 UTC, John Colvin wrote:
> Just do what std.typecons.Proxy does and return float.nan for 
> the incomparable case.

Isn't it slow though on current processors?  I just threw 
together a test program.

-----
import std.datetime.stopwatch, std.math, std.stdio;
immutable double limit = 10 ^^ 7;
void main () {
     int s;
     auto sw = StopWatch (AutoStart.yes);
     auto start = sw.peek ();
     for (double x = NaN (0), i = 0; i < limit; i++)
         s += (i < x);
     auto now = sw.peek ();
     writeln (now - start, ", sum is ", s);
}
-----

Essentially, it compares a double x (initialized as a quiet NaN 
with payload 0) to a numeric double i, ten million times.  
Leaving x uninitialized, or using floats, work about the same.  
And here is the result:

-----
1 sec, 593 ms, 116 μs, and 3 hnsecs, sum is 0
-----

So, for a comparison involving NaN, we can do only a few million 
of them a second.  Granted, my Core i7-2600K is more than 5 years 
old already, but the situation is unlikely to get any better.  
But that's still a couple orders of magnitude slower than normal 
vs. normal floating-point comparison: try assigning some regular 
number to x, then the test takes ~50ms.

As far as I know, rare floating-point operations (such as this, 
or using subnormal numbers) are, or rather should be, treated as 
exceptions.  The hardware manufacturers neglect such rare 
operations to fit a bit more efficiency in the more common ones 
(or they are just lazy).  As a result, the developers don't 
overuse them.

Ivan Kazmenko.