|
From: Stephen C. U. <up...@mi...> - 2003-02-25 08:09:51
|
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 |