Sorting floating-point values, and NaN

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Tue Nov 12 08:47:59 PST 2013


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




More information about the Digitalmars-d mailing list