Motion P1788/M007.01_NaI No
I vote No for NaI.
Introducing NaI(s) has a cost in the implementation of
basic operations (+, *) due to the propagation rules.
I can see how to propagate the empty set at zero cost
(if implemented as (NaN, NaN)), but I fail to see how
to generalize it for NaI : neither with NaN payloads
(how do you combine them?), nor with a non-NaN as second
member (needs fixups for e.g. the unary minus operator).
I think it is very important that the IA standard be
efficiently implementable with current hardware,
because it is through software implementations that it
has a chance of being adopted first, to later have a chance
of seeing hardware support appear. So I would need a much
stronger rationale to support NaI(s) at this stage.
The alternatives mentioned for reporting "errors" appear
to be enough for me now (variants of the functions
returning more information besides an interval, "flags"...).
Moreover, on the more "philosophical" ground, I think the
reasons for introducing NaNs in FP do not hold for IA,
as the IA system is more naturally closed. Introducing
a cost in all interval operations mostly to handle cases
coming from FP->IA conversions seems like a wrong trade-off
to me.
--
Sylvain Pion
INRIA Sophia-Antipolis
Geometrica Project-Team
CGAL, http://cgal.org/