Re: Motion P1788/M0008.01_Exception_Handling
Marco, Juergen, Nate, P1788 members
I find the flagspace idea definitely interesting. I have some further questions about the "decoration" approach:
Nate Hayes wrote:
> Note that if yy is a 100 element vector, it is normal in vector operations
that evaluating
yy <= 0
requires 100 component-wise evaluations of yy. In this regard, the fact that
isValid( yy )
requires 100 component-wise examinations of yy elements does not seem to
me poor design; it is just status-quo for vector operations. Along these lines,
I think your example breaks the syntactic model one would generally expect
from a vector library. ...
-----
Not really. The vectorisation I described happens along a dimension orthogonal to xx and yy, the one indexed p=1..P. It just happens that xx and yy are vectors in my (notional) function yy=ff(xx). But it might have been, using Matlab syntax,
[yy1,yy2] = ff(xx1,xx2,alpha)
say, where the xx's and yy's are interval scalars and alpha is a real scalar. For definiteness suppose the body of ff says
(*)
uu = xx1.^alpha + xx2.^alpha;
yy1 = xx1./uu;
yy2 = xx2./uu;
Again I have used Matlab notation, with ./ meaning element-wise division, etc. Addition is automatically element-wise.
My points are
1. The vectorisation replicates this over each "SIMD thread" p = 1 to P.
However this is done by the library. The user writes the code (*) and
the effect is
for p=1:P
uu(p) = xx1(p)^alpha(p) + xx2(p)^alpha(p);
yy1(p) = xx1(p)/uu(p);
yy2(p) = xx2(p)/uu(p);
end
I could have merged xx1, xx2 into a vector of length 2, in which case the code for (*), in Matlab notation, would change to
(**)
uu = xx(1,:).^alpha + xx(2,:).^alpha;
yy1 = xx(1,:)./uu;
yy2 = xx(2,:)./uu;
(assuming the SIMD-dimension of xx is chosen to be the second dimension). One could do the same to yy1, yy2.
2. Each SIMD thread needs its own flag(s). As in my previous, I speak of one flag per thread that plays the role of "possiblyUndefined". These form an array indexed over p=1:P, that I call FLAG.
Any line of the code above could set some elements of FLAG, depending on the inputs.
3. It is inherent in my view of things that FLAG does not belong to any one of the six "actors" xx1, xx2, alpha, uu, yy1, yy2; nor to any one expression or assignment statement. Instead, each element FLAG(p) belongs to the p-th thread.
4. The library is not written by the user. Somehow, there must be a way to tell the library, as part of the definition of the vectorised ff, that as code (*) is executed, if "possiblyUndefined" occurs in any of the 3 lines of (*), for a specific p value, then
FLAG(p) must be set.
Nate Hayes wrote:
> However, an object-oriented design might be able to salvage the model by introducing the notion of a "decorated interval vector", e.g.,
class DecoratedIntervalVector< N > {
public:
Interval inv[N];
Decoration dec;
};
DecoratedIntervalVector< n > yy[P];
Now the compiler has something to possibly work with to make the FLAG model more natural in its vector-like syntax.
-----
Nate, I do not see how your "DecoratedIntervalVector" class comes anywhere close to meeting this spec. For my example above, it seems one needs to write a new "DecoratedPairOfIntervals" class that holds yy1, yy2, and a decoration. That is, you need to write a new class, for each pattern of output parameters that occurs in vectorised functions in the user program.
And, if YY is the instance of this class that forms the actual output argument to the vectorised function, you need a way to tell the library "Use the vector formed by the fields YY(p).dec, p=1:P, as the FLAG vector when calling my function ff". Doubtless possible, but neither easy nor neat.
On the other hand, the flagspace approach seems closer to offering what I am asking for. Of course things are usually easier when one allows oneself a language extension! I also have some questions about the approach, of which more later.
Best wishes
John Pryce