Re: Edge case conversions, exceptions to IEEE FPA
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). 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. 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 while the pro
should be able to decide,
intval(1e400) = [realmax, oo] seems to be the sensible choice for me.
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).
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?
Best regards,
Christian
--
/"\
Christian Keil \ / ASCII Ribbon Campaign
mail:c.keil@xxxxxxxxxxxxx X against HTML email & vCards
/ \