Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: A Level 2 query

On 6/21/13 2:15 AM, John Pryce wrote:

P1788

(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. 

I await an answer to my query: what about an implementation that by default evaluates an expression in single precision (but stores the result in double) even when its inputs are double precision intervals? My view at present is: that doesn't violate the standard, it's just lousy QoI.
It should not violate the standard, because in a given situation speed might be more important than narrow width. 

(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? 

Cheers,

Bill



On 20 Jun 2013, at 16:03, Ralph Baker Kearfott wrote:

If P were not explicitly listed in the standard, and the value
it returned would contain the actual range, that certainly
would not be prohibited by the standard.  (However, I would think
it would not be controversial that, if the evaluation of P were
part of a package claimed to be standard-conforming, the value of P
shall contain the actual range.  I'll need to check our present
draft document carefully to see whether or not that is clear.)

That's just my personal take on it.

Best regards,

Baker

On 06/20/2013 09:27 AM, Richard Fateman wrote:

I am unclear as to whether you are excluding from consideration as
standard-conforming the following compiler
"optimization":

let  y :=   ...some explicit polynomial P in the interval variable x.

The compiler recognizes P as a polynomial, computes (at compile time)
locations and values at
  its relative maxima and minima, and at run-time uses this information to
compute inf(y)  and sup(y) on the interval x  entirely without
dependency slop.


John Pryce