MidRad -- and Two Different Application Domains (TDAD).
As I mentioned in earlier posts, Interval Arithmetic is used in several
rather different application domains, and if the standard does not deal
with this explicitly (I suppose I should formalize a motion on this),
we will always run into trouble by chasing conflicting goals.
One domain of application is operating with uncertain numbers, where an
interval represents a single numeric value with bounded uncertainty.
In this domain MidRad and InfSup are logically interchangeable, though
conversion between the two may increase uncertainty, sometimes by a lot.
The general property of such intervals is that they are always bounded
(given that we operate in R and not R*, per Motion 3), and the width
is small, either absolutely or relatively.
A totally different domain is that of intervals representing ranges of
different, individually-precise, numeric values, where that range may
be unbounded on one or both sides. InfSup is the only flavour that
can handle this domain, and semibounded intervals can only be converted
to totally-unbounded MidRad from, i.e. Entire. Branch-and-Bound and
equation solvers fall into this domain.
It should be noted that the discussions about different ways to deal
with domain violations (ignore or flag/NaI), and hence the entire
topic of decorated intervals, are applicable only to he second domain.
The only decoration/NaI that seems applicable to the first domain is
the Single-NaI proposed by Motion 7: Invalid construction.
This suggests that both Motion 7 and the new Motion 8 might have to
be re-evaluated in a context where the two application domains are
formally distinguished.
A large part of past discussions may have suffered from arguments that
had only ONE of the two domains in mind, triggering disagreement from
those who had the OTHER domain in mind!
Michel.
---Sent: 2009-09-17 08:51:45 UTC