Re: A proposal for motion 5 "Arithmetic operations for intervals"
Arnold Neumaier schrieb:
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.
Simplicity should not be measured by a number of letters. There is hardly
any way to define arithmetic for floating-point intervals simpler and
shorter than by the few formulas on page 4 of the proposal. These formulas
are the standard definition of arithmetic in other interval spaces also,
like interval matrices, complex intervals, complex interval matrices,
matrix vector operations, and so on. (This implicitly even requires an
exact dot product.) All operations defined that way produce a result that
is ‘tightest’. In any interval space the neutral element of multiplication
e has a unique additive inverse denoted by –e. With it for an interval x
the minus operator is defined by –x := (-e)*x. Interval subtraction is
defined by x – y := x + (-y).
An implementer of interval arithmetic will not be satisfied with a definition.
He will ask for explicit formulas and a standard should provide these. Their
derivation is not trivial, see 1. below:
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.
The notation [x, y) for an interval where the bound y is not an element
is quite
usual in mathemeics. The notation [x, y] may occasionally cause confusion.
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.
As the title of the proposal says it just considers arithmetic
operations for intervals.
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.
Interval arithmetic and floating-point arithmetic are different topics.
In interval
arithmetic -0, +0, and NaN should not be considered to be floating-point
numbers.
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.
If x is a number or a variable or an arithmetic expression it is correct
that (x) means the same.
But IR is none of these.
*IR may be a better notation. But its definition in the StandardNotation
may be misleading.
I*R is used for another set in modal arithmetic.
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.
This is a top down approach. It may be easier to reach general agreement
if the development starts with
a small kernel and builds the standard around it. The development will
be an iterative process anyhow.
Thus, should the motion proposed above reach decision stage,
I strongly recommend to vote with No.
Arnold Neumaier
Nevertheles, we are grateful for all arguments. The proposal will be
rearranged. Other duties do not allow
to do this in the three weeks timeframe. So we withdraw the motion for
the moment.
Best wishes
Ulrich and Bo