M0008.02_Exception_Handling NO
I vote NO for motion M0008.02.
It's obviously important to know about discontinuities and
other exceptional events in interval computations, but I would
prefer to see this addressed in the standard by introducing
variants of functions which return some additional information
separately, and leave the propagation rules outside of the
standard completely.
The motion text is too imprecise for me at this stage to agree
on the particular direction it proposes. For example, not
specifying which properties are considered can change the
deal : some properties could be altered by an addition
operation, while some others can only be altered by more
complex operations. And if costly operations (say,
division, sqrt, or worse) are the only ones concerned, then we
could consider that the cost of a separate treatment/propagation
of the additional information is amortized, and so
folding this task inside the main decorated-interval
operation would not be needed.
My goal here is to make it *easy* for hardware vendors
to support the critical interval operations. That is,
it should be a relative no-brainer to extend an existing
SIMD unit to support the interval functions of this standard.
Concretely, what I would propose instead would be to have
functions like sqrt(x) which return an interval y, together
with the "exceptional" information in a separate (integer) register i.
This should vectorize without problem, with an accompanying
integer vector-register.
Then if you need to propagate or combine the information
one way or another, you do it by considering the information
registers.
Of course, at the programming language level, one can
encapsulate all the propagation rules the way the motion says
(or rather, says a later motion would specify).
But I think that this part should not be specified in this standard.
This is more a topic for the -er subgroup anyway.
Some other remarks on the motion :
- "trit" is not a very good name to me for {true, false, possibly}
since it does not carry a relation to ternary logic specifically.
tribool might be better (as in boost::tribool for those who know
about this class). Maybe 4 values might find more use and still
fit in 2 bits. The C++ interval proposal comes with a bool_set class
representing {true, false, true_or_false, neither_true_nor_false}.
(I don't claim this name is better, for the 4th value can be useful)
- I can't make sense of the rationale paragraph for limiting
the trits to 5 since it only considers bare decorations.
- In my experience using IA for controlling rounding error propagation,
I never needed those exceptions. However, there is one place where
I use C++ exceptions, which is when comparing intervals. Strangely,
this does not seem to be covered by the motion, although the text
is fuzzy enough that we could interpret it as if it did (?).
Note : the C++ interval proposal makes the comparison operators return
a bool_set object mentioned above.
--
Sylvain Pion
INRIA Sophia-Antipolis
Geometrica Project-Team
CGAL, http://cgal.org/