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

Re: Edge case conversions, exceptions to IEEE FPA

Van Snyder schrieb:
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?

I find myself defending a mere suggestion before it has been commented
on by Siegfried, who

The reason would be to ensure that mixed computations with floats and nonempty intervals always give nonempty intervals. This is a reasonable though debatable requirement; I'd prefer to convert bad floats to Empty.

If no arithmetic operation of floated different from NaN would give NaN,
one would not need to convert NaN.

Arnold's conversion suggests that +realmax represents {x|x>=+realmax}.


realmax is converted to itself, and inf to realmax, the closest finite floating-point number.

In Siegfried's sproposal, realmax is converted to itself, and inf to
[realmax,inf] = {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.

This is not a problem since inf as endpoint is completely uncontroversial. The conflict is about what to do with a floating-point inf that arose from a floating-point computation or conversion from text done for the sake of itself rather than as part of an interval computation.

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,


This would remove the above strangeness.

I think it just moves the strangeness somewhere else.

inf is needed as a bound, and this is uncontroversial.

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

OK; I wasn't completely precise. Of course division of an interval by the float zero will and should result in Empty, according to my
proposal (v2.0), and this would remain so even with the above modification.

But mixed arithmetic operations with floats and intervals will
never result in the empty set if they give valid results in exact arithmetic with intevals replaced by some real number contained
in it.

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.

In the notation of intervals as pairs of floats representing endpoints,
+inf cannot mean an interval itself, but only the upper bpound in the order closure of the reals.

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))

So you suggest to use inflation 2ulp wide for conversion of floats?
What then about intval(0.5) or intval(0.5e1)?

intval('0.1') should become something sharper than intval(0.1).

1ulp wide?

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.  T

No. (a:+inf) - (b:+inf) -> (a-inf,+inf-b) = (-inf,inf).

With the above definition of subtraction and bounds overflow, interval
addition and subtraction can be built on IEEE FPA without exceptions.

The problems with the conversion of +-inf and NaN has nothing to do
with the implementation of the operations, since the meaning of +-inf and NaN as 'real' numbers and the meaning as bounds in an interval are
completely separate issues.

Arnold Neumaier