Re: Edge case conversions, exceptions to IEEE FPA
Given the interval constructor "intval" mapping floats into intervals
and the call
y = intval(x),
what is the interval result y for input x=inf?
I see three possibilities for the user's program to produce this
situation:
1) y = intval(inf) the input argument is true infinity
2) y = intval(1e400) a constant causing overflow
3) y = intval(expression) an expression with result inf.
Ok, now we've indeed isolated the main point of contention -- but not
quite. I think Siegfried left out a fourth case, which is in fact the
one I've been most concerned with:
4) y = intval(variable) a floating-point variable with value Inf
You are right, but I think this is not really relevant to the discussion,
it is theoretical. The setting is
- some computation is performed,
- maybe flags are cleared,
- some variable x is computed, and
- now x is transformed into an interval variable by type cast.
I read between the lines that the true value for x - if all computations
had been performed in interval arithmetic - should possibly be contained
in y. Of course, this will, in general, not be true, but we may try to
come close to it.
I am working in verification methods more than three decades, but this
scenario
never occurred. If an inclusion of the true value is needed, interval
arithmetic
is used from the beginning.
The typical case were a float variable is type casted into an interval
variable
is that some approximation has been computed and is fed into a verification
algorithm. Then only the VALUE of the approximation is important, not the
computation that led to it before-hand.
Therefore case 4) is similar to case 1) or 2).
Arnold's proposal merely uses "empty" as a flag, no information is passed.
Taking x as a VALUE without some computation in the backpack, I think
[realmax,inf]
is not unlikely to be the inclusion we are looking for. But one may argue
about that.
One more point I'd like to make in favour of intval(Inf)=Empty:
It preserves the relation isIn(x,intval(x)) for all floats x
(in the model where the underlying range is Non-extended Reals).
Do you mean "for all finite floats x"? Otherwise (in Arnold's proposal)
x=inf is not a member of intval(x)=Empty.
But
isIn(x,intval(x)) for all (finite) floats x
is also true in my proposal.
I give another, practical example in executable INTLAB code:
function Y = range(f,X)
% Inclusion of the range f(X) = {f(x): x in X} for f:R^n->R and interval
vector X
%
G = f(gradientinit(X)); % inclusion of the gradient
if any(in(0,G.dx)) % gradient components may contain zero
Y = f(X);
else % the function is monotone
Y = hull( f(intval(X.inf)) , f(intval(X.sup)) );
end
The function computes an inclusion of the range f(X) of a function f over
some interval (vector) X.
It gives back the hull of an inclusion of f(X.inf) and f(X.sup) is f is
proved to be monotone, and
otherwise the result by ordinary interval arithmetic.
I think this is a reasonable approach. The problems come with infinite
intervals when
intval(X.sup) becomes empty.
The function works fine in my approach:
X=infsup(5,inf); f=@(x)(x^2-1); range(f,X)
intval ans =
[ 24.0000, Inf]
were the "else"-branch was used.
In Arnold's approach the result would be the point interval [24,24] with a
flag set.
I don't like flags. I think any arithmetic including IA should be usable
for casual users -
who may not even know about the existence of such a flag.
Besides, I am not sure whether flags can be traced in Matlab, e.g. the
overflow flag.
I doubt mathworks would support several IA flags on every platform.
Best wishes
Siegfried
--
=====================================================
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