Re: Edge case conversions, exceptions to IEEE FPA
Christian Keil schrieb:
It seems to me that the main argument against
intval(1e400) = [realmax, oo]
is that we do not know where the oo came from. But this is true for
every value x supplied to intval(x).
Therefore, the only proper conclusion is that the user must know where
it came from, and make sure that it is an exact value.
It is not reasonable to demand that the user must know that it is
an exact value provided its magnitude is below maxreal, but to
account for the rare case where it isn't by treating it then as an interval.
Perhaps some IA-aware language
could distinguish between a literal and a variable/expression supplied
to the constructor. But in the latter case, irrespective of the value
supplied to the constructor, it can have an arbitrary error.
The constructor should only be used when it is known that the value is
exact. Such as when computing in an interval newton method an interval
enclosure for a point value. But never for intval(1e-1) or intval(1e308)
or intval(1e309).
We all know
that floating point computations can yield arbitrarily wrong results not
just if the floating point result is oo. Following the argumentation to
convert intval(1e400) to the empty set, you could therefore argue that
intval(x) should always return empty...
Taking into consideration the recent wish that
- an implementation should follow the principle of "least astonishment" and
- the amateur programmer should get the expected results
Even amateur programmers must know that the result will be incorrect for
intval(1e308); once they know that they weon't write intval(1e309)
or intval(1e400).
while the pro
should be able to decide,
intval(1e400) = [realmax, oo] seems to be the sensible choice for me.
I find
intval(1e308) = an interval not containing 1e308
intval(1e309) = [realmax,inf]
at least astonishing as
intval(1e308) = an interval not containing 1e308
intval(1e309) = Empty
especially as the 754 standard permits loaded NaN's which allow the
user to distinguish different sources of NaN, hence different kinds
of Empty.
However, writing intval(1e308) or intval(1e309) must be considered a
semantic error anyway, hence the result doesn't matter, and simplicity
and genericity of the definition should be the deciding principle.
With intval(x) and realHull(x,x) both versions would be available.
Should the standard specify which has to be the default (implicit)
conversion? After all any result obtained by not starting with intervals
in the first place lacks rigor.
So beside the argument of unknown origin. Are there practical
considerations in favor of one or the other version? Siegfried sent the
example code from INTLAB to support intval(1e400) = [realmax, oo]. As
this discussion went on for some time, I don't remember if there were
practical arguments for the other version (apart from oo is not a real
number and therefore no interval can be constructed containing it).
If intval(1e400) is interpreted as a proper interval then,
for the same reasons, 1e400+xx, 1e400*xx, xx/1e100, etc should
also interpret 1e400 as a proper interval. Therefore,
specifying the result of mixed (real, interval) operations becomes
more combersome, since phi(inf) and inf circ real must be treated
completely differently from the other cases.
A short question to Arnold's proposal. You say that intval(oo) = empty
preserves
xx = intval(x) implies isIn(x,xx)=isEmpty(xx).
I assume this has to be isIn() = !isEmpty(), with ! denoting negation?
Yes, of course.
Arnold Neumaier