Re: comments on the comments...
P1788
Below are my suggestions on responding to Vincent's comments.
John Pryce
On 10 Feb 2015, at 15:53, Vincent Lefevre <vincent@xxxxxxxxxx> wrote:
> 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.
OK, let's use "can always".
> 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.
The sentence containing "by an if ... else ... construct" seems to shed confusion and not illumination, so I suggest just delete it.
There are situations where an "if" seems necessary, e.g. suppose in the example given, the function joins continuously at one region boundary but not the other, as e.g. if it has the current definition for x <= 2, but equals f_3(x) = x for x > 2.
Then I think the bare interval value yy is best done as currently, but using f_3 to evaluate ww. But for the decoration the simplest code seems to be "if xx contains 2 and also points >2 then dy = min(dx,def), else dy=dx". But such an example seems "over the top" in context and would take too long to explain.
> 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.
Have you any examples in mind? Have you an opinion on what should be expicitly allowed, or forbidden?
A possible example is a Rump "Interval arithmetic over finitely many endpoints" flavor based on IEEE binary64. It could use a model that provides intervals T=(0,Tiny) and H=(Huge,oo) as endpoints (also -T, -H), as well as singleton binary64 endpoints.
- So e.g. in Rump notation [[T,3]] represents (meaning its "interval range" equals) the half-open interval (0,3]. That's a non-common interval, and I suppose an implementation might need
numsToInterval(l,u)
to accept a special value for l, of binary64 type, that means T.
- Also, a Rump model might have "exact \pi" as one of its endpoints. Again, numsToInterval(l,u) might need some special binary64 value PI reserved to mean \pi. Now the call numsToInterval(0,PI) constructs the exact interval [0,\pi], which is common. But IMO this is an "extension" of the normal spec of numsToInterval().
Is that the sort of thing you have in mind?
> I37: "upper bound oo" -> "upper bound -oo"
Ah yes, the spreadsheet "Disposition Detail" has a typo. It's OK in the 1788 text.
> 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.
Well, it looked correct and clear to me, but obviously not to some people. How about revising the paragraph thus:
"A decorated interval is an ordinary interval tagged with a few bits that encode the decoration. A small number of decorations is provided, designed for efficient propagation of such property information. For instance, if evaluation outputs an interval yy with the dac decoration, then f is _defined _and _continuous on its input box, with range contained in yy. This allows a rigorous check..."
(The _ mean that the following *letter* is underlined in the text.)
> I59: Perhaps add that a decoration value denotes here some exceptional
> condition.
Good point. I suggest change
"They are for certain applications where one needs to record either an interval value or a decoration value but never both at once."
to
"They are for certain applications where a decoration value denotes some exceptional condition, and one needs to record either an interval value or a decoration value but never both at once."
> I63: http or https? (I get only https URL's with Wikipedia, but this
> may due to my config.)
Firefox on my Mac makes it invisible in the address bar, but when I copy, I get http. I'll leave it http.
> 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.
Hmm. What you say is true.
a. The best place to say that a certain operation should/shall be
provided is surely at Level 1.
b. But the main reason for having a midrad(xx) is a Level 2 one:
that it seems the simplest way to implement r = rad(xx) is to
find m = mid(xx) first, then r is the smallest radius that gives
containment, see 12.12.8.
Possible things we could do:
(1) Just delete that sentence.
(2) Keep it as a NOTE in its present location, but change "should"
to "may", and add a phrase to explain why this might be useful,
point b above.
(3) Make it main text in its present location, and change "should"
to "shall". That has knock-on effects elsewhere.
(4) Keep it as a NOTE, move it to 12.12.8 (p62 line 11), change
"should" to "may", and add a phrase as in (2).
I don't much like (3) but am undecided between the others.
Opinions please.
> I82: I don't understand the change.
I think it means "numbers either side" should be "numbers on either side".
> I83: No answers. In any case, there is an extra closing parenthesis.
Strange, I don't remember this one. Had it got squashed to zero height, like column O got squashed?
It should say "...m is a decimal number literal of form a) in 12.11.2..."
(A pair of parentheses () removed, to follow IEEE style.)
> I86: I suppose that type conversion between flavors is also implicitly
> unspecified.
Yes. As I recall, it was discussed but we decided to leave it unspecified.