Re: Motion 8: Exception Handling for Interval Arithmetic
Nate and Arnold,
Well proposed.
Is it the intent that eventually decorations will be defined in the standard, or are decorations application-defined?
I think of situations in which I'd like to track open/closed for each endpoint, in part to avoid evaluation at known singular endpoints.
George
On 9/16/09 12:07 PM, "Arnold Neumaier" <Arnold.Neumaier@xxxxxxxxxxxx> wrote:
Nate Hayes wrote:
> I submit the document "Exception Handling for Interval Arithmetic" as a
> formal motion (motion 8) to be voted upon.
>
> The document presents a general framework for exception handling. It
> uniformly accomodates all arithmetic and nonarithmetic exceptions that are
> relevant for interval arithmetic and its applications. It eliminates the
> need for separate global sticky flags, and integrates non-intervals (NaI),
> without introducing any overhead for users who don't make use of exceptions.
... and without introducing any overhead in any portion of a program
that does not make use of exceptions. This means that the cost of
processing exceptions is quite small in most applications.
The text of Motion 8 was created over the last eight days in daily
exchanges between Nate Hayes and myself, until we agreed on its
sufficient functionality, its formal correctness, and its practical
efficiency. (As you may have noticed in earlier discussions,
the two of us do not agree until we really agree.)
I consider Motion 8 to be a significant improvement over the exception
handling as proposed in the Vienna proposal, and strongly recommend
acceptance of Motion 8 (perhaps after small changes that will come
up during the discussion period).
Since decorations naturally handle the functionality of NaI
with or without payload, this motion would be in tension with
an affirmative vote on Motion 7 regarding NaI: With both Motion 7
and Motion 8 passed, we would have decorations and in addition a
then useless single NaI signifying an invalid interval.
As George Corliss reported earlier today, the current tally on
Motion 7 is ``Yes: 13, No: 14, of 71 voting members''. I regard
this as an indication that the single NaI was not sufficiently
discussed in its consequences to make it uncontroversial.
Thus Motion 7 appears to have been premature.
I therefore recommend that Motion 7 be withdrawn. Until this happens,
I recommend that the supporters of Motion 8 (Exceptions) vote No
on Motion 7 (NaI) or, if they already voted, change their vote
to No (perhaps with reference to Motion 8). This should be done
by September 21 to take effect.
Note that I am not a voting member and consider myself just as a
scientific advisor for the whole discussion process.
Arnold Neumaier