Re: [Repast-developer] agent base interface

[Stephen C. U. <up...@mi...>]

Andy,

Attached is a report I contributed to when I was working at LANL. Your referee
is very similar to our class of what we called Arbitrators. We had considered
using Arbitrators as a completely general class, i.e., for all agent-agent and
agent-environment interactions, but came to the conclusion that doing so would
be very expensive. However, as you've pointed out, you could do a lot by just
plugging-n-playing different components depending on what you want to model.
Might still be expensive, but might also be a good trade depending on you
wanted to model.

HTH
steve

Andy Cleary wrote:

> [note to self: replies to email lists work better when you make sure they
> go to the *list* instead of the author of the last post... DOH!]
>
> At 02:20 PM 2/23/2003 -0500, you wrote:
> >In my model, I apply a different encapsulation of functionality, my
> >solution tends to rely heavily on a class I call Landscape.  Landscape is
> >a "wrapper" around an agentList, agentGrid, habitatGrid, and Birth queue
> >(like those found in SugarModel). My Agents encapsulate their own
> >"dispersal capabilites" and use methods available in the landscape wrapper
> >to move, the landscape also wraps the capability to add an agent to the
> >"grid/agentList" into a single method.
> >
> >Movement rules are defined in the agent, the ablitiy to move is done by
> >calls to landscape.moveAgentTo(agent,x,y). Agents are capable of
> >reproducing new agents, which is done by the parent agent creating a new
> >agent and letting it "disperse" from the point of the parent agent, if
> >successful, it is added to the landscape at that point. Birth and Death
> >are done by updating the landscape at the end of an iteration, which
> >clears all "dead" agents and adds all the new agents in the birthQueue to
> >the agentList.
> >
> >With my current strategy, I like the fact that the behavior for addition,
> >"alteration of position" and removal of agents is encapsulated in the
> >Landscape "wrapper" itself. One can write different Landscapes to get
> >different updating behaviors, one can write new agents with different
> >movement rules, survivorship and reproduction capabilites. While
> >"decisions agents can make" are encapsulated in the agent,  the methods of
> >the landscape solidify the "update" environments rules and keep them "out
> >of reach" of the agents themselves.
> >
> >-Mark
>
> On the subject of "ABM design patterns", this matches one that I have
> internally been calling the "Referee" design pattern. The idea in this
> pattern is to separate the decision of what agents want to do from the
> determination of what actually happens. The "Referee" is an object that
> sits between the agents and other agents and the environment that
> determines resolution of conflicts if you will. Here, the Landscape seems
> to play this role almost exactly, and Mark's reasons for the Landscape
> match my own thinking pretty much exactly (I'll leave it to Mark to decide
> if resembling my thinking is a good thing or not... ;-)
>
> A canonical example to me is conservation: if agent A and agent B
> simultaneously do something that would result in an exchange of something
> between them and that exchange must not violate conservation (e.g. one gets
> 20 bucks but the other gives 10 is a bad thing), a referee may be a nice
> way to ensure (insure?) conservation. Instead of either A or B determining
> unilaterally what they think happens in the transfer, they "submit their
> case" to the referee, who then informs them of the results, thus
> guaranteeing that they both "see" the same amount being transferred.
>
> As Mark says, the pattern works well to separate the decision making of
> agents from the "resolution" of the physics or other rules of interaction
> that the simulation is interested in. I submit that this is one step
> towards making agents more interchangeable from simulation to simulation
> (IOW, making it more likely that agents created by one team may be plugged
> into a simulation created by another): the agents just make decisions, but
> the choice of what those decisions actually *do* is encapsulated in the
> referee. Within broad limits, agents may be able to function reasonably
> well in a variety of different but somewhat related simulations. I also
> think this pattern helps the modeler try to determine the drivers of their
> system: they can run the simulation with different factors turned on and
> off just by changing the referee, instead of having to go back and change
> all of the agents themselves as they have to do if the "physics" is encoded
> in the agents themselves, and by doing so they can get a feel for which
> "rules" are the ones that truly drive their system, and which others are
> pretty superfluous. If you have a simulation of a bunch of particles flying
> around, say, is air friction is important? Well, run it twice, one with air
> friction turned on in the referee, one with it turned off, and compare the
> results. If they look similar, air friction probably wasn't a driver at
> this level of the system...
>
> So I'm wondering if anyone else uses such a pattern wherein the "rules" are
> encapsulated in a single object and the agents themselves concentrate only
> on maintaining their own internal state and making their own decisions?
>
> Cheers,
> Andy
>
> ============================================
> Andrew J. Cleary, Software Engineer/Computational Scientist
> Lawrence Livermore National Labs, 925-424-5890.
> ============================================
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Repast-developer mailing list
> Rep...@li...
> https://lists.sourceforge.net/lists/listinfo/repast-developer