comments on the comments (was: [IEEE 1788]: Post-ballot comment resolution)
On 2015-02-05 10:11:16 -0600, Ralph Baker Kearfott wrote:
> I have attached the comment resolution spreadsheet, in which
> tentative dispositions (column T) and responses (column U)
> have been inserted. (The responses, mostly due to John,
> will need to be formalized and made more succinct, but
> they nonetheless give suggestions.) As editor, John had
> questions about the following comment numbers (where the
> comment numbers appear in column C and the the actual comments
> appear in column P).
I7: I agree with Michel: "can always" ("always" after the auxiliary)
is the rule. It seems that "always can" is not completely incorrect
and can be used to emphasize, but it is much less common, and here
there is no need to emphasize.
I11, I20: "by an if ... else ... construct" is unclear in the context
of interval arithmetic. How would one do this? The most intuitive way
is to use intersection and convexHull, as in the example that follows.
I17: Since a sentence about extension is added as a clarification,
I'm wondering whether a common value is allowed as an extension or
only non-common values are allowed.
I37: "upper bound oo" -> "upper bound -oo"
I54: The proposed correction is still difficult to understand. What
is the subject of "record"? What is the complement (which shouldn't
be separated from the verb by "while ...")? I think that the sentence
should just be "A decorated interval is an ordinary interval tagged
with a few bits that encode the decoration." as the thing about
"record" is already said in the previous sentence "In this standard,
such events are recorded locally by decorations." The shortened
sentence can be followed by a new sentence giving an example.
I59: Perhaps add that a decoration value denotes here some exceptional
condition.
I63: http or https? (I get only https URL's with Wikipedia, but this
may due to my config.)
I74: "NOTE---Implementations should provide an operation that returns
mid(x) and rad(x) simultaneously." I thought that the note was
intentional. I don't think there is any reason to have a "should"
here in the standard. Implementations may provide other functions
such as midrad(x), but this is out of the scope of the standard.
If such a function were so useful, it should have been specified
to ensure portability of the user code on various implementations.
I82: I don't understand the change.
I83: No answers. In any case, there is an extra closing parenthesis.
I86: I suppose that type conversion between flavors is also implicitly
unspecified.
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)