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.
