Re: midpoint
On 2012-03-07 16:00:12 +0100, Ulrich Kulisch wrote:
> 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, closed 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.
A standard could say, with different meanings, e.g. in C:
* implementation-defined (the implementation must document the choice),
* undefined (everything can happen, e.g. a crash),
* unspecified (several behaviors are allowed, e.g. returning an
arbitrary value, without needing to document which one),
> 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.
One question would be: If you have an undefined result at Level 1,
what should the Level 2 result be? One of the above possibilities
or some specified value? In the latter case, NaN would be the most
obvious choice. Of course, you may also want to avoid any undefined
result at Level 1.
> 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'm not sure whether it should be in the standard. But the fact that
one can consider that the midpoint does not have much sense on some
particular intervals should not be a reason to drop the midpoint. You
could say the same thing for sin() / cos() / tan() in IEEE 754, which
often do not make much sense on large arguments; they still are very
useful in small domains like [-pi,pi].
> 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,
or sqrt([-2,-1])
> 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.
Something like a signal? However, if it is not trapped and correctly
handled, the consequences can be bad (isn't it more or less what
happened with Ariane 5?). I think that things are more complicated
nowadays with multithreaded/parallel applications. And signals do not
fit well with functional languages. So, for some applications, this
would mean a crash. What is important is that "incorrect" computations
can be detected at the end.
> 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.
See above. I think at least unbounded intervals are necessary because
they really correspond to correct computations at Level 1 and can be
useful in practice. The Empty set is also well-defined at Level 1, can
can occur due do rounding errors and/or hull operations and splitting,
without being an error. It can also be useful in practice.
And let's recall that the support of such intervals has been decided a
long time ago. Only the interval -> point functions are new.
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)