(j3.2006) (SC22WG5.4150) [ukfortran] [Fwd: [WG2.5] [Fwd: NaN question]]

[Malcolm Cohen]

I recommend asking the people concerned, viz the 754 committee.  Yes, really. 
We could give our opinions on why 754 did stuff, but we aren't the ones who did 
it.

> The question is about the rationale behind a design choice in IEEE 754.

It got the votes... if there were 20 people on the committee there were probably 
50 different reasons why NaN/=NaN was thought to be a good idea.  (And maybe a 
dozen reasons for thinking it a bad idea too.)


> Why is NaN not equal to NaN? It makes sense that x # NaN = NaN for any
> arithmetic operator #, but for equality this seems far less justified.
> Perhaps in three-valued logic NaN = NaN would be NaN, but with only two
> values True seems a more reasonable answer than False.

Here are some ideas...

Philosophically: NaN is not a number, so it cannot be numerically equal to 
anything else.  Is a piano equal to a writing desk as floating-point numbers - 
no, they aren't floating-point number so they are not floating-point equal.  Is 
a piano equal to the same piano as a floating-point number - no, it still isn't 
a floating-point number so it is still not floating-point equal.

Pragmatic using NaN as "missing values": if two data sequences have missing 
values, treating two values the same just because both are missing is likely to 
be problematic.

Pragmatic testing: since NaN often needs to be treated specially, X/=X gives you 
an easy test for that.

Error coding: If a particular NaN means "it's the result of SQRT of any negative 
number", that would make SQRT(-1.0)==SQRT(-222.5) which might be thought to be a 
bad thing.  There aren't enough spare bits in the NaN representation to make all 
the different errors into different NaNs.

So, if
 (a) sometimes NaN means "missing value"
 (b) sometimes NaN means "indeterminate value" (sequence didn't converge or 
diverge kind of thing)
 (c) sometimes NaN means "previous floating-point error"
 (d) sometimes NaN means "uninitialised variable"
in all those cases the same NaN is being used for different things.
If
 (e) sometimes NaN means "not a number but is a valid something else"
then in this case it *might* make sense to consider two instances of the same 
NaN as representing the same thing, but not necessarily.  As it happens, this 
particular use is vanishingly rare anyway.

> This is the semantics that large-scale Eiffel users want

Then they probably don't want IEEE arithmetic.

In fact, I'd guess that for reasons known only to themselves they'd want to 
treat different NaNs as being equal too, and that idea holds even less water.

> and we are in
> the process of implementing it, at least as an option, but we are
> wondering whether we are completely off the mark.

Yes.

> A related question is the value of x < NaN; here it does not seem
> unreasonable to take the convention that NaN is larger than anything else.

That seems totally bonkers.  Is someone confused between NaN and +INF?  Why 
should ASIN(22.0) be >22.0?  I just cannot imagine the chain of reasoning that 
leads from "it is not a number" to "it must be +infinity".

Cheers,
-- 
................................Malcolm Cohen, Nihon NAG, Tokyo.