Re: scheduling and related questions

[Roger M. Burkhart]

> I have some questions, most related to scheduling of activity
> (at one level or another).
> Just a general note: what I'm looking for is not
> abstract algorithms, but advice about what's the best
> way to do this kinds of things in *Swarm*, i.e., given the way
> Swarm objects like lists, indexes on them, etc, work.
> 
> Suppose I have a Pop object, which has
>    id agents;     // a List 
> which has a bunch of Agent objects in it.
> Over time agents are created and destroyed.
> (In one extreme case, they are *all* destroyed and
> the list re-created each time step T.
> In the other, sometimes none are changed during a time step.)

Given that you want a different order every time, the basic approach
I'd suggest is to create a separate scrambled version of the collection
every time it is traversed.  This is like an index that would traverse the
members in a randomly determined order each time it is created, but you'll
need to create a complete temporary collection to hold the members in
their randomly determined order.

You are currently on your own to create this temporary collection and
to use whatever algorithm you like to load its members before you traverse
it.  As part of its concurrency model, Swarm has some future plans for
randomizing order of actions declared to be concurrent, but this is not
available on members of ForEach collections in the current interface design
(though some way of specifying this on each ForEach collection is
probably needed).

> 1. Suppose I want to activate my list of agents
>    in a different random order each time step T.
>    If I wanted to just have them processed in some
>    unknown (but I assume fixed) order I guess I would send
>    the following to my modelActions ActionGroup:   
>       [modelActions createActionForEach: [pop getAgents] message: M(step)];
>    as we see in heatbugs (if I recall correctly).
>    A couple of questions: 
>    a. What would I do to guarentee these agents are sent the step
>       message in a different random order each time step T?

Instead of sending the message to the [pop getAgents] collection, send the
message to a separate temporary collection initialized in an immediately
preceding step.  Since the collection is created for just this one use,
the most efficient form of collection is just an Array, and that also
gives a convenient way for directly indexing the members by calculated
offset for random selection.

At the point you're about to begin the traversal, the overall operation would
first be to copy all members of your target collection to a temporary array
containing just the needed count of members, applying your favorite random
shuffle algorithm somewhere along the way.  Then send the step message to
that collection instead of the one you started with.  Clean up the temporary
collection after you're done, or hold it somewhere for the next time around.

A random traversal order could be built into a special form of index on
any kind of collection, which would essentially use this form of temporary
machinery internally.  Or, some way of distinguishing a sequential vs.
random ForEach action could be devised.  Both these make sense, but your
only choice for now is to do your own.  Then maybe we can go ahead and
make this an integral part of Swarm.

>    b. How do I set the seed for whatever RNG Swarm uses
>       for generating those agent list permutations down in schedules, 
>       so that I can repeat the experiment exactly by setting the seed
>       to a known seed once at the beginning of a run?

Since Swarm doesn't generate these agent list permutations itself, at
least not currently, you supply your own seeds to whatever RNGs you use.

> 2. Suppose I have a small sublist of agent objects, eg suppose
>    each agent has 
>       id neighbors;   // a List of neighbor agents
>    Suppose down in the [agent step] method somewhere I'd like to
>    process an agent's neighbor list, again in a 
>    different random order each time I go through it.
>    What's the best (most efficient,cleanest) way to do that?

Somewhere, somehow, you end up having to do a random order regeneration
much like the above.  It's not particularly efficient, but it could be
clean if packaged into good reusable code that kept the storage along
with a traversal index just for as long as it needed it.  I suspect the
RNG calculations swamp any effects of temporary storage usage anyway.

Those were your first two, high-priority questions.  On the third
question:

> Again, suppose I have a Pop object with 
>  id  agents, newAgents;   // both are List's
> with [pop getAgents] returning that first list.
> 
> 3. I have a question about the following (admittedly naive) experiment.
>    I set up a simple model schedule like this:
> 
>       modelActions = [ActionGroup create: [self getZone]];
>       [modelActions createActionTo:      pop        message: 
> M(startGeneration)];
>       [modelActions createActionForEach: [pop getAgents] message: M(step)];
>       [modelActions createActionTo:      pop        message: 
> M(endGeneration)];
> 
>       modelSchedule = [Schedule createBegin: [self getZone]];
>       [modelSchedule setRepeatInterval: 1];
>       modelSchedule = [modelSchedule createEnd];
>       [modelSchedule at: 0 createAction: modelActions];
> 
>     Now in [pop startGeneration] I wanted to use the current
>     agent list (the list returned by [pop getAgents]) to create a list of
>     newAgents, and then replace the current list of agents with those new 
> ones.
>     Then I wanted the step message to be sent to those new agents during 
>     that same T step of the schedule.
>     So (still thinking in non-objectiveC/Swarm terms) I put the 
>     following in  pop-startGeneration:
> 
>         // do whatever to create the newAgents (all new objects) 
>         // from the agents List, then...
>       tmpList = agents;          // save pointer to agents
>       agents = newAgents;        // agents now point to newAgents list 
>       newAgents = tmpList;       // newAgents points to old list of agents
>       [newAgents forEach: drop]; // get rid of those old agents!
>         [newAgents removeAll];
> 
>     What I found was that during the T step right after this is first done,
>     no agents get any of the messages sent to the agents in [pop getAgents].
>     Then the next time step (new) agents do get messages.
>     Then the next step none do, and so on.
> 
>     I gather that despite the fact that to me it looked like I was
>     switching the agents id variable to point to the list of 
>     new agents before (ie in pop-startGeneration) the schedule sends the 
>     step message to the agents list, that's not what really happens.
>     What does happen?

The problem is that the [pop getAgents] subexpression in your original
schedule setup:

>       [modelActions createActionForEach: [pop getAgents] message: M(step)];

is only executed *at the time of that setup*.  So you're executing the
same collection all the time, and some of the time it's just been cleaned
out, and some of the time it's the new agents collection.

>     What would be a good way to do this synchoronous creation
>     of an entire new list of agents in pop-startGeneration,
>     followed by sending all those new agents the step message?

The start/end generation methods are a good way to bracket the overall
timestep actions.  But given that you're really doing a step on the
whole Pop object, why not provide a step message directly on it, and
let it send the individual agent step messages to whichever collection
it wants?  The Pop step method could also incorporate the start/end
generation actions merely as it's first/last statements bracketing
the step messages to each member.

Admittedly this isn't using the Swarm schedule structures to execute
each of the agent step messages, but since you're using a dynamically
switched collection that would be hard anyway.  The alternative that uses
schedules would be to remove the old ForEach action and replace it with
a new one each time the collection switches, or else change the collection
that the ForEach action refers to (there are messages on an action that
can do this).  But all this dynamic action modification may be more
trouble than it's worth if you have a case that you can control entirely
locally.

Roger Burkhart