Re: SWARM problems

[Doug Donalson]

Paul,

   That is a good term, "circular inclusion".  The odd thing about it is that it
only happens in certain "circles".  A real hacked up way to deal with it is to
compile twice.  Put the file that starts the chain as the 1st file to be
compiled and then comment out one of the include files farther down in the
chain.  In the first compile, the object that starts the chain will compile, and
then "make" will fail when it gets to the object that had the include file
commented out.  Then "uncomment" the include file and recompile.  The start of
the chain is already compiled, so the chain is broken, and the rest will
compile.  I have not yet run into an instance of more than one chain actually
causing a problem in my simulation.

Of course, the politically correct thing to do is Paul's method, and design your
model purely top down.  Although it is clean, it seems a shame that extra
infrastructure needs to be added to models for the sake of purity.  These are
guidelines for modeling, and must be weighed against model performence and
design considerations.  Bethoven was once asked whether parallel 5ths were
allowed in music.  He replied "no".  When the questioner pointed to a place in
one of Bethovens pieces that had them, Bethoven replied "then they are allowed".

To put it in a more modern sense, when questioned about the inclusion of a
"goto" in his code by me, the great Swarm designer, Roger Burkhart replied that
sometimes breaking the rules were necessary.

Cheers,

   D3

address@hidden wrote:

> It is not quite clear where the problem is.
>
> But, anyway, let me say this.  I encountered 2 similar issues, maybe
> these ideas will lead in a good direction.
> 1. If agents are passing things back and forth, create a separate class
> of object, embed that inside an agent, and write get and set methods so
> they can deposit their objects in places where other agents can get
> them.  My models have agents that have preferences, and preferences are
> described by instances of another kind of object. So when they say "my
> favorite is X" to one another, they do not pass themselves, they pass an
> item from the class of policy points.  That way there is no circular
> inclusion.
>
> 2.  Sometimes I've wished agents could directly message model swarm.
> ObserverSwarm can say
>        [modelSwarm getData]
> but I can't make the same work for agents like heatbugs. It causes a
> circular inclusion of the sort you describe, I think.  The solution is
> yet again to create another class of agent.  If you look in
> the heatbugs example, instead of letting agents send messages to
> modelSwarm, a heatspace is created that agents can send messages to and
> find out the state of their environment.
>
> Well, hope your project goes along nicely. When you have something,
> please consider making it available.
>
> pj
>
>
> On 24 Jun, Laurence wrote:
> > Hi,
>
> >
> > 2) At the moment, the classes are written whereby each class is explicity
> > typed. Eg. when class 'Receptor' signals class 'Enzyme_A', the receptor
> > object is given a pointer (of type Enzyme_A) in order to send a message to
> > the target.  In order to do this, the receptor class needs to include the
> > header file for 'Enzyme_a'. This is because if I make the target pointer
> > type id, I always get a compilation error.  However, I have the situation
> > where the receptor signals Enzyme_A, which in turn signals Enzyme_b, which
> > in turn signals the receptor.  By '#include'ing header files, the receptor
> > header includes the enzyme_a header, which in turn includes the enzyme_b
> > header, which in turn includes the receptor header -- hence, the receptor
> > header is including itself effectively, and an error is produced!  Help!
> > (Sorry if that doesn't read very clearly).
> >
> > Best wishes, Laurence (address@hidden)
> > ---------------------
> > http://www.csc.liv.ac.uk/~laurence
> >
> >
> >                   ==================================
> >    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.
> >                   ==================================
>
> --
> Paul E. Johnson                       email: address@hidden
> Dept. of Political Science            http://lark.cc.ukans.edu/~pauljohn
> University of Kansas                  Office: (913) 864-9086
> Lawrence, Kansas 66045                FAX: (913) 864-5700
>
>                   ==================================
>    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.
>                   ==================================



--
************************************************************************
* Doug Donalson                                          * Office: (805)
893-2962
* Ecology, Evolution, and Marine Biology   * Home:   (805) 961-4447
* UC Santa Barbara                                      * email
address@hidden
* Santa Barbara Ca. 93106                           *
************************************************************************
*
*   The most exciting phrase to hear in science, the one that
*   heralds new discoveries, is not "EUREKA" (I have found it) but
*   "That's funny ...?"
*
*       Isaac Asimov
*
************************************************************************



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