Re: V02.1Decorations question - depending on history
This is a standard for computing, not for off-line analysis. The only information available to an operation is its inputs. For an undecorated interval, that is just the lower and upper bounds of the ranges of its inputs. For a decorated interval, the decorations of its inputs are also available. Each value's decorations result from some aspects of the history and values in its computation. They do not include the complete history of its computation.
The definition of an operation MUST work and produce correct results in the absence of any history or context other than what is included in its input values - the bounds and decorations.
At the same time, a compiler or interpreter MAY be able to see some subset of the _expression_(s) in its calculation or may know some history. The size of the subset would depend on things like the way the program was written, the way the compiler or interpreter is designed, and what optimizations have been done. Examples:
- Writing a complete _expression_ in one statement will make more visible than splitting it into several separately compiled functions.
- The internal representation in the compiler may make some subexpressions more or less opaque, especially across statements and most especially across function boundaries (even when the function is inlined).
- Optimizations like Inlining or Value Propagation may effectively combine separate expressions into one, making more visible.
- A tool designed to facilitate as precise analysis as possible instead of for efficient computation might keep a very extensive history of how a value was calculated.
So while we must define all operations to work correctly in the absence of context or history beyond what's recorded in the optional decorations, some implementations might be able to do better and if the standard allows a mode producing more precise results than what's required, using _expression_ context and history would be part of that. "More precise" applies to both the ranges and the decorations.
- Ian McIntosh IBM Canada Lab Compiler Back End Support and Development
Arnold Neumaier ---04/01/2010 06:28:49 AM---Dominique Lohez wrote: > Arnold Neumaier a écrit :
From: |
Arnold Neumaier <Arnold.Neumaier@xxxxxxxxxxxx> |
To: |
Ian McIntosh/Toronto/IBM@IBMCA |
Date: |
04/01/2010 06:28 AM |
Subject: |
Re: V02.1Decorations question |
Dominique Lohez wrote:
> Arnold Neumaier a écrit :
>>
>> The basic question was whether floor([0.5,1.5]) should return the
>> decoration PossiblyContinuous (my conclusion) or NotContinuous
>> (Nate's conclusion).
>
> IMHO the trouble arises from the fact that the decoration is considered
> independently of the value of the interval to which it is
> associated.
>
> In the present situation the decoration reflect a property of the
> history of the calculations including the application of the the floor
> function
>
> Given X = [0.5, 1.5] and R= floor(X) , we have R= [0,1]
>
> The decoration of R is NotContinuous whatever the decoration of X may be.
>
> If we consider an _expression_ such R=floor(S) with S=f(X)
>
> A smart implementation of f(X) can produce a result S strictly
> included between 0 and 1 , we obtain R=[0,0] .
> The decoration of R is continuous provided both X and S bear
> this decoration
>
> A less smart implementation of f(X) could produce R =[0,1] or even
> R=[-1, 1].
> In these cases, the decoration of R is necessarily NotContinuous .
> This decoration does not depend on the decorations of X and S.
No.
We do not know how X was produced. It could have come from a prior
computation yielding overestimation. For example, the arithmetic must
produce a correct result for fcn([0,1]) given the function defined by
the Matlab program
R=fcn(z);
X=0.5+(z-z)^2;
R=floor(X);
end;
The function fcn(z) is continuous for z in [0,1].
Your and Nate's recipe produce the decoration NotContinuous, which is
wrong and misleading, while my recipe produces the decoration
PossiblyContinuous, which is valid though not very informative.
Arnold Neumaier