Re: Motion P1788/M0008.01_Exception_Handling
John Pryce wrote:
> Really, I would like to handle the scenario where "global flag" and
> "huge SIMD calculation" are combined. Namely, I have
>> - a vector function f: D \subseteq R^n -> R^n
>> - a box xx in R^n
>> and you want to check that
>> - f is defined and continuous on the whole of xx, and
>> - f maps xx into itself,
>> which proves that a fixed-point theorem can be applied.
>> With a "FLAG" approach it works very simply:
>> - Assume f has been coded up as a function, as this is the typical
>> case.
>> - Evaluate the interval version ff of f:
>> yy = ff(xx) where xx, yy are interval vectors of length n.
>
> But I now have P = a million xx vectors at once, and I wish to
> evaluate the P output vectors yy in SIMD mode, assuming that the code
> for ff can indeed be vectorised in that way (which is language- and
> compiler-dependent). And I want the FLAG reported individually for
> each component. A picture (using indexing from 1, not 0)
>
> 1 2 ... P
> xx(1) x x x ... x x x }
> ... ... ... ... } inputs, an n by P array
> xx(n) x x x ... x x x }
>
> v1 x x x ... x x x }
> v2 x x x ... x x x } intermediate variables in ff,
> ... } each is a P-vector
>
> yy(1) x x x ... x x x }
> ... ... ... ... } outputs, an n by P array
> yy(n) x x x ... x x x }
>
> FLAG x x x ... x x x } a P-vector
>
> Column p (for parallel) of this picture represents calculating (in
> Matlab notation)
> yy(:,p) = ff(xx(:,p)), for p=1:P.
>
> This is done a row at a time, e.g.
> v1 = xx(1,:) .* xx(3,:);
> v2 = sin(v1);
> ...
> This needs a vectorised library of interval arithmetic operations
> (and elementary functions) like the level-1 functions in BIAS. These
> operations set FLAG componentwise where appropriate.
>
> I continue to believe that for some applications, this gives a
> cleaner conceptual scheme than does leaving FLAG information in the
> decorations of individual output components yy(i,p).
...
> On 19 Sep 2009, at 02:02, Nate Hayes wrote:
>> John Pryce wrote:
>>> Therefore I would like the authors of this motion to consider adding
>>> suitable flag support to it.
>>
>> This may be the Camel's nose in the tent, since the abstraction is
>> then no
>> longer decoupled from the implementation.
>
> I accept this point to some extent. If my idea can't be cleanly
> described as part of Level 2 (as it seems decorations can be), it
> should be discarded.
Dear John,
I don't think your FLAG idea should be discarded.
I only mean to suggest what you mention is a particular implementation
choice, which I believe is already accomodated nicely by the Motion 8
abstractions.
For example, FLAG can be seen as just a pre-computed alias for the
combination of all yy(1), yy(2) ... yy(n) decorations that would otherwise
be returned by isValid( yy ), which you originally noticed would require a
potentially expensive component-wise examination of all the yy decorations.
So your example implementation trades the cost of the isValid( yy )
operation for requiring the user and/or implementor to manage the extra FLAG
memory and state.
In some implementations or computing environments, this may indeed be a
highly desireable and effective implementation strategy. In others it may
not be. I think the strength of the Motion 8 abstraction is it *allows* the
implementation example you provide, yet at the same time it does not require
it for all implementors. It is the nice thing about keeping the abstraction
and implementation decoupled.
Nate Hayes