On 11/12/13 8:00 AM, Vladimir Panteleev wrote:
1) NaN values are accepted as input almost anywhere where doubles are.
std.conv recognizes the string "nan" and converts it to double.nan,
They are still singular values. Code has no business comparing them
unwittingly.
2) It is unreasonable to expect every D user out there dealing with
floating point numbers to be forced to check every source of floating
point values in their program against NaNs.
I find that perfectly reasonable. How do you mean that?
3) If the program is compiled in debug mode, it will crash
quasi-randomly, since the assumeSorted assert does not check every pair.
It should always crash. As I said: insert an assert in assumeSorted and
be done with it.
For these reasons, this problem can become a sort of time bomb in their
application: even with 100% test coverage, one NaN in the wrong place
inputted by a malicious end user can cause a situation the program's
authors have not foreseen.
It can be argued that it is a flaw in the language in that it allowed
such a situation to arise in the first place.
The language allows NaN floating point number with the semantics of IEEE
754. We hardly have any leeway in the matter unless we want to irate a
lot of people for no good reason.
I don't understand your entire point here. I agree with something like
"NaNs are a nuisance." We need to fix the corresponding bugs in
assumeSorted, isSorted etc. by inserting sanity checks such as:
if (a[i] < a[i + 1]) { assert(!(a[i + 1] < a[i])); ... }
else { assert(a[i + 1] >= a[i]); ... }
etc.
Andrei
