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

[xiaowen]

Hi Steve,


Responding to your questions:

1) I don't want the count actor to reset itself when it reaches the 
value of two.  The workflow compares that count against the value two 
to determine whether to process further tokens, so it needs to keep 
outputting the count (two) until we're done with the current sequence 
of tokens.

I'm honestly not sure how I could use a function predicate here 
effectively.  In order to determine whether to continue processing, it 
needs as input the update token from processing the last element, the 
current count, and possibly a number indicating the total number of 
elements to be processed.  This means there would need to be two sample 
delay actors, because both the count and the update tokens need to have 
an initial value.  Add to that an expression actor we'd need to use the 
function predicate, it's already as complex as the count actor 
currently is ... maybe I'm not seeing it the way you are.


2) That's a good point.  I'll have to ruminate on how to implement 
that.  Thanks for pointing it out.  It's a lot more intuitive to think 
of count as a storage unit -- you go retrieve its value at the 
beginning of processing an element, and you update its value when 
you're done processing that element.  So far, I've been forced to think 
of it as a function that takes as input the previous update token and 
the last count, and outputs the current count.  The FSM model might 
facilitate thinking of it as a storage unit.


Thanks,
Xiaowen




On Jul 7, 2004, at 4:40 PM, Stephen Andrew Neuendorffer wrote:

> That looks reasonable, although I'm still not sure that the update 
> port really needs a sample delay.
>
> As a parting shot, I'll ask two questions:
> 1) The reset port is built so that the model tells the component when 
> to reset.  But in the model, it will always just count to 2!  Could we 
> design a component that counts to a value given by a parameter and 
> then resets itself?  Or what if we gave it a predicate (a function: 
> inputs -> boolean) that said what inputs to count and another that 
> said when to reset?  This might be easier to understand, since the 
> 'stopping condition' is part of the design...
>
> 2) Finite state machines and modal models can often be used to express 
> things like 'reset' very easily.  If you build a synchronous dataflow 
> model instead of a process network, then you can put it 'inside' the 
> state of a finite state machine and a transition of the finite state 
> machine can re-initialize the model when the transition is taken.  
> This is essentially another way of making the 'stopping condition' 
> more explicit in the model: it will be the guard of the transition.  
> Unfortunately, Ptolemy doesn't deal well with process networks other 
> than at the toplevel currently, although it could.
>
> The point of all this is that control logic in dataflow is often 
> awkward:  One of the values of using things like FSM and function 
> closures, is that they are sometimes easier to deal with than just 
> plain dataflow.
>
> Steve