Re: A Level 2 query
>
> Suppose you have the function
>
> SUB(X)
> INTERVAL X
> SUB = X-X
> RETURN
>
> and in the calling program
>
> INTERVAL X
> X = [-1,1]
> Y = X-X
> Z = SUB(X)
> PRINT, X, Y, Z
> END
>
> Do you expect to get [0,0] for Z and [-2,2] for Y? Isn't that what your
> "without dependency slop" remark implies?
I would prefer [0,0] for both Y and Z in this case. Perhaps the example
should be this;
SUB(X,Y)
INTERVAL X,Y
SUB=X-Y
RETURN
and the calling program
INTERVAL X,Y,Z
X=MAKE_INTERVAL(-1,1) // this conforms to the syntax of my made-up
language :)
Y=X-X
Z=MAKE_INTERVAL(-1,1)
Z=SUB(X,Z)
PRINT, X,Y,Z
END
In this case the SUB routine is given two arguments by reference which are
in different memory locations and presumably independent. so Z
is [-2,2]. Y could be [0,0]
There is another version, which is trickier...
...
Y=X-X
Z=X
Z=SUB(X,Z)
Now X and Z are different locations in memory, but arguably they
have the same mathematical value, so maybe SUB(X,Z) should be [0,0]?
(This could be implemented by tagging each interval at its creation;
two intervals with the same tag are dependent and equal...)
compare this to
Y=X_X
Z=X+MAKE_INTERVAL[0,0]
... or Z=COPY_INTERVAL(x)
in which the programmer has made some effort to show that
X and Z, while component-wise arithmetically equal, are
not the same.
I assume that these kinds of things exist in other interval
library designs where people have made some effort to
extract single-use expressions, are willing to consider
differentiation / max / min extraction, etc. From the
perspective of the language/compiler-for-intervals
design, I think the routine
SUB(X)
SUB=X-X
RETURN
should return [0,0] for finite intervals. I'm unsure about
what is best if X is not-an-interval. (etc)
Anyway, my question is still -- if the compiler works hard to come
up with a tighter enclosure (by doing SUE simplification, polynomial
root finding, etc) is that going to violate the standard, or is it
irrelevant to the standard being supra-library, and nothing to
worry about :)
RJF
>
> If so, then the standard should make it very clear that interval
> arguments of functions are to be evaluated differently from regular
> interval variables.
>
> Cheers,
>
> Bill
>
> On 6/20/13 7: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.
>> And perhaps with great speed compared to evaluating P.
>>
>> RJF
>>
>>
>> On 6/20/2013 6:05 AM, John Pryce wrote:
>>> Ian, Jürgen, P1788
>>>
>>> What I get from these replies is that the T -> T operation *should*
>>> be mandatory. Ian's comments are important but they apply to
>>> expressions. Those are a language issue and we IMO
>>> (a) *should not* make requirements about expression-evaluation
>>> (beyond containment);
>>> (b) *should* make recommendations on the lines Ian proposes.
>>> Actually, thinking about it, I'm less sure about (a).
>>>
>>>
>> <snip>
>>
>
>