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

[Daniel Zinn]

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