| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Vincent,
Here is the subsection on Common interval literals with most of your comments applied.
Thank you for them.
Additions and changes are in red color.
Deletions are in red color in square brackets.
Here are some comments returned:
> Line 27: "The value of a common interval in a flavor is the same as
> its common value, modulo the embedding map." is unclear.
Changed to "The value of a commom interval LITERAL in ..."
"modulo embdding map" were introduced in 7.2.
> Why does §9.5 only handle common intervals? For textToInterval(s),
> the rules should be the same for non-common intervals. For instance,
> if s is a valid bare interval literal denoting the interval x, then
> textToInterval(s) has value x, whether x is common or not. Everything
> about the extension is in the grammar that defines the literals.
I didn't change it now. Perhaps I will make one more iteration.
> Note also that I prefer "denoting" to "with a [common] value", since
> "value" has too many meanings and the definition of interval literals
> in §9.4.1 uses the term "denotes".
"Denoting" is used for literals.
"with a [common] value" is uses for operations (like textToInterval(s)).
> I also think that the use of the same name textToInterval(s) for both
> the bare operation and the decorated operation is currently a bad idea
> due to the text in §9.4.5.
Personally I agree, but I'm not sure that everybody will like this.
-Dima
----- Original Message -----
From: vincent@xxxxxxxxxx
To: dmitry.nadezhin@xxxxxxxxxx
Cc: j.d.pryce@xxxxxxxxxx
Sent: Monday, February 23, 2015 6:32:40 PM GMT +04:00 Abu Dhabi / Muscat
Subject: Re: Common interval literals
Dmitry,
On 2015-02-21 23:54:43 -0800, Dmitry Nadezhin wrote:
> I tried to adapt "Interal and number literals" from Ch2 to Ch1.
> Please make a first round of review.
Here are my comments. Some of them could actually have applied to the
original text from §12.11 (Interval and number literals).
Page 29 line 4 (§9.4.1, first paragraph): "interval literal" is not
defined. I suppose that it means either a bare interval literal or a
decorated interval literal, but it is worth a definition. Something
like:
Bare interval literals and decorated interval literals are
collectively called interval literals.
Line 5: "if it denotes a finite integer it is an integer literal."
I would add a comma after "a finite integer".
Line 6: "The bare interval denoted by a bare interval literal of a
flavor is its value (as a bare interval literal). Any other string
has no value in that sense." is unclear. One can guess the meaning,
but I think that this is not well specified. I wouldn't talk about
the value of a *string* since it is just the sequence of characters.
Similarly, line 7, instead of "a string is called valid or invalid
(as a bare interval literal)", I would say: "a bare interval literal
is called valid or invalid". What I mean is that one can have:
* A string, which is just a sequence of characters.
* A bare interval literal, which is a string with some defined
interpretation: as a bare interval. A bare interval literal
may have a value (= is valid), which is a bare interval, or
not (= is invalid).
* A decorated interval literal, which is a string with some
defined interpretation: as a decorated interval. Similarly,
a decorated interval literal may have a value (= is valid),
which is a decorated interval, or not (= is invalid).
* A number literal, [...]
* An integer literal, [...]
Line 10: "Bare and decorated interval literals are used as input to
bare and decorated versions of textToInterval 9.5"
Text seems to be missing before "9.5".
Line 14: in "conversion of number literals", I don't like the term
"conversion", since it usually implies a loss of information. Here,
a number literal has a value (an extended-real number), and there
is no notion of precision.
Line 24: "It may restrict the support of portable interval literals,
by relaxing conversion accuracy of hard cases: rational number
literals (b)), long strings, etc."
* It is not clear whether this restriction occurs at Level 1
(where it is really a restriction) or at Level 2 (where it
should be part of Level 1 to Level 2 interval conversion).
If this restriction occurs at Level 1, then it is dangerous
as containment is no longer guaranteed.
* What is "(b))"? (See also the parenthesis mismatch.)
* Missing space after "etc.".
Line 27: "The value of a common interval in a flavor is the same as
its common value, modulo the embedding map." is unclear.
Page 30, line 7 (§9.4.2): "It may restrict the support of literals,
by relaxing conversion accuracy of hard cases: rational
literalsit:ch1nlitrat, long strings, etc."
Same remarks as above (+ "literalsit:ch1nlitrat").
Line 36 (§9.4.5): "A decorated interval literal may denote either
a bare or a decorated interval value depending on context." is in
contradiction with the definition of a decorated interval literal.
I think that there are two possibilities:
1) The grammar for the bare interval literals shall accept the
decorated interval literals. (Or is this the opposite?) And
this is not context-dependent.
2) Some operations can take either a bare or a decorated interval
literal in input.
In either case, whether this is a good thing is another matter.
There's also the question where a same string can denote both a
bare interval literal and a decorated interval literal, possibly
with different values for the interval part. I don't think that
this is currently forbidden by the standard; I would say that this
is obviously implicitly discouraged, but at least this shouldn't
yield a contradiction in the standard if not forbidden.
The rules given in §9.4.5 seem to apply to any decorated interval
literals, not just the common ones, so that either the subclause
title ("Common decorated intervals") or the text is unclear.
Page 31 line 2: missing period at the end.
Line 9: "The value of common bare literal in a flavor is its common
value, modulo the embedding map. The interval part of the value of
common decorated interval literal in a flavor is its common value,
modulo the embedding map."
Same remark as above.
Line 15 (§9.5): remove the comma after "numsToInterval(l,u)".
Why does §9.5 only handle common intervals? For textToInterval(s),
the rules should be the same for non-common intervals. For instance,
if s is a valid bare interval literal denoting the interval x, then
textToInterval(s) has value x, whether x is common or not. Everything
about the extension is in the grammar that defines the literals.
Note also that I prefer "denoting" to "with a [common] value", since
"value" has too many meanings and the definition of interval literals
in §9.4.1 uses the term "denotes".
I also think that the use of the same name textToInterval(s) for both
the bare operation and the decorated operation is currently a bad idea
due to the text in §9.4.5.
--
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)
Attachment:
CommonLiteralsCh1.pdf
Description: Adobe PDF document