[kepler-dev] Re: [kepler-cvs] kepler/src/org/sdm/spa ArrayToSequence.java

[xiaowen]

Hi Tobin,

I'll freely admit that org.sdm.spa.Count is something of a hack.  Let me 
explain what I want it to do, then ask for suggestions of how it could 
be better implemented, whether with ptolemy.actors.lib.Accumulator 
instead or using another method =)

Inside the PIW workflow, there's a point where we want to select the 
first two elements of a sequence that fit a certain criteria.  The 
general flow goes like this:

[sequence of tokens, outputted one by one]

-->

[Discard if we've already chosen two]

-->

[Discard if it doesn't fit other criteria]

-->

[Update count if the token passes]


This process takes place for multiple sets of sequences.


Because of this, we need an actor that's capable of keeping track of a 
count, and being able to reset the count when a new sequence starts.


Let me trace through what org.sdm.spa.Count does at run time.

When an element arrives to be processed, org.sdm.spa.Count outputs the 
current count, whereupon a decision is made whether to discard the 
token.  If the token isn't discarded, then it's submitted to further 
actors that determine whether it fits other criteria.  At the end of 
this, org.sdm.spa.Count is notified of whether the token passed, and if 
it did, then the internal count is updated.

We don't want the processing of the tokens to overlap because processing 
one token to figure out whether it passes is fairly expensive in this 
workflow.  So the workflow must wait until it knows whether the previous 
token passed the test and the count has been updated before it starts 
processing the next token.

So there's a one-to-one correspondence between the output count tokens 
sent by org.sdm.spa.Count and the input update tokens.  However, the 
output token is sent _before_ it receives the input token.  And the 
sending and receiving of them are kept synchronized so that a count is 
_not_ sent out until it receives notification of the fate of the 
previous token.  This is how the actor helps to ensure that the 
processing of one element doesn't occur until we're done processing the 
previous element.  Since we're operating in the PN domain, actors that 
expect a count from org.sdm.spa.Count will hang until they receive it.

Thus org.sdm.spa.Count serves a two-fold purpose:

1. keep the count
2. keep the synchronization


ptolemy.actors.lib.Accumulator expects both the reset token and the 
input token before it sends out an output token.  This is not 
interchangeable with org.sdm.spa.Count because I need it to output a 
count _before_ it receives the input token.  Perhaps the way to use 
ptolemy.actor.lib.Accumulator would be to send it a token in the input 
port when a sequence starts, and discard the last notification for each 
sequence.  It would be a bit messy, but could work.  What do you think?


Hopefully, I got the main idea across and why I needed this actor.  If 
something's not clear please ask.  Also, will you please suggest 
alternative ways of implementing this?


Thanks!
Xiaowen


Tobin Fricke wrote:
> On Fri, 2 Jul 2004, Stephen Andrew Neuendorffer wrote:
> 
> 
>>Out of curiosity: Why do you think you need this?
>>An array in Ptolemy always has elements of the same type.
> 
> 
> Likewise, how does orb.sdm.spa.Count differ from
> ptolemy.actors.lib.Accumulator?
> 
> I think the behavior that lead to org.sdm.apa.ArrayToSequence is similar
> to the problem I have with my ObjectToRecord actor (described earlier).
> It is "tempting" to circumvent the type system, but I'd rather not do
> that.
> 
> Tobin
> 
> _______________________________________________
> kepler-dev mailing list
> kepler-dev at ecoinformatics.org
> http://www.ecoinformatics.org/mailman/listinfo/kepler-dev