Re: midpoint
> Date: Wed, 07 Mar 2012 16:00:12 +0100
> From: Ulrich Kulisch <Ulrich.Kulisch@xxxxxxxxxxx>
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: midpoint
>
>
> Dear P1788 members:
>
> P1788 considers intervals of \overline{IR}, the set of closed and
> connected sets of real numbers. In mathematics the midpoint of an
> interval is well defined for elements of the set IR, the set of
> nonempty, colsed and bounded real intervals.
>
> During the last 12 months the question was discussed whether and how the
> midpoint should be defined for elements of the set \overline{IR}\IR. I
> have great sympathy with Dan's resistance of returning NaN in these
> cases. First of all, this answer may be wrong. Think of an interval of
> IR where the lower and the upper bound are greater than Fmax. This
> interval has a real number as its midpoint. It is just not compubable
> within the given floating-point system. An answer like "not calculable"
> or perhaps "indefinite" (a native English speaking colleague may find a
> better denotation) seems to me being more appropriate. Second:
> Arithmetic of \overline{IR} is strictly based on mathematical grounds
> and it is free of exceptions. So elements of IEEE 754 like NaN which are
> more of a speculative nature should not unnecessarily be introduced into
> P1788.
>
> Now, the question remains, how should the midpoint of elements of
> \overline{IR}\IR be defined? I think there is no need at all defining it
> within P1788. We also don't give a definition of the logarithm for
> negative numbers. If a user has a reasonable application where he needs
> a splitting point for an unbounded interval or the empty set we should
> let him the freedom defining it in a way that is appropriate for his
> application. We don't need this definition in the standard.
>
> I still remember the old days of interval arithmetic (the 1970s).
> Arithmetic operations were just defined for closed and bounded real
> intervals (of IR). No functions or operations were defined for the empty
> set which considerably simplified the implementation of interval
> arithmetic. Of course, the empty set could occur in a computation as
> result of an intersection, for instance, and its appearance could be
> used to continue computing with another branch of an algorithm. In
> general, however, the empty set meant an end of this computation.
>
> Then IEEE 754 arithmetic brought the strategy to continue computing even
> with exceptional numbers like -oo, +oo, -0, +0, or NaNs and we all got
> used to this strategy. I don't see why we should introduce this strategy
> into P1788.
>
> Best wishes
> Ulrich
>
Thank you, Ulrich.
For the most part I agree with these sentiments.
Especially the principles of avoiding things like
NaNs & infinities as much as possible. My own
experience is, of course, different than yours
but these things have caused trouble in my life
as well. One finds that infinities lead to NaNs
& NaNs infect a calculation with meaninglessness.
I believe we should make a clear conceptual
distinction between a function defined among the
Reals & its coercion into the floating-point answer
we are forced to return. If we are careful, the
requirement to express an answer in some finite
number system need not compromise the quality or
utility of the original function. And criticisms
of the coercion need not tar the definition of the
function.
Our results may come from \overline{IR} or
intervals of \overline{IR}, but we must return
them to our users in \overline{IF} or intervals
of \overline{IF} for some necessarily finite
floating-point number system F.
Thus, although things like midpoint may be easily
well defined among the Reals, we have to ask
ourselves: What is the best representation of
these results within our finite floating-point
systems & the intervals we construct out of them?
And, in this context, the word "best" should not
be interpreted as "closest" but as "most useful".
So: What is the most useful answer?
In general, this will be a matter of some opinion
& debate (obvious from the length of this discussion
already). But I think your principle of avoiding
NaNs & infinities in so far as is possible is a good
place to start.
I believe that infinities can largely be avoided &
that NaNs can be avoided altogether. But I must
admit I am not quite sure about the NaNs.
Avoiding either involves making some compromise in
the name of utility. And sometimes an arbitrary
but otherwise harmless choice may be the only way.
So one must ask oneself if such compromises & such
choices are a lesser evil than the introduction of
errors implied by NaNs & infinities. I believe
they can be if we are careful. It is obvious that
is not a universal belief.
But I believe we should try.
We have the possibility of building a better, cleaner
arithmetic than was possible in 754. (The existence
of the Empty set is one reason.) In particular, we
should not let the choices we had to make in 754 hold
us back from that goal.
As always, IMHO...
Dan