Nested Swarms and Schedules

[Benedikt Stefansson]

Hi,

I've been assisting a new Swarm devotee to implement an Iterated
Prisoners Dilemma (IPD) simulation which will be used for pedagogical
purposes. We ran across an interesting problem & limitation of
schedules. I'd like to solicit some comments on:
     a) whether I've overlooked some obvious trick to solve the problem
     b) how this reflects on the usability of the scheduling mechanism

The IPD implementation is pretty standard: Agents live in a "soup". Each
agent is assumed to have four nearest neighbors (randomly selected) and
plays a tournament of four iterated PD stage-games with each neighbor.
When all agents have played out their four "tournaments" we count
payoffs and "evolve" the population - strategies are replicated in
proportion to their relative aggregate payoff.

The programmer decided to create a special tournament object with its
own schedule to implement each match between pairs of agents. So the
ModelSwarm creates one tournament sub-swarm after another. Each of these
in turn creates a schedule and action group which schedule internal
events (the four PD stage games between the two players). A stop
schedule terminates the activity for the tournament sub-swarm, we then
drop both schedules, the action group and the tournament object.

The problem is that we want the ObserverSwarm to sit there and wait
until the whole generation has played out its tournaments - and then to
plot the aggregate scores for each strategy type. But because the
sub-sub-swarms (tournaments) are employing the activity mechanism to
schedule events, the global clock is advanced by 4 x 4 x N timesteps
each generation. The ObserverSwarm thus needs to know how many agents
there are, how often they interact etc. to update graphs correctly -
which runs against the whole Observer - Model dichotomy.

The solutions I have thought of are:
    a) Don't use schedules in the tournament, do all with for-next loops
(but this means that schedules have limited use for sims when there are
major nesting of Swarms)

    b) Update the ObserverSwarm every 4 x 4 x N time steps. This would
go against the Observer - Model dichotomy, also aggregate clock is still
advanced by 4 x 4 x N time steps, and what about dynamic populations
(variable N?)

    c) Update Observer from the Model after tournaments have run, same
criticism holds as in b.

The question is: How would one go about freezing the aggregate clock,
running the internal sequence of tournaments and then evolving to the
next generation, without abandoning the activity mechanism altogether?

I can't think of any easy way to do that, but I was hoping that I was
overlooking an obvious solution.

By the way, in some of the early mission statements for Swarm and in my
own tutorial we depict virtual clocks in each sub-Swarm which are
supposed to run "on their own time." This is a perfect example of where
this would apply.

Regards,
-Benedikt

------------------
Benedikt Stefansson                 address@hidden
Department of Economics, UCLA       Fax. (310) 825-9528
Los Angeles, CA 90095-1477          Tel. (310) 825-1777



                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.