Re: comments on the comments...
On 2015-02-16 22:52:10 +0000, John Pryce wrote:
> On 10 Feb 2015, at 15:53, Vincent Lefevre <vincent@xxxxxxxxxx> wrote:
> > 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?
The more I re-read it, the more I'm confused! Before answering the
question...
First, there are two textToInterval(s) constructors: a bare one and
a decorated one. In the lines 7-9, it seems to be the bare one since
the decorated one is mentioned below, and also because of "its value
is the common bare interval x". But I'm wondering why the condition
is "If s is a valid interval literal *with decorated value x_com*
in the set-based flavor". So, if I understand correctly, despite
textToInterval(s) is here a bare interval constructor, the string s
is interpreted as a decorated interval. And I suppose that if the
decoration part is "com", then the interval part must be a common
value; and in this case, the item says that the textToInterval(s)
value is this interval part.
This is how I understand this text. Then I have several remarks.
What about strings like "[0,+Inf]_com"? Are they necessarily regarded
as invalid or is an extension allowed to regard them as valid. In
the latter case, I suppose that the decorated value [0,+Inf]_com is
forbidden, but [0,+Inf]_def could be allowed. Well, in any case,
on this example, there is no common value.
What if one has a common value at Level 1, but an overflow at Level 2?
I suppose that Clause 9.4 is a Level 1 specification, but this is not
explicit (it gives references to both Level 1 and Level 2).
What if the decorated value is [0,1]_def? Since the decoration is not
"com", one would be in the "Otherwise, it has no common value." case.
However the bare interval value would be [0,1], which is normally a
common value. This is the main problem I have with the text.
Finally, concerning the extensions, I don't think they are a problem
because s is interpreted as a decorated interval, and then I think
that the main questions are the above ones.
> > 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
^^^^^ missing article?
> the dac decoration, then f is _defined _and _continuous on its input
^^^^^^^
I would say: "then this means that f is ..." (I think that is should
be clear that it is the intent, possibly not the reality, as a user
could lie on a decoration since it is possible to set decorations).
> box, with range contained in yy. This allows a rigorous check..."
> (The _ mean that the following *letter* is underlined in the text.)
I don't think that underline should be used (since regarded as
typographically incorrect). Italic?
> > 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."
OK.
> > 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.
OK. The switch to https seems to occur automatically only when I'm
logged in on Wikipedia.
> > 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.
I'm not sure that it is always true. In any case,
* midrad() would be useful only if the user wants both mid() and
rad();
* the implementation should be able to optimize separate calls to
mid() and rad() because the user may want to use separate calls
for portability reasons (for instance, GCC can do that for
separate sin() and cos() calls, and call the glibc sincos()
function when available);
* there are many potential ways to optimize code.
> 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.
I'd favor (1). Standards should not encourage optional operations
that are just there for potential optimizations that may be done
in some other way (here midrad() doesn't bring functionality).
Anyway it is well-know that implementations can provide their own
functions.
Actually here it could be regarded as a binding thing and language
specification (since the functionality is the same), which is out
of scope of the standard.
> > I82: I don't understand the change.
> I think it means "numbers either side" should be "numbers on either side".
OK.
> > 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.)
OK.
--
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)