Re: Draft Level 2, in time for Novosibirsk
On 2012-09-21 16:32:15 +0100, John Pryce wrote:
> Following the passing of Motion 36 I have been working further on
> the (set-based) draft standard text.
>
> I discussed it with a subgroup of people -- Vincent Lefevre, Michel
> Hack and Siegfried Rump being the most active over the last three
> weeks and making many substantial comments. I sent them a draft
> about a week ago, asking them to suggest final edits before the
> Novosibirsk meeting. I have not had any, so I now copy that draft to
> everyone without change.
I didn't have the time, but here are my comments now:
§8.1, 3rd line: missing period after footnote.
§8.3, 2nd paragraph, 2nd line: "five basic types" -> five basic formats.
§8.3, last sentence (top of page 39): a 754-conforming implementation
requires *all* supported types to be 754-conforming. I'm OK with that,
but in a private discussion, Michel Hack raised the question, with an
example where a C implementation can implement "long double" with a
double-double arithmetic (PowerPC ABI coming from AIX), thus *not*
754-conforming. This could be discussed...
§8.10, "widen(x)" formula (page 41): missing closing bracket "]".
§8.10, note about "accurate" (page 42): as also mentioned by Michel Hack
in a private discussion, the terms "second widen()" and "first widen()"
are ambiguous. Michel recommends "inner" / "outer".
§8.11.5 (page 43): the sentence about cancelMinus(x,y) returning Entire
should be moved to the Level 1 text, IMHO, because this is a Level 1
property.
Table 9 (page 44): What is the rationale for the accuracy requirements
of the elementary functions? In particular, I don't understand why
tightest is required for exp, but not for sinh, cosh and tanh.
§8.11.7, line 3: I don't understand what "at user level" means (and
the opposite, i.e. what is not "at user level").
§8.11.7, just before "nums2interval" (page 45): About false positives,
would there be a decoration? Or would a possible false positive be
signaled by not setting the "defined" decoration? This should be
discussed when decorations are reintroduced, but a note could be
added now about this point.
§8.11.7, nums2interval, 1st item, line 2, about mixed formats:
"is possible" is ambiguous. Is it possible for the implementation?
For the user? I suppose that it is the former, and the standard
should say "The implementation may..." ("may" is the conventional
word in standards for a possibility).
§8.11.7, nums2interval, 2nd item, 2nd sentence, about the format
compatibility with T, I would add a requirement: "This format SHALL be
compatible with T if T is an inf-sup type", so that one can construct
any interval of T (in practice, the parent format of T would typically
be the chosen format).
§8.11.7, nums2interval, 4th item (l = u = +inf or -inf): I strongly
disagree! If directed rounding is used in a previous computation with
a numeric format, this case cannot be obtained. Ditto for anything
equivalent, such as rounding to nearest with the computation of an
error bound (which would be infinite here). Otherwise there is no
guarantee that the interval would contain the expected result. So,
some form of error (NaI...) would be the most reliable choice. What
is proposed here is dangerous, even in simple cases. For instance,
take x = number a bit larger than sqrt(HUGEPOS). The user can obtain
l = u = +inf because he has done something like sqrt(x*x); thus he
would obtain [HUGEPOS,+inf] while the constructed interval should
have contained a number close to sqrt(HUGEPOS). It is bad to hide
consequences of overflow like this one.
§8.11.8, wid(x): In the formula, which "rad" is it? The Level 1 one or
the Level 2 one?
--
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)