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

[Daniel Zinn]

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