Producing (-Infinity, +Infinity) instead of (NaN, NaN) for
Infinity-Infinity would be a reasonable objective. Doing it would be
slower than producing a NaN, but correctness must come first unless the
user allows deviations. We'll have to make a decision. That could also
be something we allow a compiler to violate for users who say they care
about performance more than they care about infinities.
Speaking of Infinity, more things to think about:
The Interval Arithmetic discussions have led me to believe IEEE 754
could have handled Infinity better. 754 Infinity has two meanings:
1. If you divide a +/-nonzero by +/-zero you get +/-Infinity, and I
can't see any other mathematically reasonable result except "invalid"
which is less useful. I'll call this TrueInfinity.
2. If you get an overflow you also get +/-Infinity, but the ideal result
would be a distinct value +/-Overflow, meaning the result overflowed but
is not infinite. Since 754 has no such values we have to make do.
Opinions vary, but since the fundamental Interval axiom is that the
correct value MUST be within the range, and alternatives would violate
that, I think we only have two valid options:
(a) Use +/-Infinity both for TrueInfinity and for overflow, or
(b) Invent our own +/-Overflow represented as a form of NaN with a
special payload saying it means Overflow.
That would require special code in almost every operation, or a trap
handler to detect an overflow and adjust the result (without perturbing
non-interval operations).
I prefer (a), because inventing +/-Overflow will cause larger slower
code in all cases when very few would benefit. On the other hand,
correctness must come first unless the user allows deviations, so if we
decide we really need to distinguish Overflow from Infinity, it isn't
impossible, just less efficient. I don't think that using the maximum
finite value is acceptable because then the fundamental Interval axiom
gets violated (eg, claiming that MaxFinite + MaxFinite <= MaxFinite,
which is untrue). (I used "MaxFinite" to avoid a precision-dependent and
language-dependent name.)
The current proposal essentially treats MaxFinite as both itself and
Overflow, which I think violates the fundamental Interval axiom, but you
could argue otherwise. It also needs either hardware changes or more
work to handle, but that's a performance not correctness issue.
There's also the question of what to convert a floating point Infinity to:
- If we use (a) above then we would be following the 754 overloading of
+/-Infinity to mean both +/-True Infinity and +/-Overflow. In that case
I think converting +Infinity to an Interval should give (+MaxFinite,
+Infinity) not (+Infinity, +Infinity) because the correct value may be
+TrueInfinity or +Overflow which is in the range +MaxFinite < +Overflow
< +Infinity. Similarly -Infinity should become (-Infinity, -MaxFinite).
The exception might be that if it was allowed and if you knew somehow
that the meaning was +/-TrueInfinity (eg, by seeing that the input came
from X/0), then you could produce the narrower range (+Infinity,
+Infinity) or (-Infinity, -Infinity).
- If we use (b) above, distinguishing between TrueInfinity versus
Overflow, then I think the result of converting +Infinity should be
(+Overflow, +Infinity) and -Infinity should be (-Infinity, -Overflow) .
- Ian McIntosh, wearing my asbestos suit Toronto IBM Lab 8200 Warden
D2-445 905-413-3411
Ralph Baker Kearfott <rbk@xxxxxxxxxxxxx> wrote on 05/03/2009 11:28:57 AM:
> And, again, what do we mean by "infinity as a number?" In 754,
> we had Inf - Inf = NaN, because there is no logical way of defining
> the result as a number, but, in 1788, we MAY (if we want)
> define Inf - Inf = [-Inf,Inf]; the latter has a valid interpretation.
>
> Baker
>
> On 2/26/2009 11:08 AM, Ian McIntosh wrote:
> >
> > VL> "Infinity as number" is buggy. For instance, with the above
point of
> > VL> view, if F(x) = (x+1)-x, then F(Inf) = (Inf+1)-Inf = Inf-Inf = 0.
> >
> > Under IEEE 754, F(Inf) = (Inf+1)-Inf = Inf-Inf = NaN, not 0.
> >
> > - Ian McIntosh Toronto IBM Lab 8200 Warden D2-445 905-413-3411
> >
>
>
> --
>
> ---------------------------------------------------------------
> R. Baker Kearfott, rbk@xxxxxxxxxxxxx (337) 482-5346 (fax)
> (337) 482-5270 (work) (337) 993-1827 (home)
> URL: http://interval.louisiana.edu/kearfott.html
> Department of Mathematics, University of Louisiana at Lafayette
> (Room 217 Maxim D. Doucet Hall, 1403 Johnston Street)
> Box 4-1010, Lafayette, LA 70504-1010, USA
> ---------------------------------------------------------------