Re: Help on walking lists of Swarm Collection

[William S. Shu]

>WS> for (i = 0; i < count; ++i) {
>WS>   cly = [colonyList atOffset: i];
>
>You don't want to do this.  Since List is a linked list, finding the
>ith with atOffset: item requires iterating through from the beginning.
>The result will be that processing all the colonies will slow as the
>square of the count.


Yes.  I found the simulation frustratingly slow, especially when I have to
do a:
    count = [colonyList getCount]
 in a loop, just in case the count changed!  And I have many such loops!

>If dropDead has the side effect of touching the List, the Index will
>break, and you'll probably get a segfault.
>
>Conceptually, I don't think it is clean to have agents touching global
>bookkeeping data structures.  I mean, unless it is a suicide or a
>terminal illness, people don't generally cancel their utilities and
>fill out their own death certificates, etc.  Instead, a death causes a
>disruption and society makes the necessary adaptations.

I agree, but probably if I explain what I am trying to do more precisely,
you may be able to make alternative suggestions.  I am developing a template
to capture the interactions in malaria.  populations (of a subclass of the
class Population) of malaria parasites migrate from person to mosquito and
mosquito to person.  The malaria populations have their own dynamics
(behaviour) which depends also on its current host.  They have their own
swarm -- just as persons and mosquitoes have their own swarm and exhibit
their own behaviour.

A person or mosquito may have a number of such populations (for whatever
reason) and hence we put them in the person or mosquito's colonyList (the
list of all population colonies it has).  When a person is bitten, a
population (or part thereoff) may be transferred to the mosquito.

In computing terms, a colony list holds pointers to populations, and each
population has a *single* pointer to its current host.  So when a population
migrates to a new host, it has to come off the colonyList of the one to get
into that of the other.  Hence we fiddle with the colonyList.

Now, when a mosquito or person dies, the populations in them die, and so we
remove them from further interactions in given ways.

In computing terms, I minimise trouble by removing the above pointers (and
more), so other agents (mosquito, person or malaria) do not interact with
dead things.  However, following the reaperQueue example of sugarScape
(sss-1.3.1), I let each swarm destroy (physically remove datastructures) its
own agents.  But each agent when dead (or dying) has to break off all
"relationships" with others (by removing pointers, say) so that they (or it)
do not inadvertently try to use them!

We cannot just leave it to a "master Undertaker", as even dead agents may be
of interest to some yet-to-be-defined agent (Coroner?).  Moreover, such an
undertaker would have the extra burden of deciding which relationships are
valid (c.f. Coroner-deadman inquest) and which are not.

Besides, in computing terms, many coding bugs get introduced if a clear and
simple strategy is not used in handling "relationships".

I hasten to add that dying is not the only cause for breaking relationships
(c.f. change of hosts above).  Whatever the case, it must ensure a severed
relationship is indeed severed.

Hope this helps explain my predicament, and why I wished so much for a
robust list with their own "next" methods!

Thanks,


William.



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