Motion 42: NO
I vote NO on Motion 42. Here are my comments. My vote would be changed
to YES if my comments (at least the most important ones) are taken into
account.
§5.2, paragraph 2: "no other intervals belong to all of them" to be
changed to "no other intervals belong to the set of all of them"?
§5.2, "Arithmetic operation": "an interval extension of the
corresponding point function phi". It doesn't seem to be any
interval extension, but the *natural* interval extension.
§5.3, first paragraph: If I understand correctly, the notion of
"loose" / "tight" is mainly for Level 1 and is aimed to be similar
to the notion of accuracy modes at Level 2. As specified, it seems
that any common evaluation is loose. So, concerning the definition
of "tight", "it is not loose" is not possible.
§5.5, about "sharing" for a common evaluation at Level 2: For
operations with numbers in input and/or output, the number formats
should be the same (or at least have some language-defined form of
compatibility). Now, I wonder whether this is worth mentioning.
I think that "sharing" makes sense only if one has "reproducible
interval arithmetic" (see §1.8 in Draft 6.3). Something should be
said about that. In particular, the same evaluation scheme (e.g.
ordering, contractions...) shall be used.
BTW, "rounding" (for an interval) should be defined in §3.2. I suppose
that it is regarded as a mapping of a Level 1 interval x to a Level 2
interval y containing x.
§6.1, first paragraph: I would replace "for a real-valued function" by
"for real-valued functions", and "decorated intervals [...] target the
second" by "the decoration system [...] targets the second".
§6.1, paragraph 5 ("Especially..."): it is said "f restricted to x
being continuous", but this is not the same as f being continuous
at each point of x (used for common intervals). In §8.8.2, dac uses
the latter property, contrary to com (§5.2 and §8.8.10). Is this
difference intentional? If yes, I think this should be emphasized
(here and/or later). IIRC, this point was unclear in our private
discussions (in particular when "bdc" was introduced).
§6.1, last two paragraphs: I would add "IEEE" in front of "754".
§6.2, paragraph 3: "For diagnostic use it may convey Level 3 or 4
information, e.g., how an interval is represented, or how memory is
used." would be possible only for specific intervals, in particular
not in a common evaluation (unless only one flavor is provided), as
the "com" decoration shall be used. This is a bit misleading.
§8.8.1, paragraph 2: §8.8.8 is missing.
§8.8.3: It should be made clear that NaI must not be returned if
the interval interpretation would not return an empty interval,
even in the case where the true decoration is ill (this was from
my remarks in our private discussion). For instance, even though
the implementation may return NaI for sqrt(-1-x^2) for any x, it
must not return NaI for sqrt(-1-x*x) where x = [-1,1], because
at Level 1: x*x = [-1,1], -1-x*x = [-2,0], sqrt(-1-x*x) = [0,0].
The reason to decorrelate the variables is that the implementation
doesn't know what a variable means exactly (this may be specified
by the language, but the exact meaning may also be left to the end
user). By default, the implementation should behave in a safe way.
Indeed, a variable may represent several mathematical values. For
instance, a math problem may have its own x_i's, where the index i
can take a huge number of values, and it would be inefficient (or
even impossible) to take care of all these different x_i's in a
program. So, the user may choose to represent each x_i by a single
interval variable x such that x_i is in x for all i.
§8.8.4, paragraph 1: is "implementations shall not produce them."
for arithmetic operations (implied by the beginning of the paragraph)
only or more generally for all operations (including constructors)?
This is ambiguous. There's also the question of what is specified if
the user produces a forbidden combination via Level 3 or 4 (e.g. via
a union in C). I don't think that implementations shall support such
combinations in input.
§8.8.4, paragraph 2: the relation between this paragraph for y_ill
with nonempty y and §8.8.3 is not clear.
§8.8.7: With the rule given on NaI, code ending with something like
(e.g. for piecewise functions):
y = convexHull(u_du,v_dv)
dy = dx
or
y_dy = convexHullDec(u_du,v_dv)
may be wrong if NaI can occur in intermediate results! There should
be a note with some warning. I suspect problems may occur in practice
with parameterized intervals (a function may become nowhere defined
for some values of the parameter). This is a problem with specific
rules for NaI: here a NaI can be produced by evaluating a function
that is never defined, but having such an operation on intervals is
not necessarily a user error.
§8.8.9, Example (i): Replace "2½" by "2+½"? I don't know whether "2½"
is a common notation. However it may be ambiguous.
§8.8.10, definition of "com": about "and the computed interval f(x)
is bounded", I would add (perhaps in the notes, at least more clearly
than in the third note) that this condition is needed only at Level 2
(since all the intervals we consider in the standard are closed), and
an unbounded interval is necessarily a consequence of an overflow.
§8.8.10, "Each arithmetic operation gives com as its local decoration
if the conditions (30) are satisfied.", just after (31): is this a
"shall" or a "should"? And I would add "in" or "of" before "(30)",
since (30) seems to be the whole table rather than the conditions.
§8.8.10, "The propagation rule [...] is" (next line): replace "rule
[...] is" by "rules [...] are" (the plural is used in the notes and
it looks better to me)?
§8.8.11: Since decorations trv, emp, ill and dac are mentioned,
I suppose that compressed arithmetic is specified only for the
set-based flavor (and the common one). This should be said.
--
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)