Edge case conversions, exceptions to IEEE FPA
On (Mon, 17 Nov 2008 18:04:17 +0900) Christian Keil wrote:
> 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).
First of all, let's forget about intval(1e400) -- that's a red herring.
There are too many possible interpretations, some of which do not lead
to an exceptional situation at all(*). We are talking about intval(Inf).
This last "apart from" is actually a pretty strong reason, because it gives
a single interpretation to intval(float) where float is any IEEE 754 value:
treat the argument as standing for itself. Since neither Inf nor Nan can
be a *member* of an interval, the situation *is* exceptional, so the result
should be exceptional. Actually, based on that line of reasoning, none of
the three proposed values for intval(Inf) would be acceptable, as Arnold's
Empty, Siegfried's Tail (actually, my name for [realmax,Inf]), and my Entire
(proposed, but actually recommended, in an earlier post) are all ordinary
intervals, i.e. intervals that arise during actual IA operations, which are
always supposed to be free of exceptions. This line of reasoning suggests
that it should be John Pryce's NaI (Not an Interval).
> 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?
That could have been my mistake when reading in Arnold's document.
I forgot that the bang (!) is sometimes an escape character.
It would be better to write:
xx := number2interval(x) implies isIn(x,xx) = NOT(isEmpty(xx)).
(thus also distinguishing assignment from equality in "publication"
language as opposed to C, where "==" should have been used for equality).
A final comment about "unknown origin". The issue is, unknown to WHOM?
It is in fact "unknown to the language processor" that is at stake here.
The programmer is supposed to know, and hence should pick the appropriate
conversion; we agree by now that there need to be several, so that the
only remaining issue is which rule should apply to IMPLICIT conversion.
And there one wants the rule with the most precise and concise description
to make sure programmers know exactly what will happen, and hence will be
able to code accordingly. Personally, I value much more the ability for
competent programmers to write correct code than the ability to cover up
a larger proportion of programming errors.
Michel.
(*) Contexts where intval(1e400) is non-exceptional:
(a) IA-aware languages that defer conversion of literals until the
the context is known, implicitly carrying literals as strings.
(b) When the input argument type, though numeric, differs from the
interval inplementation type, in which case conversion to tightest
enclosure is used, which is the same rule as applies to (a) above.
In this case it is assumed that the input value is indeed 1e400
(possible if the input is Decimal128), or is shorthand for the
Binary128 number that 1e400 rounds to, which is the interpretation
normally used in examples that mention 1e308 for Binary64.
In both (a) and (b), interval(Inf) WOULD be exceptional.
Sent: 2008-11-17 15:10:01 UTC