| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
On Fri, 2008-11-07 at 08:50 -0800, Arnold Neumaier wrote:
> This is why I had proposed to convert
> +inf into the interval [realmax,realmax],
> -inf into the interval [-realmax,-realmax],
> NaN into the interval [0,0]
> (for symmetry reasons, and since 0*inf=NaN suggest that in
> floating-point arithmetic, NaN is a limiting form of zero),
> and to raise the nonstandardNumber flag as in Section 2.1 of
> my proposal (Version 2.0).
I assume the reason for this is to avoid exceptions from the behavior of
P754 when interval arithmetic is built atop it. If P754 had defined
0*inf to be zero instead of NaN, would your conversions be different?
Arnold's conversion suggests that +realmax represents {x|x>=+realmax}.
Therein, intval(+realmax) -> [+realmax,+realmax], so there is no
difference between +realmax and +inf, and we might as well use +inf.
If P1788 is based upon P754 we still have the problem that [a,+realmax]
+ [b,+realmax] -> [a+b,+inf] with overflow signaled. Should the IA
implementation trap the overflow signal and convert the interval to [a
+b,+realmax]? How is this different from leaving the result as [a+b,
+inf]?
> This would remove the above strangeness.
I think it just moves the strangeness somewhere else.
> Somehow, my suggestion seems to have missed your attention.
> Please comment on this proposal to modify the interpretation
> of +-inf and NaN.
>
> With this interpretation, fixed operations could be handled
> at about the same cost as with the interpretation in my proposal
> (Version 2.0).
>
> With nonreal floating-point numbers interpreted as empty, we'd have
> to convert a=+-inf to NaN before execution of formulas such as
> a+[l,u] = [a+l,a+u], etc.,
> while with the above proposal, we'd convert a=+-inf to +-realmax and
> a=NaN to 0 before execution. And similar for formulas based on
> explicit case distinctions.
>
> Then mixed arithmetic operations with floats and intervals will
> never result in the empty set.
In the proposal that I prepared for P754 from Ulrich's work (I acted
purely as editor -- I didn't change any of his mathematics), empty sets
arose during division [x,y]/[0,0] when x>0 or y<0. So it seems empty
sets arise, although perhaps not from operations between points and
intervals.
Consideration of the exceptional cases from a computational perspective,
leads me to believe that if intervals represented by two IEEE objects
other than NaN are considered to be open (in the real-number sense, not
the FP number sense), IA can be based upon IEEE FPA with only a few
exceptional cases mentioned below, and the sign of zero can be ignored.
I,ve just done some hand-waving about limits, but haven't otherwise
thought this through from a mathematical perspective.
If any interval with NaN as either boundary is specified to represent
the empty set, IEEE FPA causes any operation in which an operand is the
empty set to produce an empty set as the result. I think this the
desired behavior.
Fortran's notation for intervals of integers is I:J (so far, this exists
only for subscripts but ought to be extended to first-class
integer-based objects and would be a natural program notation for
FP-based intervals). I use this notation to distinguish what follows
from what we have been discussing in this forum. For the same reasons,
I use Fortran's HUGE and TINY. Unless explicit otherwise, HUGE and TINY
are taken according to the precision of the context, i.e., either
HUGE(1.0e0) or HUGE(1.0d0), etc., as necessary.
I interpret the single object IEEE +inf to repesent {x|x>+HUGE}, not the
point \infty. That is, an open interval. When +inf (-inf) is used as
an upper (lower) bound in an interval, it represents +\infty (-\infty),
not {x|x>HUGE} ({x|x<-HUGE}). Thus intval(+inf) -> (+HUGE:+inf), which
we can't represent with closed intervals based upon IEEE FP because
there is no next floating-point number after +HUGE. When +inf (-inf)
would be the lower (upper) bound of an interval, it represents the set,
not the point, so [-inf,-inf] -> (-inf:-HUGE) and [+inf,+inf] -> (HUGE:
+inf). Thereby, in a proper interval +inf is never a lower bound, and
-inf is never an upper bound.
The edge case conversions are as follows. Single- and double-precision
infinities are distinguished as necessary using sinf and dinf,
respectively. According to the above interpretation +sinf represents
{x|x>HUGE(1.0e0)} and +dinf represents {x|x>HUGE(1.0d0)}, when they are
not upper bounds, and +\infty when they are upper bounds.
intval(inf) -> (HUGE:+inf)
intval(-inf) -> (-inf:-HUGE)
intval(1.0e40) = intval(sinf) -> (HUGE(1.0e0):sinf)
intval(1.0e400) = intval(sinf) -> (HUGE(1.0e0):sinf)
intval(1.0d400) = intval(dinf) -> (HUGE(1.0d0):dinf)
intval(1.0d40) -> (NEAREST(1.0d40,-1.0d0):NEAREST(1.0d40,+1.0d0))
intval(0.1) -> (NEAREST(0.1,-1.0):NEAREST(0.1,+1.0))
intval('0.1') should become something sharper than intval(0.1).
intval(NaN) -> (NaN:NaN) = the empty set
intval(x,y) -> (x:y) provided x <= y and either x or y is finite. If
either one is NaN the result represents the empty set
intval(-inf,-inf) -> (-inf:-HUGE)
intval(+inf,+inf) -> (+HUGE:+inf)
Using IEEE FPA, (a:+inf) - (b:+inf) -> (a-b:NaN) = the empty set. This
is probably not the answer you want, so (x:y)-(u:v) -> (x:y)+(-(u:v)) ->
(x:y)+(-v:-u), and therefore (a:+inf)-(b:+inf) -> (a:+inf)+(-(b:+inf))
-> (a:+inf)+(-inf:-b) -> (a-inf:inf-b) = (-inf:+inf). Subtraction of
infinities, resulting in NaN, never arises during addition because +inf
(-inf) is never a lower (upper) bound.
If the upper (lower) bound of the result of an operation overflows to
+inf (-inf) it remains. If the lower (upper) bound overflows to +inf
(-inf) it must be converted to +HUGE (-HUGE). This prevents problems
later, e.g. in adding the result to (-inf,z). If IA is implemented in
hardware, a lower (upper) bound of +inf (-inf) could be converted within
the arithmetic unit to +HUGE (-HUGE).
With the above definition of subtraction and bounds overflow, interval
addition and subtraction can be built on IEEE FPA without exceptions.
The invalid cases for multiplication and division using IEEE FPA are
0*inf, inf*0, 0/0 and inf/inf. P754 defines these to be NaN. The
proposal sent to P754 implicitly assumes these are 0, 0, NaN and inf.
A draft based upon the proposal sent to P754 is attached for reference.
For purposes of this message, the interesting parts are tables 4.1-4.3
on pages 11-13.
To summarize the exceptions to IEEE FPA:
0*inf -> 0 instead of NaN
inf*0 -> 0 instead of NaN
inf/inf -> inf, with the sign as specified in the attachment, instead of
NaN
(+inf:+inf) -> (+HUGE:+inf)
(-inf:-inf) -> (-inf:-HUGE)
(these, together with the transformation of subtraction, prevent inf-inf
from appearing).
--
Van Snyder | What fraction of Americans believe
Van.Snyder@xxxxxxxxxxxx | Wrestling is real and NASA is fake?
Any alleged opinions are my own and have not been approved or
disapproved by JPL, CalTech, NASA, the President, or anybody else.
Attachment:
P1788.pdf
Description: Adobe PDF document