Re: Scheduling

[Ken Cline]

On Wed, 19 Nov 1997, Thai Dinh Nguyen wrote:

> Dear fellow Swarm users:
> 
> I need help on Swarm's schedule:
> 
> 1.  In the application Heatbugs, what will happen if there are two bugs
> at (2,4) and (2,5) and both bugs pick out (2,3) as the next best spot to
> move to?  Will only one of the bug moves to this spot?  If so, will this
> be determined by which bug was first (or last) added to the bugList?

>From the Heatbug.m file:

  // Part of the heatbug simulation is that two bugs cannot be in the
  // same spot. The code to enforce that is done here: if the site we
  // want is occupied by another heatbug, move randomly. Note that
  // this code does not parallelize properly, it requires that each
  // bug be set a "step" method in sequence. This is a design flaw in
  // heatbugs: proper conflict resolution is difficult.
  // Also note we only look for 10 random spots - if we don't find an
  // unoccupied spot by then, assume it's too crowded and just don't move.

And yes, I think the bug which is first on the bugList will
be the one that gets the prefered spot.  Technically, its
the first bug on the modelSchedule, but in this case I think
both are the same.

>From the HeatbugModelSwarm.m file:

  modelActions = [ ActionGroup create: [self getZone] ];
  [ modelActions createActionTo:      heat        message: M(stepRule)      ];
  [ modelActions createActionForEach: heatbugList message: M(step)          ];
  [ modelActions createActionTo:      heat        message: M(updateLattice) ];

Note that the 3rd line creates a `step' action for the
entire budList.  The modelActions action plan uses the
default ordering of actions which I believe is a sequential
ordering.  If you changed the modelActions to use some other
type of ordering (eg randomized) then which bug picked the
best spot wouldn't necessarily be related at all to the
order of the bugList.  Check the Swarm documentation about
action plan orderings.


> 2.  In the application Mousetrap, how would I make mousetraps that have
> been triggered to keep on firing at every timestep afterward?  Would
> setting autoDrop to 0 or removing this line do it?

I'm not an expert, but I think its more complex than that.
Setting autoDrop to 0 just means actions won't be dropped
after they are processed.  It doesn't mean that they will be
scheduled to repeat.  That is, "trigger" actions are
scheduled for a particular time:

  [modelSchedule at: n createActionTo: trap message: M(trigger)];

and the modelSchedule does not have a repeat interval.

You could try to make modelSchedule a repeating schedule but
the repeat interval must be large enough to accept all
possible values of n, and I think n is approx. the number of
traps instantiated.  (Please correct me if I'm wrong,
folks.)

Possibly you could have a second, repeating schedule that
repeated some action group, triggerActions.  Then, instead
of creating a "trigger" action on the modelSchedule (as
above) you could create that action on the triggerActions.

Another approach would be to have triggered traps continue
to reschedule themselves on the modelSchedule.

Again, I'm not an expert on schedules.

Later,

Ken.


_________________________________________________________
Ken Cline                             address@hidden
SAIC                                 VOICE (410) 571-0413
Annapolis, MD                          FAX (301) 261-8427


                  ==================================
   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.
                  ==================================