swarm in object in object: where to put observer

[glen e. p. ropella]

pagie> Hi all, raising (slowly) from lurker3 to lurker4 I just
pagie> wondered (don't know yet if this will become a 'real' problem);

It's a real modelling problem.  Probably not a real programming
problem.

pagie> Suppose you build a model in which the top-level swarm contains
pagie> an object, which contains another object, which contains
pagie> another object, which contains a swarm (of objects). Now who
pagie> should hold the observer for the last swarm.

pagie> Obviously not the last object; 'agents' should not contain
pagie> observer-tools.  But (obviously ?) also not the top-level
pagie> swarm, that would lead to problems in the maintainance, etc.

pagie> Does a design principle exist for this sort of construct?

We've thought about this recently.  But, no satisficing conclusion
was reached.  I tend to think that there should be a clear line
between the Observer and the Model, which is not the case in
demos like heatbugs, mousetrap, etc.  In general, there should
probably be an entire hieararchy of instrumentation separate
from an entire hierarchy of model-specific constructs.  So, what
I imagine is something like:

          ObserverHier              ModeHier
               |                       |
               |                       |
             Swarm --------------->  Swarm
               |     |               / | \
               |     |              /  |  \
               |     +--------->   O1 O2  O3 ...
               |                           |
               |                           |
             Swarm ------------------->  Swarm
               |     |                  /  |  \
               |     |                 /   |   \
               |     +------------>  O1   O2   O3 ...
               |                    /      |
               |                   /       |
             Swarm              Swarm    Swarm

                      etc.


This is only different from our current demos in that some
of the observer functions (like designing probemaps and self
drawing) are taking place in the model.  There is one other
"programming" type detail that really confuses this issue....
that is that the observerSwarm/modelSwarm instantiation process
is this three part depth-first recursion scheme.  I.e. One
first creates the ObserverSwarm, then does buildObjects, which
does buildObjects in the modelSwarm.  Then one does buildActions
on the observerSwarm, which calls buildActions on the modelSwarm.
Then one does a activateIn on the observerSwarm, which calls
activateIn on the modelSwarm.

It gets a little confusing if you try to create more than one 
set of observer/model swarms.  I suggest flattening out this
recursion.  One still has to watch which objects are created
and depend on the existence of other objects and such; but, 
it's probably best to avoid the recursion, if possible.

glen

-- 
+-------------------------------------------------------------------------+
|glen e. p. ropella (address@hidden) |                                  |
|Hive Drone, SFI Swarm Project         |            Hail Eris!            |
|http://www.trail.com/~gepr/home.html  |                                  |
+-------------------------------------------------------------------------+