Re: The current proposal - Infinity
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
> ---------------------------------------------------------------