Alternate floating-point results under directed rounding
John Pryce wrote:
> Similarly if a mixed point & interval computation goes close to
> overflow then - in genuine application code - that's dumb, and
> you should be _grateful_ for a mechanism, like returning Empty,
> that tells you so.
>
> Actually I say it should return NaI. Empty can be a genuine,
> correct result, whereas NaI is _always_ an indicator that
> something went wrong.
I'm definitely of the school that says errors should never be hidden.
There is however a valid argument that Interval Arithmetic PER SE
never leads to exceptions; the worst results are the empty set and
the complete set of reals.
It seems to me that what we are discussing here is something that
happens at the edge of IA. Clearly I can't sensibly convert the
string "foobar" to an interval, and saying that any nonsense should
quietly be converted to the empty interval is indeed NOT A GOOD IDEA.
Since exact on-the-spot exception handling is (as P754 became painfully
aware of) not universally available, it makes sense to define something
that can be injected into an IA computation to indicate that it is not
a valid interval -- i.e. NaI -- with the appropriate propagation rules
and possibly flag setting and/or exception triggering (taking advantage
of the relatively flexible rules defined in 754-2008). This permits
proper deferred exception handling, which is especially valuable in
SIMD applications where, say, an entire array of strings is converted
to an array of intervals, with some invalid strings scattered about.
Michel.
Sent: 2008-11-10 15:39:42 UTC