RE: [Repast-developer] agent base interface

[Blecha, F. <Fra...@ps...>]

This sounds good; in the models I work on we require an agent to deal
with such an interface such that they do not have access to "ground
truth."

For clarification, is the "agent base interface" going to be located in
the repast code/package?

1) What about putting this in a different tier, such that RePast is the
"sim" part and XXX is the "agent" part.  Let XXX also contain the
extensions to RePast (model, displays, etc) that understand the
agent(s).  This wouldn't seem to impact repast development all that
much, it still let's ppl ignore the agent if they want, yet obtain it if
they need it.

2) Building different extensions off XXX for specific agent
ideas/environments/etc?

- Frank


> -----Original Message-----
> From: Nick Collier [mailto:nic...@ve...]
> Sent: Tuesday, February 25, 2003 6:50 AM
> To: Andy Cleary
> Cc: repast-developer; Rep...@li...
> Subject: Re: [Repast-developer] agent base interface
>=20
> I think Andy's point is an excellent one here. In the non-toy
> simulations I have written an agent's access to its "raw topology" is
> almost always mediated by some "referee." Sometimes this is a one shot
> class with no design for extensibility. In other cases, I use a
> "referee" interface, and the actual "referee" is produced via a
factory
> class. The specific type of the "referee" is usually dependent on some
> parameter in the model. The referee might have a method getNeighbor()
> and specific implementations might return a random neighbor, a "max"
> neighbor, the "most alike" neighbor or whatever. The point being that
> the referee in these cases uses the raw topology but filters it in
> someway.
>=20
> I've cc'd this to repast-interest as I think others would be
interested
> in this discussion. Please keep the thread going there.
>=20
> Nick
>=20
> On Mon, 2003-02-24 at 21:16, Andy Cleary wrote:
> > At 05:50 PM 2/24/2003 -0800, you wrote:
> >
> > >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.
> >
> > Oh, I forgot something along the lines of making agents that can be
> dropped
> > into different simulations... Since there has been discussion of the
> spaces
> > and in particular generalizing things like "getNeighbors", I thought
I'd
> > mention that the Referee pattern is another way to approach this.
> Instead
> > of having the space itself expose common functionality like
GetNeighbor,
> > this could actually be exposed in the Referee. Instead of the agents
> > directly querying the space, it could be argued that essentially
they
> are
> > trying to "see" what is around them; and that the result of that
action
> > should be dictated by the Referee. In this pattern, the agents
pretty
> much
> > interact directly only with the Referee. The Referee in turn has
access
> to
> > the other agents, the environment, the space that the agents are
> > interacting with, etc. The Referee could then expose a GetNeighbors
> > function and then choose to implement it as dictated by the
conditions
> of
> > the simulation. The implementation of the Agents doesn't change.
Now,
> > there's a sense in which this just pushes the logic for dealing with
> > different underlying spaces from one point in the code to another,
but,
> at
> > least it is in *one* point, the implementation of the Referee,
instead
> of
> > in N points, each of the agents (which, again, ideally could be
mixed
> and
> > matched from different developers, hence more code to change).
> >
> > Perhaps more thought provoking, thinking about "GetNeighbors" more
as
> some
> > sort of "see" function creates scenarios that lend themselves more
to
> the
> > Referee concept. What if there is a "wall" in between you and one of
> your
> > neighbors? Your simulation might not want you to "see" that
neighbor.
> One
> > way to implement this is to extend the particular space you are
working
> > with to include the logic of "walls", but there are a lot of reasons
to
> > prefer composition to extension here. I prefer to have the Referee
"have
> a"
> > space as they are currently implemented, and then encode extra logic
> > internally to track these "walls". Again, the Agent implementation
> doesn't
> > change: it gets some representation of what it "sees" (e.g. a list
of
> other
> > agents), and if one of its physical neighbors isn't included because
the
> > Referee determines they don't see it, so be it. Where composition
really
> > shines vs extension is in more dynamic situations: say, for example,
> that
> > the presence of one agent may "block" sight of other agents. Here,
the
> > GetNeighbors function in the referee has to encode logic looking at
the
> > location of other agents to even compute what the agent sees. To try
to
> get
> > this effect by extension of the spaces is to start having the spaces
> > themselves encode knowledge of simulation specifics like the kinds
of
> > agents, etc., which seems fairly obviously to be the wrong path.
> >
> > In general, the Referee is a useful pattern in cases where what an
agent
> > *intends* to do does not always happen, or in which the agent cannot
> > unilaterally decide what happens to it because it requires
calculations
> > involving interaction with other agents or the environment.
Underlying
> > something like "GetMooreNeighborhood" is the assumption that if an
agent
> > *wants* to get its neighborhood, it necessarily *can*. Obviously,
for
> many
> > applications, this is fine. But the interesting thing about the
Referee
> is
> > that it doesn't preclude this: one could always have a "no-op"
referee
> in
> > essence, one that allows agents to dictate what they want to do. But
by
> > using the pattern, if something comes up where you go "shoot, I
don't
> > really want the agents to be able to do that", having the the
Referee in
> > place is convenient. Again, if the same development team is writing
the
> > simulation *and* the agents, this probably doesn't come up very
much.
> But
> > when you start trying to decouple their implementation to some
extent,
> it
> > becomes more attractive. The Referee can make sure the entities
follow
> the
> > "rules" for this simulation, just in case they were written in a way
> that
> > might otherwise violate the rules.
> >
> > Cheers,
> > Andy
> >
> >
> >
> > -------------------------------------------------------
> > 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
> --
> Nick Collier
> Social Science Research Computing
> University of Chicago
> http://repast.sourceforge.net
>=20
>=20
>=20
> -------------------------------------------------------
> 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