Re: Draft decoration system for discussion
Michel
Sorry for the delay in responding, caused by a bad cold.
On 4 Dec 2012, at 04:34, Michel Hack wrote:
> 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)
Oops. Done.
> to collate information -> to collect information (?)
I think "collate" is OK. My dictionary gives it the meanings "collect & combine" and "compare & analyze", which seem right.
> 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.
I don't see a theoretical problem with using "ill" in this extended way, and see it as a matter of taste, maybe an option. I envisage user documentation on the lines of:
------
Apart from an "ill" interval (a NaI) being produced by an invalid construction such as text2interval("garbage"), it may occur when the compiler is able to determine that some function-expression is undefined for all real inputs (has empty domain). For example, suppose you define f(x) = sqrt(-1-x*x). If you evaluate the interval version of this in the normal way, on the interval [-1,2], the result is
f([-1,2]) = sqrt([-1,-1]-[-2,4]) = sqrt([-5,1]) = [0,1],
with the decoration trv. But analysis during compilation shows that as a real function, f(x) has empty domain, so instead code is generated to return
f(xx) = Empty_ill
i.e., NaI, for any interval xx. Another examples is in a constant expression inadvertently containing division be 0 ... This behaviour can be turned on or off with the switch -detectill ...
------
As for "evaluation by cases", can you give an example? I tried an example of the interval case function defined in Level 1 text §8.6.3, with an empty subdomain. Seems I haven't put its decoration behaviour into the text yet! However it seemed to give valid results.
> Related to this are cases where that smart compiler, or a case-based
> evaluation, determines that a result does not depend on certain inputs.
...
Very important point, I'll reply separately about this.
> 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...
That paragraph in 8.8.3 is wrong, as I noted in an earlier email. But I think your example doesn't actually show up any difficulty.
Namely "at Level 2 it would be bounded"?? Well, yes if you verify "bounded" by evaluating f(x) at every real number in [1,+oo] that is binary64-representable. But of course that's not how it's done. The interval library function log evaluates log([1,+oo]), and returns [0,+oo], so it all works OK.
> 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".
Yes, done. That used to be in Arnold's & my description, until the autumn 2011 decoration draft with ein (empty input) at the top of the order, where it looked strange to call ein the "best".
> 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?
Nate proposed such operations a week or two ago. I guess the Kaucher flavor will include them. If anyone makes a good case for such an op in the set-based flavor I'm willing to be persuaded.
> Page 35, 8.8.7, 1st sentence: what does "defined in $6.3" refer to?
Refers to the flavor-independent description of decorations in §6 in Chapter 1. A few words added to make this clearer.
> Page 35, 8.8.7, amended newDec function, typo: instaed
Yes
> 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).
Changed to "com describes both a Level 1 and a Level 2 property". Will that do?
> 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...
Do you mean that it is OK to leave all this in the Level 1 text?
> Page 36, 8.8.8, normalInterval() function (just past middle of page):
> This description is totally garbled.
Too right. I meant this function to convert xx to a decorated interval (yy,dy) of the parent type, but the phone rang or I made coffee or whatever, and forgot. Now done.
My spec is
If xx is an interval, return (yy,dy) = (xx,t) where t is the threshold.
If xx is a decoration d
If d is ill or emp, return (Empty,d).
Otherwise return (Entire,d).
Are there any flaws in that? Vincent: I expect you may object?
I also added a compressedInterval() function that does the reverse: converts a decorated interval to a compressed one.
John Pryce