Sorting floating-point values, and NaN

[Vladimir Panteleev]

On Tuesday, 12 November 2013 at 18:31:40 UTC, Walter Bright wrote:
> NaNs are valid values for floating point numbers. Trying to 
> pretend they don't exist is a doomed strategy for programmers. 
> I regard this as analogous to the regular proposals to hide the 
> fact that char[] are sequences of unicode code points, attempts 
> to pretend that integers don't overflow, etc.
>
> Floating point math has some strange characteristics (NaNs are 
> only one such), and anyone writing a non-toy fp app needs to 
> learn that stuff. There's no other way.

On Tuesday, 12 November 2013 at 18:25:10 UTC, Bigsandwich wrote:
> Please, please, please just no.  As someone who works with 
> floating point daily, you cannot idiot proof it like this.  
> They will never behave like "just numbers" and you can't make 
> them.
>
> Even leaving out NAN, you have issues with precision, 
> accumulated error, denormals, equality comparison, and on and 
> on.

That doesn't change the reality that not everyone is aware of 
these issues, and that even people who are aware of them may 
overlook something somewhere. We can't pretend that there is no 
problem just because it's something you "have to know" and "have 
to be careful about" - if we can improve the situation without 
making a compromise elsewhere, then it must be done.

I don't see this stance as any different than shouting "RTFM!!!" 
at anyone who makes a mistake which, in theory, could be avoided 
by studying, memorization and careful application of the 
appropriate documentation located ... somewhere. This approach 
does not work - even if that user has learned his lesson the hard 
way, more new users will make the same mistake. Instead, you must 
actually make the problem less likely to manifest - improve your 
documentation, or improve the design of your system such that 
such errors will be less likely to occur.

This particular situation affects only one specific property of 
floating-point numbers, so other properties are not relevant to 
this discussion. Personally, I've been taught about 
floating-point precision issues back in school, but I've only 
learned about NaNs while learning D. Call me an unlearned idiot 
if that makes you feel better, but it is rather likely that there 
will be more users making the same mistake in the future if the 
situation is not addressed.

Furthermore, the problem is aggravated by that it is hidden by 
generic code. This thread isn't a complaint that "the line `if 
(a<b)` in my program behaves in a funny way" - there are no 
explicit floating-point comparisons in the example in the 
original post. We are calling sort, a function in the standard 
library, with its default predicate, as specified in the standard 
library, using a built-in type, which is part of the language, 
and it fails its own assertion on certain input. This is a 
problem!

I have suggested possible improvements earlier in this thread, so 
I'd like to ask you to comment on those rather than hand-waving 
the problem away.