[kepler-dev] modeling question about producing f(A, x), f(A, y)...
Daniel Zinn
dzinn at ucdavis.edu
Fri Aug 3 15:33:03 PDT 2007
Indeed, therefore, see my first email on that topic:
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, ..
On Friday 03 August 2007 15:30, Carlos Rueda wrote:
> Precisely; being able to read multiple ai seems more interesting :)
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
On Friday 03 August 2007 15:30, Carlos Rueda wrote:
> 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
> >>>> ----------------------------------
--
"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
More information about the Kepler-dev
mailing list