>> I get Eliots statement that, given all the different possible origins
>> of NaN, assuming equivalency is assuming too much.  But that's a
>> purists view
>
> Well, hang on, because this comes down to one of the subtle issues we end
> dealing with all the time.  In short: we tend to reinterpret others' ideas
> to our liking.  The issue is that in doing so we might develop our own brand
> of IEEE-754 which is then incompatible with the IEEE-754 understanding of
> everyone following the standard to the letter --- including the
> implementation of modern FPUs.
>
> I'm not saying I like every single little thing in IEEE-754.  However,
> compliance gives me compatibility, portability, the ability to read Knuth
> without having to redo his work according to my private interpretation of
> IEEE-754, etc.  It's a compromise: in exchange for restraining oneself, one
> can take advantage of the work of others.

Oh, absolutely yes.  I hope I did not give anyone the idea I actually
want to DO anything about this.  Not at all.  It was just the == but
not = "violation" that caught my interest enough to poke out an email
to y'all.  This is way too low-level to change (and my image
immediately locked when I tried  :), and way too fraught with unknown
consequences, not to mention non-standard and non-compliant in a
critical part of the system.

I like Berts solution because its explicit enough to not need a
comment, but for my situation would require an additional type-check,
since it can be any object going through there, not just Numbers.  So,
for now, I just went with the efficient "a==b or: [a=b]" solution and
put a comment on it.

 - Chris