Re: Status of 1788 revision: interval literals
John,
First, I answer the questions that I found in your edits.
p.29 line 29.
> [b)] meant to be c)
Yes. Thank you.
p.29 line 33
> The value of a common interval in a flavor is the same
> as its common value, modulo the embedding map.
> —In 9.4.6 I see the point of such a statement but here, I’m not sure what ir means.
My bug. The intention was "The value of a common interval LITERAL".
Perhaps a link to (7.2 Flavor basic properties) after the words "embedding map" is appropriate.
p.30 line 13
> overlaps some of 9.4.1, can repetition be removed?
YES.
p.30 line 43
> A decorated interval literal may denote either a bare or a decorated interval value depending on context.
My bug again. I forgot to kill this line.
> JDP: As I said on 21 Feb, I feel automatic “demotion” from decorated to bare is risky; “promotion” from bare
> to decorated might be less risky and I can see it could be useful. But anyway, are they our business? As they
> are a kind of cast or coercion, should we not be silent, or at most say such things MAY be done, and defer to
> the language? Removing this feature simplifies 9.4.5.
I agree with dropping "demotion".
However, I don't think that treating "[1,2]" as a valid decorated interval is a coercion.
Coercion is defined on numerical types. "[1,2]" is a sequence of char.
Suppose a program used decorated textToInterval(s) to parse a string "s" entered by an user.
User may enter "[1,2]_com". No questions in this case.
User may enter "[1,2]". How will the program coerce ? Do we expect programmer to actually make a new char sequence
by appending four chars '_', 'c', 'o', 'm' ?
It seems to me that a set of valid decorated interval literals contains a set of valid bare interal literals.
It is similar that a set of valid decimal number literals contains a set of valid integer literals.
p.31 line 11
> sx_com. I put com in tt font here as it is literal tex
Thanks.
> 3. If we approve this new text in Chapter 1, I hope 12.11 can be drastically shortened,
> to say only what the set-based standard *adds* to the Chapter 1 spec.
> I will start work on this, but Dmitry, maybe you already have this in hand?
Yes, It can be shorted, but I haven't done anything on it.
Vincent has a lot of comments.
One of them that I should put more stress on requirements
to portable intervals literals for each flavor
than only to common interval literals.
I think that they will cause me to make one more version of the text.
John, please either send to me or to the repositiry the "P1788D_levels.tex" source
with your edits.
-Dima
----- Original Message -----
From: j.d.pryce@xxxxxxxxxx
To: rbk5287@xxxxxxxxxxxxx, stds-1788@xxxxxxxxxxxxxxxxx
Sent: Wednesday, March 4, 2015 4:01:29 AM GMT +04:00 Abu Dhabi / Muscat
Subject: Status of 1788 revision: interval literals
Baker, P1788
On 2 Mar 2015, at 13:14, Ralph Baker Kearfott <rbk5287@xxxxxxxxxxxxx> wrote:
> What is the status of the revisions to the document?
I regret taking so long to respond, it is my teaching period in Cardiff. For now I just comment on what seems the most substantial revision to the text, namely to remedy Vincent's 17 Feb criticism of the text's currently vague specification of interval literals (also see my 20 Feb reply) by making a flavor-independent specification of "common interval literal".
Dmitry acted very quickly to produce such a spec as a new subclause inserted after §9.3, so it is §9.4. Attached is his text plus my comments/edits in red:
- red roman text is an insertion
- [except if in brackets like this] it is a deletion
- red italic text is my comment.
Notes:
1. Dmitry requires uncertain form, as well as inf-sup (and point) form, be supported. Thinking it over, I'm happy with this choice.
2. I'm increasingly doubtful of "promotion" and "demotion" (between bare & decorated), see my comments in 9.4.5. I now feel one should defer to the language, on whether it is supported. This applies to the set-based version too, in 12.11.
3. If we approve this new text in Chapter 1, I hope 12.11 can be drastically shortened, to say only what the set-based standard *adds* to the Chapter 1 spec. I will start work on this, but Dmitry, maybe you already have this in hand?
My assessment of changes in response to other comments will follow soon.
John Pryce