Re: A note about {empty} and NaI...
> Date: Wed, 10 Jun 2009 13:12:24 -0400
> From: Nate Hayes <nh@xxxxxxxxxxxxxxxxx>
> Subject: A note about {empty} and NaI...
> To: STDS-1788@xxxxxxxxxxxxxxxxx
>
> John Pryce wrote:
> > (when given nonsense input); some interval mappings may be allowed
> > to destroy NaI (e.g maybe hull(xx, NaI) should return xx).
>
> I would also just add I believe NaI should always be a true annihilator,
> just like NaN in IEEE 754. This means no interval mapping can destroy the
> NaI. In my view, that is what {empty} is reserved for, i.e., {empty} is
> almost the same as NaI except that for any valid, non-empty interval X
>
> X \union {empty} = X but X \union NaI = NaI.
>
> I think it is important that 1788 will not conflate {empty} and NaI.
>
> Nate
Folks,
That NaN is preserved in all operations in 754 is a myth.
It is simply not true.
In particular, the selection functions minNum, maxNum,
minNumMag, & maxNumMag all return the number in the choice
between qNaN & a number.
Also, copySign(x, NaN) is perfectly happy to copy the 'sign'
of a NaN to a number & return that number according to clause
5.5.1. It is also happy to return the NaN according to clause
6.2. Unfortunately, implementors have gone both ways & we have
had to live with it.
And, of course, NaNs do not survive operations that result
in datatypes that are not floating-point types. For example,
any of the many conversions to integers as well as logB when it
has an integer result.
Each of the 22 comparisons defined returns True or False (as
is the case) when comparing a NaN to something else. Some
signal invalid in that case. Some don't.
None of the general operations class, isSignMinus, isNormal,
isFinite, isZero, isSubnormal, isInfinite, isNaN, isSignaling,
isCanonical, radix, totalOrder, or totalOrderMag, or sameQuantum
ever returns a NaN or signals an exception of any kind.
I suppose conversion of a NaN to a string may be considered
to have preserved that NaN in that the resulting string is
likely to have the substring 'nan' in it somewhere but there is
no guarentee that anything further about the NaN is preserved.
Neither need it be true that string2FP(FP2string(NaN)) be the
same NaN as the operand & for most string specifications for
most implementations this is highly unlikely.
The same may be said of conversions to & from hexadecimal
strings.
Clause 6.2.3 governs the rules of NaN propagation. It is
a bit tautological in that it begins with "An operation that
propagates a NaN operand to its result ..." & goes on to say
that almost all rules governing the propagation of NaNs are
governed by 'should' (read: 'need not do') rather than 'shall'
(read: 'must do').
Clause 9 functions would seem to return qNaN as a result for
NaN as input according to clause 9.1.1 but there are exceptions
listed in clause 9.2. For example, hypot(+/-inf,qNaN) = +inf,
& pown(qNaN,+/-0) = pow(qNaN,+/-0) = pow(1,qNaN) = 1. However,
powr(x,qNaN) = qNaN for x >=0 & powr(qNaN,y) = qNaN is provided
for those who would rather see NaN in those cases. In clause
9.4, sumSquare & sumAbs return +inf if any element is infinite
even if all the other elements are NaNs.
Perhaps it would have been nice if NaNs were the 'true
annihilators' that Nate seems to think they are.
Unfortunately it is simply not true. They are not.
Nor should they be. Most of the exceptions I've listed have
very good reasons for dropping the NaN.
But that is a tale for another day...
Dan