Re: A Level 2 query
Bill, P1788
On 22 Jun 2013, at 17:58, G. William (Bill) Walster wrote:
> On 6/21/13 2:15 AM, John Pryce wrote:
>> (A)
>> On 20 Jun 2013, at 19:10, G. William (Bill) Walster wrote:
>>> In my opinion, as long as the syntax and semantics are made clear, so there is no confusion about when multiple occurrences of the same interval variable are dependent, I think any cset invariant simplification should be permitted by the standard.
>> I agree (except for the word "cset", unfortunately). But with respect, the issues raised by Richard & Bill are not Level 2 issues. They are independent of precision, and concern language semantics and algorithms.
> My use of "cset" above is only short hand for the set of values that must be contained in the computed interval result. Surely, a transformation that changes the set of values that must be contained in the computed interval result cannot be allowed. Otherwise, one could simply make a transformation that caused the new cset to be a subset of the original.
Bill poses an important question. OK, for this discussion, "cset" shall not mean the topological containment set on which he and I worked together, but "the set of values that must be contained in the computed interval result" as defined by THIS standard.
This is 100% unambiguous for library functions: it is the set-theoretical range over a box, as specified in §9.4 of the text (ratified). In one sense it is equally unambiguous for (a function defined by) an expression F. If we agree that F defines a mathematical point-function f, then the range of f is what must be contained. In another sense it is totally *unspecified*, because P1788 leaves "the meaning of an arithmetic expression" language-defined.
But assume a normal language where we know what an expression means. Then isn't Bill's "a transformation that changes the set of values that must be contained in the computed interval result cannot be allowed" (a) correct and (b) un-problematic? F may be transformed to F* iff they define the same function f *over the box in question*.
As an example, in this standard F = x/(x+y) is equivalent to the SUE form F* = 1/(1+y/x) iff the box zz = (xx,yy) at which we evaluate does not have 0 in xx.
Bill, am I catching the sense of your query or is there something more? See below.
>> (B)
>> On Baker's comment below. I don't think the standard has anything to say about such a P. I think you are assuming some implementer who says
>> "Here's an implementation of 1788 with all the required functions"
>> -- and someone checks that out and it's all OK --
>> "and by the way, here is an interval implementation of function P which isn't mentioned in 1788"
>> (or a compiler facility, such as Richard mentions, that produces such implementations automatically for a class of functions)
>> -- but it turns out not to ensure containment.
>> As far as I can see
>> - The question "Does P violate 1788"? is as meaningless as
>> "Does this piece of cheese violate 1788"?
>> since 1788 says nothing about P.
>> - The fact that P is no good doesn't make the rest of the
>> implementation non-conforming. Unless our conformance
>> requirements explicitly say the contrary, and that seems
>> a bit OTT to me.
> Ahhhh. Here is the rub. Without clearly defining, or having a way to derive, P's cset, you are correct. The standard cannot say anything about any implemented interval evaluated function other than those explicitly specified in the standard. This is precisely why the standard, in my not so humble opinion, must provide a way for people to derive the cset of any possible expression, function, and/or finite sequence of them. Otherwise, how will anybody be able to determine if containment has, or has not been violated? How can one even speak of violating containment if what is to be contained is not defined?
Here we are going way beyond rearranging an expression. In Richard's original example P was a polynomial expression I think. So it defines an unambiguous point function p(x). But we apply cruel and unusual algorithms to it, like slope functions, or finding its maxima and minima at compile time, ..., so as to enclose its range more tightly. But why is there a rub? We know p so we know what "cset" means: the range of p. If such an algorithm always encloses that, it is correct. If not, it isn't. It's up to the implementer to prove correctness.
What am I missing?
John Pryce