Re: A note about {empty} and NaI...
Dan Zuras Intervals wrote:
> 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,
I don't think anyone expects NaN should "anihilate" boolean operations like
classification routines or comparison relations (or even utility routines
like copySign which are designed to give programmers "under the hood" access
to the binary represention). In our own C++ interval library, we have
isNaI(xx), etc., as well as comparison relations such as
NaI != NaI = true
NaI <= [0,2] = false.
I write about a few of these in Section 7.6 of my paper. They all follow
naturally from the properties of NaN/NaI.
Does it mean NaN/NaI are not "true anihilators?" I don't think so. Does it
mean exceptions don't exist? Clearly they do, and I agree for good reasons.
But this only underscores the reason why it is so important in 1788 that
{empty} and NaI should not be conflated or fused together. They are distinct
abstract objects with different properties and purposes: one is member of
the set-theory, for example, and the other is not.
Nate