Draft decoration system for discussion
Here are my comments.
Page 31, 3rd-to-last paragraph of 8.8.1:
"The P1788 decoration model, in contrast with 754's, ..."
The P1788 -> This standard's
754's -> 754's exception model (754 has no decoration model)
to collate information -> to collect information (?)
Page 32, 8.8.3, Ill-formed intervals.
I am not sure it is a good idea to use "ill" for anything other than
the result of invalid constructors. It seems perfectly ok to return
"emp". When there is evaluation by cases it may turn out that some
cases don't apply, i.e. have empty subdomains -- this should not have
to pollute the final result.
Related to this are cases where that smart compiler, or a case-based
evaluation, determines that a result does not depend on certain inputs.
This would certainly be the case for functions with a variable-length
argument list, where one of the inputs (implicit or explicit) is the
number of arguments. Should an "input" that is not used affect the
result? I referring of course to inputs that *provably* have no effect.
Page 33, 8.8.3, Unbounded dac intervals.
Consider the function 1/(1000 - log(x)) for positive x. This
is undefined for a very large x (outside 754 binary64 range),
so at Level 2 it would be bounded. However, if an interval
input is [1,+oo;dac], the dac must not be allowed to propagate
because that input range does contain the large pole.
I'm not saying the document is wrong; I just feel a bit uneasy...
Page 33, 8.8.4, propagation order (just above the Notes).
It might be nice to describe the two sides of trv as "good" and "bad".
Page 34, last para of 8.8.5: "may provide versions ... add a decoration"
Does this partially address Nate's concern? Would it be worthwhile
to standardize (and expect implementations to use different names)
SOME useful decorated Hull and Intersection operations -- granted
that the default, unadorned operations would be bare-only?
Page 35, 8.8.7, 1st sentence: what does "defined in $6.3" refer to?
Page 35, 8.8.7, amended newDec function, typo: instaed
Page 35, 8.8.7, Note. "com describes a Level 2 property".
The notions seems perfectly well-defined at Level 1, where it simply
excludes empty and unbounded inputs; in all other cases it is, at
Level 1, equivalent to dac. The real benefit does indeed show up at
Level 2, due to the guarantees on intermediate results mentioned at
the end of the next paragraph (bottom of page 35).
Page 36, 8.8.8, Compressed decorated intervals.
As formulated by means of a decoration threshold this too makes sense
as a Level 1 concept, though the practical consequences show primarily
at Level 3. The level 1 domain is the union of the set of non-empty
bare intervals and a discrete set of decorations, in a cross product
with a constant threshold (i.e. it is a family of domains parameterized
by the threshold).
Page 36, 8.8.8, normalInterval() function (just past middle of page):
This description is totally garbled.
Michel.
---Sent: 2012-12-04 05:47:11 UTC