Re: Comments on Motion 42 (not 41): Decoration system, revised text
Michel, P1788
I was looking forward to a holiday break, but well thought out comments from various people demanded a response ...
On 21 Dec 2012, at 15:36, Michel Hack wrote:
> First on 20121221DecoSystemCirculatedA.pdf:
>
> 5.1, end of 2nd paragraph: "The permitted flavors..."
>
> This suggests that only flavors explicitly described in the standard
> are permitted. It seems to me that providing a non-standard flavor
> (in addition to at least one standard flavor, of course) should not
> cause non-compliance, though we may place requirements on the need
> for proper documentation.
You are right that "permitted" is not the right word. Change the wording on these lines:
- We need a notion of a flavor being officially in the standard: I suggest "included", "inclusion" as the term for this.
- Initially we expect the set-based and Kaucher flavors to be included.
- Any implementation may provide another flavor, which to be counted a flavor must conform to the general principles of clause 5.
- A flavor can be submitted for inclusion in the standard.
So there are issues of the ongoing existence of the 1788 working group to be sorted out. My idea is that a submitted flavor (a document + a sample implementation?) undergoes peer review by an "Editorial Board" of 1788. I discussed this off-line with the Chair and a few other officers.
Chair: I think it's time for someone who is good on the procedural aspect to draw up a motion on the lines of "If IEEE approves the 1788 standard, an ongoing 1788 working group shall be set up", together with at least an outline constitution for it.
> 5.2, last sentence. The concept of "loose common evaluation" is nice,
> but I think we need to distinguish three levels of tightness:
> Level 1 tight (described here), Level 2 tightest, and loose (could
> be due to Level 2 difficulty constraints, or conceivably Level 1
> computability constraints).
Well, we have Arnold's 3 accuracy modes at Level 2:
"tightest", which you mention,
"accurate", which you don't,
"valid", which corresponds to what I've called "loose".
It seems OTT to distinguish these 3 here. What would you like said?
> 5.3, last sentence: I like the introduction of the "com" decoration.
>
> 6.1, top of page 14: I like the way expressions are introduced.
Good. NOTE: The Level 1 (accepted) text needs amending to take this less-precise view of expressions.
> 6.3, on optionality of "com" in single-flavor implementations.
>
> For functions with decoration inputs, such as setDec() or isDec(),
> the name (or enum value) of "com" should be available universally for
> code portability reasons. If "com" is not supported, setDec(com,xx)
> should set dac, and isDec(com,xx) should return FALSE.
Seems good to me. Anyone see a problem?
On this topic:
(a) I was thinking one can overload newDec() with this role:
1 argument, newDec(xx) returns xx with its "natural initial decoration" dec(Id,xx).
2 arguments, newDec(xx,d) returns xx with the decoration d.
(b) Does setDec/newDec count as a constructor? In particular, does
newDec(Empty, d) where d is def, dac or com
count as an invalid constructor call, so that it returns NaI (which is (Empty,ill))?
BTW add (Empty,com) to the forbidden list in 8.8.4.
> 6.3, 2nd paragraph at the top of page 15: "Flavors should define other..."
>
> I think it should say "Flavors should define THE other decoration
> values..." (without my emphasis). As written it appears to suggest
> that flavors should define ADDITIONAL decorations!
Maybe you have misread my intention. My view is that there is *no* standard flavor-independent set D of decorations. D is entirely flavor-defined, except for the requirement about com.
E.g. one can have decorations that don't "lie in a line", as long there is a propagation rule that leads to correct inferences. Any problems with that?
John Pryce