Watch out for NaNs

[jbe]

@tczajka

@jbe

At the same time, it would come with a lot of downsides.

You didn't provide any. You only said there are some cases where getting rid of NaN doesn't solve the problem, but that's not a "downside", that's neutral.

The only real argument I have seen in this thread and elsewhere is that NaNs are a debugging tool. That's not a good reason to complicate your types. You can have other debugging tools instead that don't interfere with the logic, and I have mentioned some, such as hardware counters of various events, such as square roots of negative numbers.

The downside I can think of: sqrt(-1) = 0 simply is wrong (and not just a bit wrong, such as when rounding or returning infinity instead of a very huge number).

Of course, rounding errors can sum up. But when you set sqrt(-1) = 0, then a single calculation gives a wrong result (that is not just off by rounding).

Note that IEEE 754 has deterministic rounding rules. And setting sqrt(-1) = 0 can't be called "rounding" anymore.

That said, I think one can argue that NaN's are a bad idea. I see that there are pros and cons for them. I like them, but I do understand if other people don't. Maybe we wouldn't have ended up with PartialOrd (see also Traits in std::cmp and mathematical terminology) if NaNs weren't existent. I think it's legitimate to defend the hypothesis that they cause more harm than being useful, even if I feel different (for now).

---

@tczajka

@jbe

And here the problem can't be solved by simply getting rid of NaN, because 1/-0.0000000000001 is still very different from what 1/0.0000000000001 would be. (Note that both are finite.)

First of all, you're confusing infinity with NaN. This is a case where you can get an infinity. I didn't propose getting rid of infinities.

As I said, in my case there is no infinity involved either: "Note that both are finite."

P.S.: But maybe you meant that infinity can be returned in some cases (when numbers are a bit off).