Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Motion P1788/M007.01_NaI



Vincent Lefevre wrote:
>  then it would be much more correct to say "several NaI's"
>  than "a NaI with payload".

I agree.

> No, you can't use the same reasoning because of the rule on the limits:
>   lim_{x -> 0, y -> +oo} x * y
> doesn't exist (note that here I don't use the extended real numbers).

The problem is that there are two notions of zero in IA:
  the single point {0}, which is exact, and which is
  idempotent under multiplication with arbitrarily large reals
and
  an interval containing zero, in which case limit processes
  may indeed be relevant.

Note that interval arithmetic typically involves IEEE operations on
endpoints, and that an endpoint of zero should imply that all points
in the interval have the same sign.  Nevertheless I agree that when
a product of endpoints is of the form 0*oo the indefiniteness of the
limit may indeed play a role.  Arnold Neumaier however seems to have
good reasons for expecting 0*oo = 0 in this case too.

In IEEE FP arithmetic we often don't know whether either 0 or oo is
exact or not (in the latter case, result of underflow resp. overflow).
The inverse of exact (signed) zero is an exact signed infinity, and
there is no question that 0*oo is totally undefined in this case.
If one of the two is exact, the result should be that one -- but
754 has no way to identify this case, so it can't deal with it.
(Well, it *could* have made the result dependent on the Inexact
flag -- but can you imagine the howls of despair from many people?)
If neither is exact, limit reasoning applies, and again the result
is undefined, and NaN must be returned.  So 0*oo = NaN always.

Michel.

P.S.  This discussion is related to the revived stds-754 thread on
    Subject: Re: why no separation of "true zero" and "positive zero"?
      in which I pointed to a similar discussion on stds-754 in June 2007,
      findable by searching for "overloaded".
---Sent: 2009-08-24 16:58:22 UTC