Re: Edge case conversions, exceptions to IEEE FPA
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.
This was not intended as a proposal how to compute the diameter of
an interval. We are mainly interested in interval computations, and
interval arithmetic is a tool fot that. The example was just meant
as an example of a reasonable computation were - in my opinion -
the result "empty" seems strange.
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?
Let me make it clear again, my only question (and this seems to
be the only point of disagreement, is the following:
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.
The discussion moves often to case 3), but I think expressions with
result inf are not much relevant to our discussion for two reasons:
a) It is likely that the exact result of any expression is not a
floating-point
number. Thus at least a point interval is wrong in the mathematical sense.
b) There is no universal way to always produce a mathematical correct
result,
neither Arnold's "Empty", my [realmax,inf] nor Michel's "Entire".
It has been mentioned by some on this list that interval arithmetic is
not to extend fl-pt arithmetic or to cover fl-pt operations in some way.
It is a mathematical model in itself.
For cases 1) and 2) we have the problem that the union of all intervals
do not cover all floats, infinity is excluded. We have to build intervals
upon the floats, using floats as endpoints, but for infinite floats it is
proposed that the endpoints do not belong to the interval.
It may be more consistent to define that "inf" means huge but finite.
Then naturally the interpretation of "inf" as input to the type cast
intval and as bound of an interval are the same.
I know my proposal is not perfect, and the discussion shows this; at least
0 * intval(anything) is zero
for any anything (except NaN, but this is another business).
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).
Yes, but Arnold's "empty" is mathematically incorrect as my "Tail".
But again, it is an expression. Accidentally the result realmax/2 is
a float, I guess Michel constructed it that way; I think this is not
typical.
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]).
But for x=1/0 ... a long computation clearing flags ... y=intval(x)
the result "Entire" would be incorrect as well. Again, these are
expressions which can't be treated satisfactory anyway.
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