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

[N.M. Maclaren]

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

Nor are they, really.  Those decisions were taken 25 years ago.  Kahan
was the prime mover, and the following is deduced from his papers as
well as IEEE 754.

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

Perhaps.  Actually, I think that it was mostly a committeefication of
Kahan's original Intel specification.

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

I am pretty sure (well, more than that, actually) that the intention was
that programmers would write code that tested for a condition, and the
alternative ('else' or nothing) was normally the correct one to choose,
and this would lead to more 'fail-safe' programming.

I wrote some small code according to those rules, very carefully, and 
checked it. I then 'compiled' it by hand, actually following the data 
paths. I had got c. 20% of the tests the wrong way round for correct NaN 
handling. Given that I was a pretty good programmer, I considered it was 
implausible that most programmers could use NaN tests in that way and 
improve their code.

I'll skip the 'error value' versus 'missing value' question.  IEEE 754R
gets that spectacularly wrong, because the semantics are incompatible,
and they didn't understand missing values, anyway.  I have a paper on it
that I never published, if anyone is interested.

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

Not really.  That's the THIRD incompatible use of NaNs that IEEE 754/R
includes: out-of-band values.  Even base IEEE 754 hinted at it.

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

Not entirely, provided that it is a program-wide option and done
consistently.  To choose between error value, missing value and out-of-band
value AND STICK TO IT is reasonable.  But, with the last, adding 1.23 to
an out-of-band value gives a totally erroneous (non-numeric) value, and
not the same out-of-band value.

> > 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 thatleads from "it is not a number" to "it must be +infinity".

It's an old convention, and derives from statistics.  Consider it as
an 'other' response.  I agree that it is bonkers to extend a convention
for the display of tables to use in actual arithmetic ....


Regards,
Nick Maclaren.