My comments on §12.12 (Motions 56 and 57)
Here are my comments for Motions 56 and 57.
§12.12: rephrase paragraph 1?
§12.12.3 [case expressions / conditional operation]: For true
functional languages, the specification is clear. But most languages
have expressions with possible side effects, and it is not clear
whether unused arguments may or must be ignored. More generally,
P1788 must be clear on whether optimizations are allowed to discard
P1788 related side effects[*] (that is, exceptions defined in P1788).
Here with "case":
* If case(c,g,h) returns h, is the implementation allowed to evaluate g,
with its possible side effects (e.g. exceptions)?
* Similarly, is case([1,2]_com,G,h_com), which returns h_com, regarded
as a common evaluation?
[*] An example could be: convexHull(Entire,X), where X is an expression
whose evaluation can trigger an exception.
§12.12.4, last paragraph: remove "while"?
§12.12.8, first sentence: "Both numsToInterval, and textToInterval when
its input is a literal of inf-sup form, involve testing [...]"
The two commas should be removed.
§12.12.8, 2 paragraphs below: In "Evaluating b as 0 when the true value
is 1", replace "true" by "correct".
§12.12.8, second paragraph of the note: In the sentence "in C, if
long double is supported and has more precision than double, default
behavior might be to round long double inputs l and u to double[...]",
one has the impression that "is supported" means "is supported by the
C implementation" because of the immediate context ("in C" and "has
more precision than double"). Is this what this is meant?
- If yes, then it is redundant, since the long double type is part of
the C standard and is supported by all the major compilers (CompCert
is the only exception I'm aware of, and this may change in the future).
- If no, then the text should be e.g. "in C, if long double is
supported by the implementation of this standard and [...]".
§12.12.8, first paragraph of page 57:
* In "If T is a 754-conforming type and l and u are of 754 formats
with the same radix as T, the second case cannot arise", I would
replace "the second case cannot arise" by "case (b) shall not arise"
(I can see that the "the second case" -> "case (b)" part has already
been done in the trunk).
* The last sentence of this paragraph "For other cases, the tightness
of the result is implementation-defined." should be replaced by
"Otherwise the tightness of the result [...]" to avoid ambiguity,
since "case" has just been used in another context. But there's
another "Otherwise" in the next paragraph, and one is lost. I would
rewrite these 4 paragraphs from "The constructor call succeeds" to
"Otherwise the call fails and the result is Empty." in the following
way:
--------
The constructor call succeeds if (a) the implementation determines
that the call has a Level 1 value x, see §10.6.9, or (b) it cannot
determine whether a Level 1 value exists, see the discussion at the
start of this subclause.
In case (a) [...] containing l and u. [Modified in the trunk]
Otherwise the call fails and the result is Empty.
If T is a 754-conforming type and l and u are of 754 formats with the
same radix as T, case (b) shall not arise, and the result in case (a)
shall be the T-hull of x; in particular, if x is an exact T-interval,
the result is x. Otherwise the tightness of the result is
implementation-defined and the conditions under which case (b) might
occur shall be documented.
--------
The first 3 paragraphs above now give general rules and the 4th one
requires additional quality constraints. The corresponding .tex text
(starting with the current one in the trunk) would be:
--------
The constructor call succeeds if (a) the implementation determines that the call has a Level 1 value $\~x$, see \ssrf{lvl1reqdconstructors}, or (b) it cannot determine whether a Level 1 value exists, see the discussion at the start of this subclause.
Case (a) is that neither $l$ nor $u$ is \nan, and the exact extended-real values they denote---also called $l$ and $u$ for brevity---are known to satisfy $l\le u$, $l<\pinf$, $u>\ninf$. In this case the result shall be a $\T$-interval containing $\~x$.
In case (b) the result shall be a $\T$-interval containing $l$ and $u$.
Otherwise the call fails, and the result is \Emp.
If $\T$ is a 754-conforming type and $l$ and $u$ are of 754 formats with the same radix as $\T$, case (b) shall not arise, and the result in case (a) shall be the $\T$-hull of $\~x$; in particular, if $\~x$ is an exact $\T$-interval, the result is $\~x$. Otherwise the tightness of the result is \Idefd and the conditions under which case (b) might occur shall be documented.
--------
§12.12.8, about textToInterval: isn't "If T is a 754-conforming type,
this shall be the T-hull of x" too strong? This seems stronger than
correct rounding. For instance, consider [l,u] with l in decimal form
and u in hex form, both with many digits. I think this means that you
need something equivalent to a multiple-precision base 2 -> base 10 or
base 10 -> base 2 conversion (such as in GNU MPFR).
§12.12.8, Decorated interval constructors: I don't understand the
3 items, as they are written. The first one seems to overlap with
the 3rd one, though the requirements are consistent. Aren't there
only 2 cases: whether the interval literal has a decoration or not?
Whether it is of inf-sup form or not doesn't matter.
§12.12.9: The note for wid(x) "For nonempty bounded x the ratio
wid(x)/rad(x), which is always 2 at Level 1, ranges from 1 to +∞
at Level 2." is incorrect. For instance, let F be binary32, T be
an inf-sup interval type based on binary64, and xx = [x,x], where
x is not in F. Since mid(xx) is in F, it is different from x.
Thus rad(xx) > 0. However wid(x) = 0, so that wid(x)/rad(x) = 0.
§12.12.10: There should be no decoratedEqual (see my 2013-11-20 mail
on this subject). But after a discussion, it has been removed.
§12.12.13: Well, I recall that I'm personally against these operations,
which do not involve intervals at all. It should at least be noted that
the rule of the sign of an exact zero is different from the general one
of IEEE 754. In particular, sum(x) with x = 0 may change the sign of
the 0, and sum(x,y) with x = y = 0 may not have the same sign as x+y.
Moreover, IMHO, the last sentence should be removed (or changed into
an example) as the standard should not give any recommendation on the
implementation; it may give recommendations on the behavior only. For
a fixed behavior, in general (possibly with some constraints, such as
on the power consumption), the faster, the better.
--
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)