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:[EMAIL PROTECTED] ICQ:79511325 > > AIM:QN303 Skype:DanielZinn IRC:[EMAIL PROTECTED] > > _______________________________________________ > > Kepler-dev mailing list > > [EMAIL PROTECTED] > > http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev > > Norbert Podhorszki > ------------------------------------ > University of California, Davis > Department of Computer Science > 1 Shields Ave, 2236 Kemper Hall > Davis, CA 95616 > (530) 752-5076 > [EMAIL PROTECTED] > ---------------------------------- -- "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:[EMAIL PROTECTED] ICQ:79511325 AIM:QN303 Skype:DanielZinn IRC:[EMAIL PROTECTED] ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: [EMAIL PROTECTED]