Re: Edge case conversions, exceptions to IEEE FPA
I would like to propose a flag that indicates if an endpoint of an
intervalis is included or not. It might be helpful in edge case
conversions. Here are few initial rationales:
1. For maxReal <= x < oo, say 1e400, we can set the inclusion flag
false at oo. Similarly, for 0 < x <= minReal, we can set the flag false
at 0. Then operations on them could be handled more reasonably.
2. Give user the option if he/she wants to specify an open interval.
3. It can be useful in inner approximation.
4. By setting the default to true, this would not complicate things on
closed intervals as we discussed so far.
Chenyi
>>> "Siegfried M. Rump" <rump@xxxxxxxxxxxxx> 11/13/2008 3:30 AM >>>
> (*) 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.
> Part of this comes from a certain ambiguity in a statement like:
> X = intval(1e400)
>
For me this is the only point. I support intval('1e400') for the
standard (and also in INTLAB since the beginning). The question
is: How to deal with the language literal 1e400 which becomes
inf in the function "intval".
> There are the following issues however.
>
> (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.
>
> (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?
> Now, Siegfried says:
>> My interpretation of the input inf is a huge number, so that ...
>
> This would be acceptable if we knew that this inf was in fact an
> input, i.e. the direct result of a conversion of something that
> did not fit in the floating-point format. My point (2) however
> shows that this cannot be depended on -- which is why it is better
> to supply the "something" directly to the interval constructor.
I don't understand, can you give a simple example?
> Later Siegfried gets into trouble:
>
>> Converting 1e400 into ?realmax,realmaxÙ would also be strange to me
>> because, e.g.,
>> intval(1e500) / 1e400 = ?1,1Ù
>> in this definition. In your (original) definition it would be
empty,
>> in mine ?1,infÙ.
>
> What if the example reversed 1e500 and 1e400? Then both definitions
> based on realmax would be wrong, but "empty" would still be right,
> even if bothersome.
This would have convinced me straight away. However, sorry, I made a
mistake; of course we have
intval(1e500) / 1e400 = [0,inf] ,
the same as
intval(1e400) / 1e500 = [0,inf]
because (using operator concept) both translate into
[realmax,inf] / [realmax,inf] = [0,inf] .
In either model a user error may produce wrong results (well, this is
not
new anyway). Example 1:
X = intval(1/0)
which is the same as X=intval(inf).
In Arnold's model X is empty, the only correct answer because
intervals
are over reals. In my model X is [realmax,inf], incorrect by user
error.
Example 2:
X = intval(1e400)
which is the same as X=intval(inf).
In my model it is [realmax,inf], the only (in terms of narrowest)
correct
answer. In Arnold's model it is empty, incorrect by user error.
Best wishes
Siegfried M. Rump
--
=====================================================
Prof. Dr. Siegfried M. Rump
Institute for Reliable Computing
Hamburg University of Technology
Schwarzenbergstr. 95
21071 Hamburg
Germany
phone +49 40 42878 3027
fax +49 40 42878 2489
http://www.ti3.tu-harburg.de
and
Visiting Professor at Waseda University
Faculty of Science and Engineering
Shinjuku Lambdax Bldg. 902
2-4-12 Okubo, Shinjuku-ku
Tokyo 169-0072
Japan
phone/fax in Japan +81 3 5286 3414