Re: one type of agent versus many...

[glen e. p. ropella]

address@hidden writes:
 > I guess the gist of my question is more like this, is it any less
 > efficent to have 100 agents of type A, 100 of B, 100 of C, 100 of D;
 > then to have just 400 of X?  Would there be any "big" overhead of
 > keeping the different types as opposed to just having one type.  If when
 > it really comes down to it, there will be the same number of agents
 > reguardless of how its done.  
 > 
 > As to the "status" question, lets say that the different agents will all
 > have a variety of attributes (right now 7), but later could be many
 > more.  All the various agents of like type will have the same values for
 > those attributes, in fact beside their name (type) and the attributes,
 > they will virtually be identical.  But, to keep all the various
 > attributes in a single agent X, seems to me to be much more overhead,
 > atleast in the creation of the agents.  Determining that 100 will have
 > A-like attributes, 100 will have B-like attributes, etc.  
 > 
 > So, while there will be more programming up front, (basically) copying a
 > single type of agent and just going in and changing the "hard-wired"
 > attributes to different values, it seems to me after that initial set-up
 > there would be less troubles later...

There are two issues here: 1) is the data structure different from
one agent to the next and 2) are the methods or behaviours different
from one agent to the next.

If the data structures are different, e.g. <x1, y1, z1, p1, q1>,
<y2, z2, q2>, etc., then to make them the same class you have to
pad some maximal data structure with nils or zeros.  Most people
will consider this enough to dictate the use of separate classes,
because it wastes memory and time (memory because every agent
will allocate the maximal amount of memory even if it only sparsely
populates it, and time because agent distinction is done by
traversing the data structure) and any similarity in methods can
be handled with subclassing. 

If the data structures are the same (i.e. all agents use the same
state table in the same way), then you have to consider the methods.
If the methods are different, you could either throw all the methods
into the same class and provide some kind of "mask" to show which
methods are available and which aren't.  Or you could put them in
separate classes.

If you throw all the methods into some monster class, then you 
could be wasting time searching the class structure for the particular
method you need, which means your decision should be based, in part,
on how many of the methods from the monster class any agent will be
using.  So, I think most people would put them in separate classes.

Another benefit to using separate classes if the methods are different
and the data structures are the same, and if your methods depend in
some way on cuts in the configuration space for the data structure,
you can embed these cuts in your methods, instead of waiting
until runtime to decide how the method will function.  This takes
more memory because you have more distinguishable precompiled methods,
but saves on execution speed.

Was this too rambly? <grin>

glen
-- 
{glen e. p. ropella <address@hidden> |  Send lawyers, guns, and money!  }
{Hive Drone, SFI Swarm Project         |            Hail Eris!            }
{http://www.trail.com/~gepr/home.html  |               =><=               }

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