Edge case conversions, exceptions to IEEE FPA
On Mon, 10 Nov 2008 23:02:00 -0100, I wrote a detailed critique of
the opposing points of view of Siegfried Rump and Arnold Neumaier.
Unfortunately I was misled by a typo in Siegfried's example, from
which I concluded that his approach was inconsistent, compared to
Arnold's. So the situation is not clear-cut after all. Here are
some replies to questions Siegfried asked here.
On Thu, 13 Nov 2008 10:30:01 +0100 Siegfried M. Rump wrote:
> > (*) The Interval->Float functions inf() and sup() that return the
> > bounds can return Inf -- and if this is fed into an interval
> > constructor as a value (instead of as a bound), an exception
> > should arise. Arnold's proposal covers this; the result of a
> > violation is simply Empty.
>
> This means that if we want to compute an upper bound for the diameter
> of an interval, then in Arnold's proposal (using INTLAB notation)
> diam = sup( intval(X.sup) - X.inf )
> is empty for X = infsup(3,inf) with an exception raised.
I suppose the underlying IA runtime would have diam() and mid()
primitives -- the question is, what would they return. If they
return a float, this would indeed by Inf if either end is unbounded.
Perhaps they should also have a form that returns an interval, which
would be [realmax-lower, Inf] for diam([lower, inf]), and (presumably)
the possible range of midpoints, [(realmax+lower)/2, Inf], for the
mid"point" of that same source interval. Arnold may have more to say
about this.
I suspect Siegfried's model would return the same. My (*) was intended
to warn about these issues in Arnold's model. I'll have to think more
about the implications in Siegfried's.
> How to deal with the language literal 1e400 which becomes inf in the
> function "intval".
Well, I think this is a *language* issue about which the proposed 1788
standard would only be able to offer suggestions, not mandates. We do
want to be able to use interval libraries in languages that don't have
explicit interval support, don't we?
> > (1) IEEE arithmetic can yield exact Inf -- but only in contexts
> > that involve division by zero. This could be dealt with by
> > trapping or monitoring the IEEE divideByZero exception.
> >
> > For example, the IA runtime could clear the DZ flag initially,
> > and when converting Inf to an interval, it would return Empty
> > when DZ was set, and [realmax,inf] if not.
> >
> > This leaves the issue of when to clear the DZ flag...
>
> Obviously this doesn't work. The DZ flag could be set anywhere.
I am assuming the context of a well-written program that mixes float
and interval arithmetic. Such a program should have cutpoints where
summary flags like DivideByZero and Overflow are monitored and reset
by the program when unexpected conditions have been handled. In that
case neither DZ nor OV should be set when an IA routine is invoked,
unless an unexpected event occurred since the last cutpoint. Those
two flags can indicate what an Inf might be, and they are semi-true,
i.e. if both flags are zero, the Inf is known to be the result of a
previously-recognized overflow. If not, we don't know whether the
Inf in question (on input to IA) is clean or dirty -- so we make
sure we get a propagating error carrier, such as Empty, to permit
deferred recognition of the error. This can be especially valuable
in vector (SIMD) processing.
In any case, it was just a suggestion. More people will have to
think about the implications so we can get a better overall picture.
> > (2) IEEE arithmetic propagates Inf -- but although an original Inf
> > (as the result of overflow) denotes a value that exceeds realmax,
> > a propagated Inf does not. There is not much we can do about
> > this, as Inf propagation is silent under IEEE 754.
>
> What exactly do you mean by that, can you give an example?
In the computation (realmax/2)*3 - (realmax) the multiplication
triggers overflow and returns Inf. The subtraction that follows
then propagates that Inf quietly. If this computation is actually
carried out in separate steps, with other things in-between, the
overflow indication could have been cleared before the subtraction
is reached, and at that point no further flags or exceptions would
result from the subtraction: the Inf propagates quietly. In the
absence of overflow (e.g. in a wider format, but using the realmax
of the narrower format as an ordinary float) the result would of
course have been -realmax/2 (again referring to the smaller realmax).
This situation actually occurs in so-called "reduction" operations
in IEEE 754-2008, where a sequence of operations is allowed to be
carried out in a wider intermediate format, with the result returned
in the original format. It is also common on the x86 platform, where
FP computations are typically carried out in an extended intermediate
format, but possibly with unpredictable coercion of intermediate
results to plain double, at the mercy of register allocation pressure.
I did give an example:
>> The "something" could be a string, or a float in a wider format
>> than the IA implementation format.
> I still think both models are consistent. I am curious about an
> example showing the contrary for my model.
Well, the one thing that bothers me about the conversion of float Inf
to the interval [realmax, Inf] is that the input Inf could have come
from a sequence of FP operations with overflow in the middle (not at
the last step), in which case the correct enclosure would be Entire,
and not +Tail (a name I just made up for [realmax, +Inf]).
Most of Siegfried's examples involved program literals, where there
is only one step, so that Tail is indeed a correct enclosure. But,
unless I have misunderstood, he wants to treat any float Inf this
way -- and that is where I prefer Arnold's approach.
Michel.
Sent: 2008-11-13 19:48:53 UTC