Re: Edge case conversions, exceptions to IEEE FPA
(*) 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