Re: [SL] In search of a StarLogo methodology

[EMERGE_sl_users@umit.maine.edu (Larry Latour) (by way of Vanessa Colella <EMERGE_sl_users@umit.maine.edu>)]

gjbalzano@ucsd.edu,.Internet writes:
>I have been tussling with a problem that I feel ought to have a general
>solution, so let me try to formulate the problem and see what more
>knowledgeable others might think.

>Suppose you have two breeds (species), and you want to give breed A some
>extra capacity or behavior that you think will give them a competitive
>advantage over breed B, where "competitive advantage" is some function
>of a
>creature's ability to find and use "resources" that are distributed over
>the patches in their environment.  So far, so good.  But doesn't the
>following problem potentially arise: the extra code or processing
>required
>to give members of breed A the putatively advantageous behavior will
>take
>time, time during which the B breed can be happily gobbling up limited
>resources.  So, as with other postings to this list, my question seems
>to
>be one of how to deal with the pseudo-parallelism in SL.  How do I
>organize
>or arrange the code for breeds A and B in this kind of example in a way
>that will ensure that an artifactual disadvantage for breed A will not
>arise?

This problem is releated to one I've seen repeatedly with my colleagues
in the modeling community - to what extent is observable model behavior
attributable to the phenomemon under study, and to what extent is it an
artifact of the implementation?

Consider the following example in Starlogo: suppose I define two
breeds, then create 200 of the first breed followed by 200 of the
second.  The scheduler in Starlogo first runs through all of the first
breed, then all of the second breed.  Suppose each member of a breed
takes energy from a member of the other breed when it bumps into it. 
If I get an oscillation in energy from breed  population 1 to breed pop
2 and then back again, is it because of a property inherent in the
system, or is it because of the scheduler? Sometimes this is obvious to
see, sometimes not.  The trick is to be able to factor this
implementation dependent stuff out when analyzing model behavior.

A solution: I created 200 turtles first, then assigned breeds randomly
as follows:
    ifelse ((random 2) = 0) [setbreed 1][setbreed 2]  
This "mixes up" the order of the breeds to try to (I emphasize "try
to") avoid patterns caused by the scheduler.

As another example, watch the MIT rabbits simulation (in the Starlogo
2.0.2 distribution sample projects).  The system runs tremendously fast
when there are only a few rabbit turtles, but slower when there are a
large number of them.  Normally the number of rabbits shouldn't affect
the speed of an individual.  What if you plot the population change and
notice a sharper change when there are less rabbits than when there are
more?  Is this due to anything but simply the amount of processor time
each rabbit gets?

A solution: pre-allocate a fixed population of rabbits, some alive,
some dead.  Turtles then simply are in a living or dead state, and are
changed according to a user-implemented birth and death operation - in
other words, manage the living and dead pools yourself.   This still
doesn't avoid the problem of some turtles moving along at different
speeds depending on the decisions they make (as in your case).  You
could use the comma (,) command to synchronize each iteration of all of
the living and dead turtles to make sure they all execute an equal
number of iterations.

My two cents.

Larry Latour
UMaine CS Dept.