Re: A proposal for motion 5 "Arithmetic operations for intervals"
Bo Einarsson wrote:
I submit the document "Arithmetic operations for intervals" written
by Ulrich Kulisch as a formal motion (motion 5) to be voted upon.
The document gives the definition of the arithmetic operations for
intervals in a way that is simple to read, simple to understand, and
simple to implement.
Simple???
It is short and understandable and to the point.
No. The proposal is not short, but 4 pages long, far to long
for its contents.
Compare the complexity of Kulisch's definition with the simplicity
of that of the Vienna Proposal, which handles all that needs to be
said about the forward mode of all unary and binary operations in
two simple formulas taking less than half a page:
3.9. Unary arithmetic operations on intervals
For each (partial) unary operation <phi> from Table 3.8,
there is a unary forward interval operation <phi>Hull defined by
<phi>Hull(xx) = convex hull of the set of <phi>(x) with x in xx
such that <phi>(x) is defined and finite,
3.11. Binary arithmetic operations on intervals
For each (partial) binary operation <circ> from Table 3.10, there
should be a binary forward interval operation <circ>Hull defined by
<circ>Hull(xx,yy) = xx <circ>Hull yy
= convex hull of the set of x <circ> y
with x in xx, y in yy, such that
x <circ> y is defined and finite.
No more is needed to fully define the forward mode, in the way most
useful for evaluating bounds for the range of arbitrary arithmertic
expressions in the tightest way possible without any analysis of
the function defined by the expression.
The proposal is neither clearly understandable, nor to the
point, and not even formally sound, so that its adoption would
have to be partially reversed later:
1. A literal implementation would be no good. Implementing it as
it stands leads to undefined behavior, e.g., for [1,1]/[0,1].
2. The definition enforces case distinctions for multiplication where
none were needed if one computed it as the hull of the products of
the four end points. This freedom should be left to the implementor.
3. Divisions such as [1,2]/[-1,1] are considered to be multi-valued,
which apparently lead to an exponential number of possible values in
expressions containing many divisions, such as continued fractions
with interval coefficients. The proposal _requires_ an explicit
invocation of a user-defined routine to handle this case,
which slows down _any_ implementation.
4. Having to write [a,b] for bounded intervals only but [a,inf), etc.
for unbounded intervals makes many table entries invalid, if one
of the computed bounds overflows under directed rounding,
resulting in an undefined [a,inf] or [-inf,b].
Moreover, it requires a separate discussion of unbounded intervals
as arguments, thus needlessly complication the exposition.
5. Arithmetic operations like unary minus, abs, square, sqrt, etc.
are not covered. But some issues like the treatment of undefined
values of the real oeration affect these as well, and hence must
be decided _before_ fixing what happens to special cases.
6. The set of floating-point numbers cannot be regarded as a subset
of R, since +0 and -0 are distinct floating-point numbers.
Thus already the formal setting (line 3 of the proposal) is faulty.
7. No symbolic notation for the set of real closed intervals is better
than a completely artificial one that puts parentheses around the
symbol for the set of real, closed and bounded intervals.
Elsewhere in mathematics, (X) is the same object as X if both have
a meaning.
One should not decide upon specific formulas to implement in specific
instances, before some general design decisions are not taken. For
these will affect _all_ operations, not only +,-,*,/.
It is very important, I think, that the following questions
- How to handle undefined real operations?
- allow/require mid-rad?
- allow/require nonstandard intervals?
- allow/require modal intervals?
are settled first.
Separate motions on these (The first three could even be handled
in parallel) can be stated in few words, simple to read, simple
to understand, short, to the point, and without any ambiguity,
and pave the way for a solid foundation of the whole standard.
Thus, should the motion proposed above reach decision stage,
I strongly recommend to vote with No.
Arnold Neumaier