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

[xiaowen]

Hi Bertram,

Hmm, that's an interesting way of looking at this problem.

Ptolemy II's expression language contains a function called 'iterate'  
that could prove useful here.

http://ptolemy.eecs.berkeley.edu/ptolemyII/ptII4.0/ptII4.0/doc/ 
expressions.htm

It takes three arguments: function, int, 'type'.

and returns an array of 'type'.

It returns "an array that results from first applying the specified  
function to the third argument, then applying it to the result of that  
application, and repeating to get an array whose length is given by the  
second argument."


A couple of examples:

 >> iterate(function(a:int) a + 1, 5, 1)
{1, 2, 3, 4, 5}

 >> iterate(function(rec : {count = int, index = int, ret=string})  
rec.count >= 2 ? {count = rec.count, index = rec.index + 1, ret = ""} :  
{count = rec.count + 1, index = rec.index + 1, ret = {'a', 'b', 'c',  
'd', 'e', 'f'}(rec.index)}, 4, {count=0, index=0, ret=""})
{{count = 0, index = 0, ret = ""}, {count = 1, index = 1, ret = "a"},  
{count = 2, index = 2, ret = "b"}, {count = 2, index = 3, ret = ""}}

This second example is a bit hard to read, but it basically passes  
around a record token to keep track of information.  The 'index' key of  
the record token remembers which element we're processing, and the  
'count' key remembers how many we've successfully processed (in this  
case, all of the ones that we've processed so far).  The 'ret' key is  
the return value after processing the current element.  If it's already  
processed two, then it returns the empty string.  Otherwise, it returns  
the element corresponding to the current value of index.

If we could somehow refer to a composite actor explicitly in the  
expression language and use it as if it were a function, then we might  
be able to get away using this expression, then parsing the result.   
However, it looks quite hairy, and might make the model less readable.

What do you think?


Thanks,
Xiaowen



On Jul 8, 2004, at 4:15 AM, Bertram Ludaescher wrote:

>>>>>> "x" == xiaowen  <xin2 at llnl.gov> writes:
> x>
> x> Hi Bertram,
> x> Thanks for the links.
> x>
> x> In this case, I believe that the workflow would be much more  
> efficient
> x> if the tokens were processed one by one rather than all in parallel
> x> because the processing involves querying web services, which is  
> fairly
> x> expensive.  Since we only want the first couple of tokens that pass  
> a
> x> certain criteria, there's no need to process all the tokens, and  
> that's
> x> why I needed a count actor.
> x>
> x> With a map actor, I'm not aware of a way to get it to process tokens
> x> sequentially and also stop processing the rest of them if the  
> previous
> x> ones fit a certain criteria.  Do you know whether that's possible?
>
> The way map works, it returns always the same number of tokens/list
> elements that it has been fed, so does not act as a filter.
>
> However to look at your "count problem" the functional programming
> (FP) way might prove useful here too. E.g. in FP languages one often
> uses a "take" function (e.g., 'take N Xs' would return the first N
> elements of the list Xs). A generalization could be the use of a
> higher-order filter actor that accepts as one of its inputs a filter
> predicate.. (with the hope that the signature and implementation
> effort of the filter predicate would be simpler than writing a special
> filter actor).
>
> Hmm.. sounds like an interesting topic for our meeting next week..
>
> Bertram
>
> x>
> x> I agree with you completely that there are other places in the  
> workflow
> x> that could benefit from using a map actor.
> x>
> x> Thanks for the suggestion, and I'll add links to some of the papers  
> at
> x> http://kbi.sdsc.edu/SciDAC-SDM/
> x>
> x>
> x> Xiaowen