Sorting floating-point values, and NaN

[Andrei Alexandrescu]

On 11/12/13 11:06 AM, Vladimir Panteleev wrote:
> 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 agree. I'll just add that people who plan to get work done with 
floating point will inevitably stumble upon NaN. There's no two ways 
about it.

> 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.

I agree here, too. Again, I'll add that "improving the documentation" 
helps little unless RTFM is at work :o).

> 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.

You're young. I guarantee you were to hit NaN whether or not D had 
anything to do with it.

> 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!

Yes.

> 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.

I think your solutions are not good. I also think my solution in 
http://goo.gl/3dGGkf is good. (I know it sounds awful, but I hope you'll 
appreciate the brevity :o).) The solution I propose explains exactly how 
NaN messes up the ordering comparison operator, in a way that doesn't 
make the tests refer to NaN or floating point numbers in particular.


Andrei