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.
