Motion P1788/M007.01_NaI NO
I vote NO on Motion 7 -- Single NAI -- with some regret.
The regret is that I believe the particular NaI that the motion
proposes -- as a possible outcome of interval constructors -- is,
in my opinion, absolutely essential. I would not want to rely
solely on global flags or exceptions, and returning plain Empty
(which is fine from an ontological point of view) just does not
satisfy the demands of programming.
However, I firmly believe that we should not repeat the mistake
of 754 and leave the interpretation of NaN-like objects mostly
undefined. This is not a problem with Motion 7, whose NaI is
perfectly well-defined. The discussions about how to handle
domain errors has me convinced however that we need other kinds
of NaI as well, with different propagation rules. This calls
for a set of several well-defined NaIs, in fact also for several
evaluation rules -- all to be dealt with by future motions.
Now, it is true that decorated intervals can do it all: carry
local information as well as an interval result (most likely
Empty if the decoration is equivalent to one of the NaI types
that may be needed). But surely we don't want to burden every
application with the full cost of decorated intervals, which
(when the interval part is non-Empty) have to participate fully
in all operations, whereas a NaI alone would propagate without
further computation. This becomes especially critical when
going beyond simple operations to working with library functions.
So depending on decorated intervals alone would be as if 754
had decided that Binary128 was sufficient, as it can do anything
that Binary32 or Binary64 would have been used for. My point is
that programmers need to be able to choose tools appropriate to
the task at hand, and the job of a standard is to make a suitable
set of tools available in, well, a standard manner.
Michel.
---Sent: 2009-09-08 22:33:53 UTC