Arnold Neumaier wrote:
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.
I am a bit reluctant to rely on a property of IEEE754 NaNs which is new
to me, probably not used a lot, and which may have some portability issues
(I would rather that IEEE-1788 only requires a subset of IEEE-754-2008).
Moreover, and most importantly, I am not sure how nicely this information
gets propagated through operations:
- how does it propagate through a floating-point addition?
(e.g. what if you add 2 such NaNs with the same or different attached
information?)
- how would it then propagate through interval additions and other
operations?
and with which overhead?
If it does not propagate nicely (automatically and efficiently), then
basically
it means that the user has to test manually what kind of Empty he gets,
*just after* the conversion float->interval, which is as cumbersome as
testing
it *just before*, but the later removes the need for reporting useful
information
in the conversion, so IMO it's better.
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.
Further thinking about this, I am now of the opinion that
intval(1e309) = Empty is not safe enough.
Arnold's proposal mentions an accompanying error flag, but also the
sentence
"I expect that the flag will never be inspected", with which I agree.
I would definitely prefer it to return Entire.
At least this way, the basic containment property is at the safest level,
while if you use Empty, an error could easily go undetected:
Take the example of an algorithm computing the hull of a bunch of
floating-point
values. The algorithm iterates over the values, converts them to interval,
and accumulates using hull(). If a floating-point value is 1e309 or +Inf,
and it gets converted to Empty, then it has gone unnoticed.