[kepler-dev] modeling question about producing f(A, x), f(A, y)...

Carlos Rueda carueda at ucdavis.edu
Fri Aug 3 15:30:39 PDT 2007


Precisely; being able to read multiple ai seems more interesting :)

Daniel Zinn wrote:
> On Friday 03 August 2007 12:13, Carlos Rueda wrote:
>> Hmm.. assuming each z, y, x ... is a fired token from A2, how is it
>> possible for A3, after reading (a1,z), to read y since it will block
>> while reading from A1?
> 
> As there is only one a1 token, the pseudo code for the actor would like like 
> this:
> 
> go() {
>   store = readFromA1();
>   while (true) { 
>     x = readFromA2();
>     output( f(store,x) );
>   }
> }
> 
> I would still prefer the solution I gave with only one channel and a switch in 
> the actor code. As this would also be able to read multiple ai.
> 
> Daniel
> 
> 
> 
>> Carlos
>>
>> Daniel Zinn wrote:
>>> On Friday 03 August 2007 11:59, Norbert Podhorszki wrote:
>>>> Close :-)
>>> I thought x,y,z,... are functions of a1.
>>>
>>> Daniel
>>>
>>>             a1
>>>
>>>>   A1 ---------------> ------  ..., f(a1,z), f(a1,y), f(a1,x)
>>>>
>>>>                       | A3 | -------------------------------->
>>>>
>>>>   A2 ---------------> ------
>>>>         ...,z,y,x
>>>>
>>>>
>>>> Norbert
>>>>
>>>> On Fri, 3 Aug 2007, Daniel Zinn wrote:
>>>>> Hi Norbert,
>>>>>
>>>>> ok, then maybe I don't understand the problem well enough. Let me give
>>>>> it another shot:
>>>>>
>>>>> in PN:
>>>>>
>>>>> A1 ---------------> A3
>>>>>    \---> A2 ----->
>>>>>
>>>>> A1 produces A which is branched and sent to A2 and A3.
>>>>> A2 just produces x,y,z,... from A
>>>>> A3 first reads from the A1 port and stores the A
>>>>>   then reads from the second port only and does its thing
>>>>>
>>>>> Daniel
>>>>>
>>>>> On Friday 03 August 2007 11:45, Norbert Podhorszki wrote:
>>>>>> Hi Daniel,
>>>>>>
>>>>>> Thanks for the idea.
>>>>>> You have generalized the problem here, because for us, A is just one
>>>>>> single token (a1 in your example).
>>>>>>
>>>>>> The collection-oriented modelling seems to be a bit heavy weight
>>>>>> solution in the sense, that if we start from a Constant with single
>>>>>> firing and a Ramp to generate a stream of tokens, it seems to be a lot
>>>>>> of work to make it a collection oriented workflow, isn't it?
>>>>>>
>>>>>> Thanks
>>>>>> Norbert
>>>>>>
>>>>>> On Fri, 3 Aug 2007, Daniel Zinn wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> (let me try, perhaps this might help)
>>>>>>>
>>>>>>> The problem here is that we need to preserve the dependency between A
>>>>>>> and x,y,z... This is a classical use-case for collection-oriented
>>>>>>> workflows.
>>>>>>>
>>>>>>> You could probably use Tim McPhillips' and Shawn Bowers'
>>>>>>> collection-oriented framework to solve this problem. You could send A
>>>>>>> as meta-data in a collection that contains x,y,z,.... In the third
>>>>>>> actor you then just pull the metadata and the x, ..
>>>>>>>
>>>>>>> You can also emulate a collection by using a workflow with 3 actors
>>>>>>> in a pipeline:
>>>>>>>
>>>>>>> A1 --> A2 --> A3
>>>>>>>
>>>>>>> actor one sends a1,a2,a3...
>>>>>>> A2 consumes a1 and produces a1, x, y, z, ..., a2, x, y, z
>>>>>>> A3's behavior depends on the type of what is coming in:
>>>>>>>     if   input == ai    => store ai in a local variable for later
>>>>>>>     else (input is one of x,y,z,...) => compute f(ai, input) and
>>>>>>> output result (with or without context)
>>>>>>>
>>>>>>> PS:
>>>>>>>
>>>>>>> In a collection oriented / tree-type enabled workflow where inner
>>>>>>> nodes also can contain data, you could do something like that:
>>>>>>>
>>>>>>> Let the three actors be
>>>>>>>
>>>>>>> A1 --> A2 --> A3
>>>>>>>
>>>>>>> A1 produces data of type A*        (that is a list of As)
>>>>>>> A2 produces data of type A[X*]     (that is to each A, also contains
>>>>>>> a list of x,y,z...
>>>>>>>                                    as a new sub collection)
>>>>>>> A3 then has a 'read scope' of A=>a[ X=>x ]
>>>>>>> A3's action then uses a and x.
>>>>>>>
>>>>>>>
>>>>>>> Daniel
>>>>> --
>>>>> "The acquisition of wealth is no longer the driving force in our
>>>>> lives ... we work to better ourselves and the rest of humanity."
>>>>>
>>>>> reach me at:    Jabber:q at n251.fem.tu-ilmenau.de  ICQ:79511325
>>>>>                AIM:QN303 Skype:DanielZinn IRC:q at irc.gimp.org
>>>>> _______________________________________________
>>>>> Kepler-dev mailing list
>>>>> Kepler-dev at ecoinformatics.org
>>>>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-de
>>>>> v
>>>>       Norbert Podhorszki
>>>>     ------------------------------------
>>>>       University of California, Davis
>>>>       Department of Computer Science
>>>>       1 Shields Ave, 2236 Kemper Hall
>>>>       Davis, CA 95616
>>>>       (530) 752-5076
>>>>       pnorbert at cs.ucdavis.edu
>>>>       ----------------------------------
> 


More information about the Kepler-dev mailing list