As someone who has implemented a lot of low level functions using all the tricks of Floating point math, I have very mixed thoughts on Floating Point. Nan and -0.0 both seem like aggressively bad ideas to me. I can totally see why it was believed at the time that they would be good, but they just add a ton of special cases if you want to do things right that slow everything down. IMO, it would have been much better if we got errors instead of NaN (like we do for integer division by zero).
That said, the ability to use double-double schemes to extend precision is wonderful and makes things much easier than they are in most of the Floating Point alternatives that have been proposed (eg Posits).
Anyone who does not like NaNs should remember that using NaNs is just an option, nobody forces you to use them.
It is enough to enable exception generation for undefined operations and it is guaranteed that no NaNs can appear in any results.
It turns out that most people think that it is too much work to write suitable exception handlers, so they prefer to mask all exceptions and deal with NaNs and negative zeros.
In practice this just means that you must be careful when you write conditional expressions where floating-point numbers are compared, because the order relation becomes partial, so there are 14 possible relational operations instead of the only 6 that are possible for a total order, and you also must write the compared values in a way where the sign of a zero does not matter (in most expressions the sign of a zero does not influence the result; you must make some efforts to distinguish a negative zero from a positive zero).
From my perspective of implementing algorithms it matters because if I want to follow the spec correctly, I have to deal with them. Even if you don't want to use them, you pay about 10% for pretty much any function that needs special NaN handling (which is most of them). Also, pre AVX-512, these checks make vectorized algorithms way harder to write efficiently.
I agree that if you are writing a library to be used by others, you cannot know how they will choose to configure their floating-point environment, so you are forced to handle all the possible cases in your code.
Comments
As someone who has implemented a lot of low level functions using all the tricks of Floating point math, I have very mixed thoughts on Floating Point. Nan and -0.0 both seem like aggressively bad ideas to me. I can totally see why it was believed at the time that they would be good, but they just add a ton of special cases if you want to do things right that slow everything down. IMO, it would have been much better if we got errors instead of NaN (like we do for integer division by zero).
That said, the ability to use double-double schemes to extend precision is wonderful and makes things much easier than they are in most of the Floating Point alternatives that have been proposed (eg Posits).
Anyone who does not like NaNs should remember that using NaNs is just an option, nobody forces you to use them.
It is enough to enable exception generation for undefined operations and it is guaranteed that no NaNs can appear in any results.
It turns out that most people think that it is too much work to write suitable exception handlers, so they prefer to mask all exceptions and deal with NaNs and negative zeros.
In practice this just means that you must be careful when you write conditional expressions where floating-point numbers are compared, because the order relation becomes partial, so there are 14 possible relational operations instead of the only 6 that are possible for a total order, and you also must write the compared values in a way where the sign of a zero does not matter (in most expressions the sign of a zero does not influence the result; you must make some efforts to distinguish a negative zero from a positive zero).
From my perspective of implementing algorithms it matters because if I want to follow the spec correctly, I have to deal with them. Even if you don't want to use them, you pay about 10% for pretty much any function that needs special NaN handling (which is most of them). Also, pre AVX-512, these checks make vectorized algorithms way harder to write efficiently.
I agree that if you are writing a library to be used by others, you cannot know how they will choose to configure their floating-point environment, so you are forced to handle all the possible cases in your code.
I'd heard of posits before but hadn't been motivated to learn about them until your comment; thanks. Reminds me of CIDR for IPv4
IMO, 8 and 16 bit posits are way better than the float equivalents, but for 32 and 64 bits, floating point math is easier to analyze.