Re: Re-submission of motion 5: multiple-format arithmetic.
John Pryce wrote:
> Some issues left open by this motion:
> - The existence and functionality of NaI. I think: the interval
> functions
> that are the subject of this motion should never give a NaI result
> from
> non-NaI arguments; they should always give NaI if any argument is
> NaI;
> only constructors (maybe other related functions) should create NaI
> (when given nonsense input); some interval mappings may be allowed
> to destroy NaI (e.g maybe hull(xx, NaI) should return xx).
> But that's my personal view of what NaI "is for". I know other folk
> have different views.
Yes.
I support your view of NaI, in general, but also believe users should be
able to obtain NaI as result of some interval operation that is not
well-defined.
> - It is left open what exceptional action an implementation may make
> available, on evaluating ff(ss) when ff is an extension of
> a point function f, and ss is not a subset of the domain of f.
> However, my approach implies such exceptional action must be _in
> addition_ to returning an interval value (which might be ignored,
> by the user or at the language level). Again, I suspect this is
> controversial.
If the only way to obtain NaI for an invalid operation, such as division by
interval containing zero, is by traps or flags, this is what I object to.
This implication is still main reason I don't support this motion.
> M3. An implementation shall be called 754-conforming if: (i) its
> underlying system is 754-conforming (Definition D1) and the
> implementation supports an interval format for each supported
> floating-point format; or (ii) it is functionally indistinguishable
> from case (i).
> [Note. The reason for case (ii) is that it seems feasible to code an
> efficient 754-conforming interval system using only a subset of 754
> floating point features. If so, a floating point system that behaves
> differently from 754 outside this subset can be used. For example, a
> system that has only one kind of zero.]
Keep in mind the rule 0*Inf=0 is not 754-conforming. But there are proposals
that require this.
> Motion 3 decided that the P1788 intervals comprise the closed
> connected subsets of the reals.
Right. I was wrong last time to say this was not true... I conflated
"closed" for "bounded" (I wonder why no one corrected me on this). For
example, Motion 3 allows (-oo,5], which is not bounded, but is closed. It is
a little counter-intuitive, since (-oo,5] is closed but has an "open"
endpoint. Perhaps this is a reason why Arnold likes the notation [-oo,5].
> R4. Overall Aims.
> -------------
>
> Ramon Moore's Basic Theorem of Interval Arithmetic (BTIA) is
> fundamental to interval computation. Roughly, it says that if E is an
> explicit real expression defining a real function f(x_1, ..., x_n),
> then evaluating E "in interval mode" over any interval inputs
> (xx_1, ..., xx_n) is guaranteed to give an enclosure of the range of
> f over those inputs.
Moore's theorem uses real analysis, so operations like division by interval
containing zero are undefined (NaI in modern parlance). This is different
than your motion, though.
I don't mind that the c-set extention you advocate in this motion is
included in 1788. However, the classical definitions should also be
included, in my opinion.
> The abstract objects and operations form interval level 2. To see its
> utility, ask yourself the question "How to prove the BTIA, starting
> from a procedural definition of the arithmetic operations as given,
> for instance, in the Einarsson-Kulisch position paper presently (May
> 2009) under discussion as Motion 5?"
Moore defines division by zero as undefined result, i.e., NaI. But there is
not a definition in the motion that allows this result to be obtained...
> I believe nothing in this motion and rationale hinders the
> implementation of various forms of non-standard intervals -- Kahan,
> modal, etc. -- as discussed at the end of Vienna/1.2.
I've mentioned before this is simply not true. If traps or flags are only
way to obtain NaI result from an interval operation such as 1/[-2,3], this
is hinderance to efficient modal interval implementations.
> R5.4. A "point function" is a (possibly partial) multivariate real
> function:
> that is, a mapping f from a subset D of R^n to R^m for some
> integers n >= 0,
> m > 0. (When n=0 and m=1, we have a "named real constant".)
> When not otherwise specified, a scalar function is assumed, i.e.
> m=1. If m>1,
> the function is called a vector function.
> D = D_f is the domain of f.
> To specify n, call f an "n-variable point function", or denote f as
> f(x_1, ..., x_n).
> The "range" (often called "exact range" in the literature) of f over
> an arbitrary subset ss of R^n is the set
> range(f, ss) = {f(x) | x in ss and x in D_f}.
>
> Notes.
> - Here, f is a mapping, not an expression.
> - For instance range(sqrt, [-1,1]) = [0,1]. We follow the
> convention, usual in mathematics, that when evaluating over sets,
> points outside
> D_f are simply ignored.
It is convention for c-sets, but not real analysis, classical interval
analysis, or modal intervals.
Chapter 4 of Hansen and Walster's "Global Optimization" book on the topic of
c-sets, p. 49-50, provides a good summary: "Because division by zero is
undefined for real numbers, division by intervals containing zero is
undefined in [Moore's] interval system... the containment constraint concept
must be extended to include point operations and functions that are normally
undefined in real arithmetic."
> The Kulisch-Einarsson position paper on
> the basic operations (May 09) makes the same definition.
That paper defines
{ a op b | a in A and b in B }
and mentions that division by interval containing zero is not well-defined.
This is different than what you propose.
> R6.3. An "F-interval datum", by analogy with the definition of
> floating-point
> datum in 754/3.2, is either
> - an F-interval; or
> - the abstract object NaI, "Not an Interval".
> An "interval datum" is an F-interval datum of any relevant aformat
> F.
> Note.
> At this level we consider there is just one NaI for all aformats;
> at the
> representation level this will probably not be the case.
I agree.
As it stands, I'm not ready to vote "yes" to this motion. As I've mentioned
in the past, I believe a more balanced solution is to provide two sets of
operations:
op1: { x op y | x in X and y in Y }
op2: { x op y | x in X and y in Y and x op y is defined }
The first is Moore's classical definition and leads to NaI if x op y is not
well-defined (this is the definition compatible with modal intervals). The
second is c-set extention which returns {empty} for those values, instead
(this is what your motion provides).
Nate