Re: Motion P1788/M0008.01_Exception_Handling
John Pryce wrote:
> Nate, P1788 members
>
> On 20 Sep 2009, at 22:40, Nate Hayes wrote:
>> 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,...
>
> Thanks for your positive response. I would love to believe what you
> say is true, but at present can't see how to make this a reality.
>
> In the "fully decorated" case, there would be an array
> yy.dec of size n by P
> (using my earlier ".dec" notation) of decorations yy.dec(i,p) on the
> output array yy, which would contain the FLAG information -- in field
> (s) that I'll call
> yy.dec.FLAG.
I don't see the fully decorated case is necessary. For each P iteration, we
essentially have just yy(1), yy(2), ... yy(n) and a single FLAG. In this
case, the yy vector can be computed with forgetful operators on bare
intervals. Then FLAG is just an alias for isValid( yy ). Implementors can
use any mechanism they wish to make sure the FLAG state is correct,
including global static variables in software or global sticky bits in
hardware. This may require changes inside the implmentation, but would be
transparent to the calling program.
>
> Now at implementation level we could arrange the memory stride in the
> i direction to be zero (this would require storing the yy.dec array
> separate from the interval array yy.inv, but we've decided compilers
> can do that). Then, physically, yy.dec would be a 1-dimensional
> array. And, if the actual action of updating an element
> yy.dec.FLAG(i,p)
> is a logical OR, then at the end of the calculation, this 1D array
> would hold the data I want.
>
> Indeed, if the memory stride were made zero in both directions, I
> would get the effect of a single scalar flag, that could be made of
> "regional" scope.
>
> So far so good. INSIDE the function ff, this hasn't changed the
> semantics; indeed the code can stay identical. But OUTSIDE, back in
> the calling program, the semantics are very different. Somehow, what
> is conceptually one array as a formal-argument within ff:
> struct(interval inv, decoration dec) yy[n,P]
>
> (I hope that is roughly correct C) has to be mapped to two actual-
> argument arrays in the calling program
> interval yyinv[n,P] 2D array holding the result intervals,
> decoration yydec[P] 1D array holding the result decorations.
>
> I can see how I could (conceptually) hand-code a one-off parameter
> passing process that would make this happen. But I can't at present
> see a language mechanism to inform a compiler that this is to be done.
>
> Looking at it more abstractly, I don't think a change that forces one
> to write the calling program differently can be just "a particular
> implementation choice" as you put it.
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. So if clean and natural code syntax is your concern,
I think the FLAG implementation may be the wrong approach.
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 Hayes