Re: Motion 42: Decoration system, re-revised text
Michel
As usual, thanks for these comments.
On 2 Jan 2013, at 17:20, Michel Hack wrote:
> Comments on
> 20121231DecoSystemCirculatedA.pdf with §5 Flavors, §6 Decorations overview,
>
> I like the notion of "included flavors".
Good.
> Page 12, last bullet in examples for 5.2: The definition that gives
> a smaller set of common evaluations is *stronger*, not weaker.
> At least that's how I understand strong and weak conditions.
Are you sure? Take, say,
sign([0,3])=[0,1]
which is true in the set-based flavor but at present is not common. If I insist that it be common, that makes makes sign's common evaluation set CE(sign) bigger, and is *more* restrictive, which is what I would call stronger -- e.g. csets can no longer be a flavor, whereas at present I believe they can be.
> Page 12, Note at the end of 5.3: "tightest" is NOT the same as the "tight"
> defined in this context, because "tightest" is a level 2 concept. Take
> for example sqrt([1,2]).
You are right. Best to remove the parenthesised comment, how about "Note. Different qualities of Level 2 enclosure are distinguished by the terms tightest, accurate and valid..."?
> Comments on
> 20121231DecoSystemCirculatedB.pdf with set-based decoration system details.
>
> Page 34, 2nd line of 2nd para of 8.8.4: is "and y_emp" supposed to be there?
Typo. Should be y_ill.
> Page 36, 8.8.8: I would like to add:
>
> "com is (should be?) a valid 2nd argument to setDec() even
> in implementations that do not support the com decoration;
> the result shall be as if "dac" had been given."
Ah yes, you said that before. I agreed but forgot to include it. Done, saying "com shall be ..."
> Perhaps clause 6.3 (in part A) should already mention this, e.g.:
>
> "All flavors shall support the com decoration, but implementations
> supporting a single flavor may treat "com" as equivalent to that
> flavor's strongest decoration when trying to set it, and would
> never report "com" when extracting the decoration part."
>
> If this is done my parenthetical "should be?" would not be needed.
I should like something like this, but it struck me that "com" is not necessarily a flavor's *strongest* (best) decoration. E.g. a flavor might reasonably have a decoration "anl" which says f is real-analytic everywhere on the input box. If you can think of suitable wording I'll consider putting it in, and changing 8.8.8 to match.
> Page 37, 8.8.10: Assuming my suggestion for 6.3 above is accepted, this
> paragraph could become:
>
> "A single-flavor set-based implementation shall treat "com"
> as if it were "dac", in accordance with #6.3 in Chapter 1.
Well, not necessarily, since a single-flavor implementation may like to detect overflow, see your next comments.
> A multi-flavor implementation shall define the "com"
> decoration as follows:"
>
> Page 38, 3rd Note: When com is provided -> when com is fully supported
> (Again, subject to my 6.3. suggestion.)
>
> A similar correction would be needed in the penultimate paragraph on
> this page.
>
> It may also be worth pointing out that as soon as a decoration is
> produced the evaluation ceases to be common (because the implied
> interval is then either Empty or Entire, neither of which is common).
When the threshold is com, events A = (the evaluation ceases to be common) and B = (a decoration is produced) occur at the same time. When the threshold is < com, A can happen before B. But that seems self-evident from the definitions: is it worth saying?
> Page 39, 2nd half: Looks good. (It reflects a private discussion I had
> had with John a few days ago.)
Good. If anyone sees a flaw, please say so.
John Pryce