repast-developer

Re: [Repast-developer] uchicago.src.sim.network.DefaultEdge.strength

[Nick C. <nic...@ve...>]

This is a bug. They should probably all be floats.

Nick

On Tue, 2003-02-25 at 13:21, Micha=B3 Jele=F1 wrote:
> Hello.
>=20
> Just one question - it's interesting for me, why DefaultEdge.strength is
> 'double' type,
> but constructor for DefaultEdge takes 'just' float type ?
>=20
> DefaultEdge(Node from, Node to, String label, float strength)
>=20
> Moreover, we have method:
> DefaultEdge.setStrength(double val)
> Now, with 'double' type...
>=20
>=20
> Thank you for your attention 8) and answers.
> Michal Jelen
>=20
>=20
>=20
>=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
--=20
Nick Collier=20
Social Science Research Computing=20
University of Chicago=20
http://repast.sourceforge.net

[Repast-developer] uchicago.src.sim.network.DefaultEdge.strength

[<M....@el...>]

Hello.

Just one question - it's interesting for me, why DefaultEdge.strength is
'double' type,
but constructor for DefaultEdge takes 'just' float type ?

DefaultEdge(Node from, Node to, String label, float strength)

Moreover, we have method:
DefaultEdge.setStrength(double val)
Now, with 'double' type...


Thank you for your attention 8) and answers.
Michal Jelen

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

Re: [Repast-developer] agent base interface

[Nick C. <nic...@ve...>]

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. 

I've cc'd this to repast-interest as I think others would be interested
in this discussion. Please keep the thread going there.

Nick

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

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

Re: [Repast-developer] agent base interface

[Andy C. <ac...@ll...>]

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

[Repast-developer] agent base interface

[Andy C. <ac...@ll...>]

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

Re: [Repast-developer] Slight addition to ThinController

[Nick C. <nic...@ve...>]

Thanks for this. I read it quickly, and it seems like a good
unification. I'll have to check whether it is possible to unify begin(),
display() etc. under this one method. Last time you asked it wasn't.
After the refactoring of the controller hierarchy this should now,
hopefully, be feasible, so thanks for bringing it up. 

As for exit(). This is a bug, I think. There used to be a flag for
really exiting or just shutting down repast on exit. I think I moved
this too far up up the hierarchy during the refactoring and so its no
longer available to thin controller. I'll push it back down. This does
raise the question though of what should supplied by repast and what
should be overridden by a user in a child class. exit() is not an
example of this however.

Nick

On Fri, 2003-02-21 at 13:03, Mark R. Diggory wrote:
> Nick,
> 
> I've added an extra method to the version of ThinController I am using 
> currently, I think it would be a nice addition to the class itself. 
> Specifically, I am providing an "initSim()" method, analogous to 
> "begin()" in the BatchController. This method provides just enought 
> rudimentary threading control to get the simulation launched in a new 
> Thread and wait for it to complete. I did this so I would not need to do 
> "thread management" in my taglibrary wrapper for the controller and I 
> can just rely on the threading available in the ThinController to get 
> the simulation started and wait until its finished before returning from 
> the initSim method. This should allow my taglibrary to support any 
> controller. (as you can see by my examples: models/cagn and models/simple).
> 
> However, I still find myself having to call different methods to get the 
> controller "initialized". Consolidating 
> Controller.display(),BatchController.begin() and 
> ThinController.initSim() into one standard method in the IController 
> interface would provide for a consistent way to initialize the 
> controller across all controllers. It could be backward compatable for 
> the time being by just creating an initSim method in the IController and 
> BaseController,  then overriding it in Controller and BatchController 
> with calls to display or begin. Eventually, 
> uchicago.src.sim.engine.SimInit could be modified to use the new initSim 
> method and there would no longer be the need to determine what type the 
> controller was just to get it initialized/running. I think we had 
> discussed this before, though I can't recall your response.
> 
> If ThinController.initSim() seems like the "wrong" name for this method, 
> I'm not attached to it.
> 
> One other thing, in this situation I find the System.exit() call in the 
> ThinController.exitSim() results in the shutdown of the entire JVM, if 
> I'm using it in the Jelly env. where I might want to do post processing 
> after the  exitSim occurs I loose the JVM instance before I can do those 
> things. I've been commenting it out in my version. Since it is a method 
> available from "System" I'm concerned about it being in the Controller, 
> specifically because, if the user of ThinController is either doing 
> thier own Thread Management or relying on initSim() for this, they can 
> decide if they want to do a System.exit() after exitSim occures in thier 
> code. Having it in the exitSim method, they loose that flexibility.
> 
> Thanks
> -Mark
> ----
> 

> /**
>  * Provides minimal (thin) controller support for running a simulation.
>  * ThinController is intended to provide batch-like non-gui programmatic control over
>  * a simulation for those who want to do batch type runs without using
>  * RePast's batch run mechansim. Thin controller thus provides methods to
>  * start, stop, pause and exit a simulation, but virtually nothing else. In
>  * particular loading parameters into a model is not done here. Loading
>  * parameters using some sort of custom parameter file or mechanism will have
>  * to be done elsewhere.<p>
>  *
>  * ThinController can be used in conjuntion with a tool like Drone (drone.sf.net)
>  * where an instance of the model and a controller are created for each run
>  * of the model. The main method of a model might then look like:
>  * <pre><code>
>  *  public static void main( String[] args ) {
>  *    MyModel model = new MyModel();
>  *    ThinController controller = new ThinController();
>  *    model.setController(controller);
>  *    controller.setExitOnExit(true);
>  *    controller.setModel(model);
>  *    model.addSimEventListener(controller);
>  *    // custom parameter loading here ...
>  *    ...
>  *    control.startSimulation();
>  * }
>  * </code></pre>
>  *
>  * @version $Revision: 1.7 $ $Date: 2003/01/03 16:41:04 $
>  *
>  */
> package uchicago.src.sim.engine;
> 
> public class ThinController extends BaseController {
> 
>   protected volatile boolean finished = false;
>   
>   private Object appMonitor = new Object();
>     
>   protected boolean isGui;
> 
>   /**
>    * Creates a ThinController, specifying whether this is a graphical controller
>    * or not. The isGui parameter only determines what value is returned by the
>    * isGUI method, nothing more.
>    *
>    * @param isGui whether or not this ThinController will identify itself as
>    * a gui controller or not
>    */
>   public ThinController(boolean isGui) {
>     super();
>     this.isGui = isGui;
>   }
> 
>     /* Gives just enough rudimentary threading control to launch the sim in a 
>      * new thread
>      */
>     public void initSim() {
>         Runnable control = new Runnable() {
>             public void run() {
>                 startSim();
>                 while (!finished) {
>                     synchronized (monitor) {
>                         while (!runFinished) {
>                             try {
>                                 monitor.wait();
>                             } catch (InterruptedException ex) {
>                             }
>                         }
>                     }
>                     
>                     stopSim();
>                     finished = true;
>                     
>                 }
>                 synchronized (appMonitor) {
>                     appMonitor.notify();
>                 }
>             }
>         };
>         
>         Thread t = new Thread(control);
>         t.start();
>         synchronized (appMonitor) {
>             while (!finished) {
>                 try {
>                     appMonitor.wait();
>                 } catch (InterruptedException ex) {
>                 }
>             }
>         }
>         exitSim();
>     }
>     
>   /**
>    * Exits a simulation.
>    */
>   public void exitSim() {
>     stopSim();
>     if (runThread != null) {
>       runThread.interrupt();
>       try {
>         runThread.join();
>       } catch (InterruptedException ex) {
>         System.out.println("Interrupted");
>       }
>     }
> 
>     fireSimEvent(new SimEvent(this, SimEvent.END_EVENT));
>     /* not so good a decision when the controller exists in the root thread of
>      * JVM, users may want to exit the sim without shutting down the JVM
>      */
>     //System.exit(0);
>   }
> 
>   protected void onTickCountUpdate() {}
> 
>   /**
>    * Listens for SimEvents and responds accordingly.
>    * @param evt
>    */
>   public void simEventPerformed(SimEvent evt) {
>     if (evt.getId() == SimEvent.STOP_EVENT) {
>       stopSim();
>     } else if (evt.getId() == SimEvent.END_EVENT) {
>       exitSim();
>     } else if (evt.getId() == SimEvent.PAUSE_EVENT) {
>       pauseSim();
>     }
>   }
> 
>   /**
>    * Returns true if this ThinController is a gui controller. The actual
>    * value returned depends the value passed to the contructor.
>    */
>   public boolean isGUI() {
>     return isGui;
>   }
> 
>   /**
>    * Returns true if this ThinController is a batch controller. The actual
>    * value returned depends the value passed to the contructor.
>    */
>   public boolean isBatch() {
>     return !isGui;
>   }
> 
>   /**
>    * Always returns 1.
>    */
>   public long getRunCount() {
>     return 1;
>   }
> }
> 
-- 
Nick Collier 
Social Science Research Computing 
University of Chicago 
http://repast.sourceforge.net

Re: [Repast-developer] Slight addition to ThinController

[Thomas R. H. <th...@sr...>]

That makes sense to me (making the name of the "start/init" method
consistent across controllers.  I'll say this, the System.exit(0) at in
exitSim has caused me problems as well.

-Tom

On Fri, 2003-02-21 at 12:03, Mark R. Diggory wrote:
> Nick,
> 
> I've added an extra method to the version of ThinController I am using 
> currently, I think it would be a nice addition to the class itself. 
> Specifically, I am providing an "initSim()" method, analogous to 
> "begin()" in the BatchController. This method provides just enought 
> rudimentary threading control to get the simulation launched in a new 
> Thread and wait for it to complete. I did this so I would not need to do 
> "thread management" in my taglibrary wrapper for the controller and I 
> can just rely on the threading available in the ThinController to get 
> the simulation started and wait until its finished before returning from 
> the initSim method. This should allow my taglibrary to support any 
> controller. (as you can see by my examples: models/cagn and models/simple).
> 
> However, I still find myself having to call different methods to get the 
> controller "initialized". Consolidating 
> Controller.display(),BatchController.begin() and 
> ThinController.initSim() into one standard method in the IController 
> interface would provide for a consistent way to initialize the 
> controller across all controllers. It could be backward compatable for 
> the time being by just creating an initSim method in the IController and 
> BaseController,  then overriding it in Controller and BatchController 
> with calls to display or begin. Eventually, 
> uchicago.src.sim.engine.SimInit could be modified to use the new initSim 
> method and there would no longer be the need to determine what type the 
> controller was just to get it initialized/running. I think we had 
> discussed this before, though I can't recall your response.
> 
> If ThinController.initSim() seems like the "wrong" name for this method, 
> I'm not attached to it.
> 
> One other thing, in this situation I find the System.exit() call in the 
> ThinController.exitSim() results in the shutdown of the entire JVM, if 
> I'm using it in the Jelly env. where I might want to do post processing 
> after the  exitSim occurs I loose the JVM instance before I can do those 
> things. I've been commenting it out in my version. Since it is a method 
> available from "System" I'm concerned about it being in the Controller, 
> specifically because, if the user of ThinController is either doing 
> thier own Thread Management or relying on initSim() for this, they can 
> decide if they want to do a System.exit() after exitSim occures in thier 
> code. Having it in the exitSim method, they loose that flexibility.
> 
> Thanks
> -Mark
> 
> ______________________________________________________________________
> 
> /**
>  * Provides minimal (thin) controller support for running a simulation.
>  * ThinController is intended to provide batch-like non-gui programmatic control over
>  * a simulation for those who want to do batch type runs without using
>  * RePast's batch run mechansim. Thin controller thus provides methods to
>  * start, stop, pause and exit a simulation, but virtually nothing else. In
>  * particular loading parameters into a model is not done here. Loading
>  * parameters using some sort of custom parameter file or mechanism will have
>  * to be done elsewhere.<p>
>  *
>  * ThinController can be used in conjuntion with a tool like Drone (drone.sf.net)
>  * where an instance of the model and a controller are created for each run
>  * of the model. The main method of a model might then look like:
>  * <pre><code>
>  *  public static void main( String[] args ) {
>  *    MyModel model = new MyModel();
>  *    ThinController controller = new ThinController();
>  *    model.setController(controller);
>  *    controller.setExitOnExit(true);
>  *    controller.setModel(model);
>  *    model.addSimEventListener(controller);
>  *    // custom parameter loading here ...
>  *    ...
>  *    control.startSimulation();
>  * }
>  * </code></pre>
>  *
>  * @version $Revision: 1.7 $ $Date: 2003/01/03 16:41:04 $
>  *
>  */
> package uchicago.src.sim.engine;
> 
> public class ThinController extends BaseController {
> 
>   protected volatile boolean finished = false;
>   
>   private Object appMonitor = new Object();
>     
>   protected boolean isGui;
> 
>   /**
>    * Creates a ThinController, specifying whether this is a graphical controller
>    * or not. The isGui parameter only determines what value is returned by the
>    * isGUI method, nothing more.
>    *
>    * @param isGui whether or not this ThinController will identify itself as
>    * a gui controller or not
>    */
>   public ThinController(boolean isGui) {
>     super();
>     this.isGui = isGui;
>   }
> 
>     /* Gives just enough rudimentary threading control to launch the sim in a 
>      * new thread
>      */
>     public void initSim() {
>         Runnable control = new Runnable() {
>             public void run() {
>                 startSim();
>                 while (!finished) {
>                     synchronized (monitor) {
>                         while (!runFinished) {
>                             try {
>                                 monitor.wait();
>                             } catch (InterruptedException ex) {
>                             }
>                         }
>                     }
>                     
>                     stopSim();
>                     finished = true;
>                     
>                 }
>                 synchronized (appMonitor) {
>                     appMonitor.notify();
>                 }
>             }
>         };
>         
>         Thread t = new Thread(control);
>         t.start();
>         synchronized (appMonitor) {
>             while (!finished) {
>                 try {
>                     appMonitor.wait();
>                 } catch (InterruptedException ex) {
>                 }
>             }
>         }
>         exitSim();
>     }
>     
>   /**
>    * Exits a simulation.
>    */
>   public void exitSim() {
>     stopSim();
>     if (runThread != null) {
>       runThread.interrupt();
>       try {
>         runThread.join();
>       } catch (InterruptedException ex) {
>         System.out.println("Interrupted");
>       }
>     }
> 
>     fireSimEvent(new SimEvent(this, SimEvent.END_EVENT));
>     /* not so good a decision when the controller exists in the root thread of
>      * JVM, users may want to exit the sim without shutting down the JVM
>      */
>     //System.exit(0);
>   }
> 
>   protected void onTickCountUpdate() {}
> 
>   /**
>    * Listens for SimEvents and responds accordingly.
>    * @param evt
>    */
>   public void simEventPerformed(SimEvent evt) {
>     if (evt.getId() == SimEvent.STOP_EVENT) {
>       stopSim();
>     } else if (evt.getId() == SimEvent.END_EVENT) {
>       exitSim();
>     } else if (evt.getId() == SimEvent.PAUSE_EVENT) {
>       pauseSim();
>     }
>   }
> 
>   /**
>    * Returns true if this ThinController is a gui controller. The actual
>    * value returned depends the value passed to the contructor.
>    */
>   public boolean isGUI() {
>     return isGui;
>   }
> 
>   /**
>    * Returns true if this ThinController is a batch controller. The actual
>    * value returned depends the value passed to the contructor.
>    */
>   public boolean isBatch() {
>     return !isGui;
>   }
> 
>   /**
>    * Always returns 1.
>    */
>   public long getRunCount() {
>     return 1;
>   }
> }
-- 
Tom Howe
Social Science Research Computing
University of Chicago

[Repast-developer] Slight addition to ThinController

[Mark R. D. <mdi...@la...>]

Nick,

I've added an extra method to the version of ThinController I am using 
currently, I think it would be a nice addition to the class itself. 
Specifically, I am providing an "initSim()" method, analogous to 
"begin()" in the BatchController. This method provides just enought 
rudimentary threading control to get the simulation launched in a new 
Thread and wait for it to complete. I did this so I would not need to do 
"thread management" in my taglibrary wrapper for the controller and I 
can just rely on the threading available in the ThinController to get 
the simulation started and wait until its finished before returning from 
the initSim method. This should allow my taglibrary to support any 
controller. (as you can see by my examples: models/cagn and models/simple).

However, I still find myself having to call different methods to get the 
controller "initialized". Consolidating 
Controller.display(),BatchController.begin() and 
ThinController.initSim() into one standard method in the IController 
interface would provide for a consistent way to initialize the 
controller across all controllers. It could be backward compatable for 
the time being by just creating an initSim method in the IController and 
BaseController,  then overriding it in Controller and BatchController 
with calls to display or begin. Eventually, 
uchicago.src.sim.engine.SimInit could be modified to use the new initSim 
method and there would no longer be the need to determine what type the 
controller was just to get it initialized/running. I think we had 
discussed this before, though I can't recall your response.

If ThinController.initSim() seems like the "wrong" name for this method, 
I'm not attached to it.

One other thing, in this situation I find the System.exit() call in the 
ThinController.exitSim() results in the shutdown of the entire JVM, if 
I'm using it in the Jelly env. where I might want to do post processing 
after the  exitSim occurs I loose the JVM instance before I can do those 
things. I've been commenting it out in my version. Since it is a method 
available from "System" I'm concerned about it being in the Controller, 
specifically because, if the user of ThinController is either doing 
thier own Thread Management or relying on initSim() for this, they can 
decide if they want to do a System.exit() after exitSim occures in thier 
code. Having it in the exitSim method, they loose that flexibility.

Thanks
-Mark

RE: [Repast-developer] Schedule question

[North, M. <no...@an...>]

All:

Nick's description of the results from scheduling events in the past or
present is correct.  Creating error log entry for improperly scheduled
events might be the thing to do.  Doing more than this could break backwards
compatibility.

Mike

Michael J. North
Deputy Director and Software Engineer
Center for Complex Adaptive Systems Simulation
Argonne National Laboratory
Decision and Information Sciences Division
 
9700 S. Cass Avenue
Argonne, IL 60439

E-mail: no...@an...
WWW: http://www.cas.anl.gov/
Telephone: (630) 252-6234
Facsimile: (630) 252-6073


-----Original Message-----
From: Nick Collier [mailto:nic...@ve...] 
Sent: Friday, February 14, 2003 7:46 AM
To: Andy Cleary
Cc: repast-developer
Subject: Re: [Repast-developer] Schedule question

The short answer is that actions that are scheduled during the current
tick to execute either at or before the current tick are not added to
the queue. The point being that it is incoherent to allow the present to
influence the past, but I'm not clear in my mind whether this should be
considered a "mistake" on the part of the programmer.

And so, the real question here is whether the user should be warned
about this. At the moment she is not, and I had good reasons for this at
one time, or at least I remember thinking about it and deciding for no
warning. I'm not sure about this now. For example, suppose you have a
simulation that does some complicated scheduling such that some
scheduling targets are missed and actions get scheduled for the past.
You are modeling this sort of error and in this case you wouldn't want
repast to throw an exception. However, now I'm thinking that modeling
this sort of error should be handled in the model and not allowed in
repast itself. Comments, suggestions?

Nick

On Thu, 2003-02-13 at 18:17, Andy Cleary wrote:
> So, what would happen if one scheduled an action for the same time that
the 
> action currently being executed is scheduled for? Whatever the answer, is 
> it an intended or unintended result?
> 
> My guess from look at ScheduleBase is that there would be a problem... but

> *perhaps* what would happen is that ScheduleBase would first come into the

> current tick, collect up all of the actions at the current tick, loop over

> them, and if in the course of looping over those actions new actions were 
> added for that same tick, when the scheduler got to the end of the first 
> group of actions, it would then just see the same "tick" as the tick at
the 
> top of the priority queue and repeat the same loop.
> 
> I realize there are valid questions about whether one should even be 
> *allowed* to do this, but in the meantime, I'm just wondering what the 
> designers think should happen with a tiny bit of explanation...
> 
> Best,
> Andy
> 
> ============================================
> Andrew J. Cleary, Software Engineer/Computational Scientist
> Lawrence Livermore National Labs, 925-424-5890.
> ============================================
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
> are you planning your Web Server Security? Click here to get a FREE
> Thawte SSL guide and find the answers to all your  SSL security issues.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
> _______________________________________________
> 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



-------------------------------------------------------
This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your  SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
_______________________________________________
Repast-developer mailing list
Rep...@li...
https://lists.sourceforge.net/lists/listinfo/repast-developer

Re: [Repast-developer] Schedule question

[Nick C. <nic...@ve...>]

The short answer is that actions that are scheduled during the current
tick to execute either at or before the current tick are not added to
the queue. The point being that it is incoherent to allow the present to
influence the past, but I'm not clear in my mind whether this should be
considered a "mistake" on the part of the programmer.

And so, the real question here is whether the user should be warned
about this. At the moment she is not, and I had good reasons for this at
one time, or at least I remember thinking about it and deciding for no
warning. I'm not sure about this now. For example, suppose you have a
simulation that does some complicated scheduling such that some
scheduling targets are missed and actions get scheduled for the past.
You are modeling this sort of error and in this case you wouldn't want
repast to throw an exception. However, now I'm thinking that modeling
this sort of error should be handled in the model and not allowed in
repast itself. Comments, suggestions?

Nick

On Thu, 2003-02-13 at 18:17, Andy Cleary wrote:
> So, what would happen if one scheduled an action for the same time that the 
> action currently being executed is scheduled for? Whatever the answer, is 
> it an intended or unintended result?
> 
> My guess from look at ScheduleBase is that there would be a problem... but 
> *perhaps* what would happen is that ScheduleBase would first come into the 
> current tick, collect up all of the actions at the current tick, loop over 
> them, and if in the course of looping over those actions new actions were 
> added for that same tick, when the scheduler got to the end of the first 
> group of actions, it would then just see the same "tick" as the tick at the 
> top of the priority queue and repeat the same loop.
> 
> I realize there are valid questions about whether one should even be 
> *allowed* to do this, but in the meantime, I'm just wondering what the 
> designers think should happen with a tiny bit of explanation...
> 
> Best,
> Andy
> 
> ============================================
> Andrew J. Cleary, Software Engineer/Computational Scientist
> Lawrence Livermore National Labs, 925-424-5890.
> ============================================
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
> are you planning your Web Server Security? Click here to get a FREE
> Thawte SSL guide and find the answers to all your  SSL security issues.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
> _______________________________________________
> 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

[Repast-developer] Schedule question

[Andy C. <ac...@ll...>]

So, what would happen if one scheduled an action for the same time that the 
action currently being executed is scheduled for? Whatever the answer, is 
it an intended or unintended result?

My guess from look at ScheduleBase is that there would be a problem... but 
*perhaps* what would happen is that ScheduleBase would first come into the 
current tick, collect up all of the actions at the current tick, loop over 
them, and if in the course of looping over those actions new actions were 
added for that same tick, when the scheduler got to the end of the first 
group of actions, it would then just see the same "tick" as the tick at the 
top of the priority queue and repeat the same loop.

I realize there are valid questions about whether one should even be 
*allowed* to do this, but in the meantime, I'm just wondering what the 
designers think should happen with a tiny bit of explanation...

Best,
Andy

============================================
Andrew J. Cleary, Software Engineer/Computational Scientist
Lawrence Livermore National Labs, 925-424-5890.
============================================

[Repast-developer] [Fwd: SwarmFest 2003]

[Nick C. <nic...@ve...>]

Hi,

SwarmFest is traditionally an excellent forum for agent modelling in
general, and not restricted to the Swarm toolkit. For more info see
below.


-- 
Nick Collier 
Social Science Research Computing 
University of Chicago 
http://repast.sourceforge.net

Re: [Repast-developer] new fixed jar

[Thomas R. H. <th...@sr...>]

The distributions containing the bug fix have now been posted on the web
site.  These should also fix the MacOSX problem people were having.

-Tom

On Wed, 2003-01-29 at 10:16, Nick Collier wrote:
> Hi,
> 
> I've posted a new repast.jar that fixes the windows problems with the
> old one. 
> 
> http://repast.sourceforge.net/repast.jar.zip
> 
> Unzip and replace the current repast.jar in repast/lib with this new
> one. 
> 
> Nick
-- 
Tom Howe
Social Science Research Computing
University of Chicago

[Repast-developer] Re: [Repast-interest] new fixed jar

[Thomas R. H. <th...@sr...>]

The distributions containing the bug fix have now been posted on the web
site.  These should also fix the MacOSX problem people were having.

-Tom


On Wed, 2003-01-29 at 10:16, Nick Collier wrote:
> Hi,
> 
> I've posted a new repast.jar that fixes the windows problems with the
> old one. 
> 
> http://repast.sourceforge.net/repast.jar.zip
> 
> Unzip and replace the current repast.jar in repast/lib with this new
> one. 
> 
> Nick
-- 
Tom Howe
Social Science Research Computing
University of Chicago

[Repast-developer] new fixed jar

[Nick C. <nic...@ve...>]

Hi,

I've posted a new repast.jar that fixes the windows problems with the
old one. 

http://repast.sourceforge.net/repast.jar.zip

Unzip and replace the current repast.jar in repast/lib with this new
one. 

Nick

-- 
Nick Collier 
Social Science Research Computing 
University of Chicago 
http://repast.sourceforge.net

[Repast-developer] problem with bug fix jar

[Nick C. <nic...@ve...>]

Hi,

There's a problem on windows (repast won't run in some cases) with the
new bug fix jar that I posted yesterday. I'm working on this now. Linux
and OSX seem to be OK. Sigh....

Nick

-- 
Nick Collier 
Social Science Research Computing 
University of Chicago 
http://repast.sourceforge.net

Re: [Repast-developer] Topology Notes

[Thomas R. H. <th...@sr...>]

On Tue, 2003-01-28 at 13:46, Andy Cleary wrote:
> At 01:32 PM 1/28/2003 -0600, you wrote:
> 
> >Having said all this, I think that there is a semantic argument still to
> >made here.  I think that your identification of spaces as contexts is
> >particularly important.  IF we think of them as spaces, this will never
> >be consistent. (A social network is different than a grid).  But if they
> >are contexts, which can be layered and represent different kinds of
> >relationships, then the semantic difference is eliminated.  Some
> >contexts are static others are dynamic.  I think that this has potential
> >to be the way forward.  What do others think?
> >
> >-Tom
> 
> This has the aesthetic ring of being "right" that I look for in semantic 
> definitions like this, so let me be one to encourage the continuation of 
> this conversation. How exactly it should be realized in a software design, 
> both one starting "from scratch" and one building on the current Repast 
> code base, remains far from clear to me though.
> 

I don't think that refactoring this out of the current space library
would be that difficult, although, the api's would be different.  Also,
if we were going to make changes like this, I think that I wouldn't
focus on backwards compatibility.
	
[...]
>  Repast says nothing about agents at all... They are implicitly 

True enough.  This is something that we have been thinking about for
quite some time.  The main dilemma has been the best way to approach
this.  For many of us, aspect oriented programming seems the way to go,
but unfortunately this is not practical.  Interfaces seems like a good
way to approach it, but I suppose what has been really delaying us has
been the task of determining what common semantics exist within agent
types.

I think that this is a very good point, though.  


> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Repast-developer mailing list
> Rep...@li...
> https://lists.sourceforge.net/lists/listinfo/repast-developer
-- 
Tom Howe
Social Science Research Computing
University of Chicago

Re: [Repast-developer] Topology Notes

[Andy C. <ac...@ll...>]

At 01:32 PM 1/28/2003 -0600, you wrote:

>Having said all this, I think that there is a semantic argument still to
>made here.  I think that your identification of spaces as contexts is
>particularly important.  IF we think of them as spaces, this will never
>be consistent. (A social network is different than a grid).  But if they
>are contexts, which can be layered and represent different kinds of
>relationships, then the semantic difference is eliminated.  Some
>contexts are static others are dynamic.  I think that this has potential
>to be the way forward.  What do others think?
>
>-Tom

This has the aesthetic ring of being "right" that I look for in semantic 
definitions like this, so let me be one to encourage the continuation of 
this conversation. How exactly it should be realized in a software design, 
both one starting "from scratch" and one building on the current Repast 
code base, remains far from clear to me though.

Somewhere in between those two, though, I'll make the following fairly 
newbie-ish observation that I think might be obscurely relevant: when I 
first started studying Repast, I was disturbed that I couldn't find the 
documentation on the basic agent classes and interfaces. Of course, I 
eventually learned that that is because Repast does not actually have them; 
perhaps this is an overly strong statement in its details, but at a general 
level, Repast says nothing about agents at all... They are implicitly 
assumed to be there, but there is nothing explicit in the framework 
mentioning them (like I said, not exactly true). There are, I am sure, lots 
and lots of reasons for that, but whatever they are, there are also 
arguments for introducing them as explicit concepts into an ABM framework. 
One of those reasons is that it can help to decouple agent implementations 
from "simulation implementations", including the "spaces" that the 
simulation has, by defining common behaviors and interfaces that all agents 
must support, in essence providing a beginning to "standardizing" the 
relationships between agents and the rest of the simulation. Since the 
specific issue you are discussing here falls into this class (standardizing 
the relationships between agents and the rest of the simulation, where, let 
me be careful, I'm overloading the term "relationship"... Here I refer to 
the interaction between agents and the rest of the simulation at a code 
level, not "relationship" in the sense that the spaces are capturing 
relationships between agents), it might be a relevant observation.

At a code level, I'd certainly encourage finding a way to capture these 
common behaviors in interfaces rather than base classes if at all possible 
because of the inheritance issue. One can even imagine extending Repast in 
a backward compatible way by defining some interfaces and support for 
agents. If a user wants to provide their own SimModel and their own agents 
that work together without using the Repast agent stuff, fine, that's still 
there. But what could emerge if done correctly is a growing body of 
developers that implements agents that are reasonably swappable into other 
simulations because they implement common interfaces and behaviors and have 
simulations that in turn depend largely on those common things...

Cheers,
Andy

Re: [Repast-developer] Topology Notes

[Thomas R. H. <th...@sr...>]

On Fri, 2003-01-24 at 20:46, Laszlo Gulyas wrote:
> Hi Tom and all,
> 
> I'm very excited that we got to talking about this! ;-)
> Obviously, most of your comments and concerns are true.
> I've been thinking along some of these lines, too, back in
> November. Let me see what I can remember from those thoughts...
> 
> At 09:55 AM 1/22/2003 -0600, Thomas R. Howe wrote:
> >[...]
> >First, I see a problem with conclusion in our previous discussions that
> >metric spaces can unify the space library.  Metric spaces only apply to
> >symmetric relationships, d(x,y) == d(y,x).  The network library has
> >complete support for asymmetric relationships: d(x,y) != d(y,x) or
> >d(y,x) == null.  In fact this is the most general case.  Symmetric
> >networks are the special case (albeit a rather substantial one). So it
> >seems that, at least for that part of the space library, metrics don't
> >apply.  Now it seems totally reasonable to unify, at least, all of the
> >grid type spaces, and perhaps even symmetric networks, using the metric
> >approach.
> 
> You're absolutely right here. (Even though, one could imagine and
> implement a  'distance function' that is not symmetric; it should never
> be called a 'metric'.) But this is really just a side-note.
> 

Yeah, it's a side-note, but I think it is a fairly important semantic
point.

[...]
> Also, I might be overlooking something. For example, I always thought edges
> could be generated 'on the fly' (e.g., when the actual method is called). 
> And, I am
> sure, this is true for most cases. Still, one never knows when the user might
> feel like starting, say, a breadth-first graph-search. And then, s/he would 
> fail
> miserably if not all edges are generated yet...
> 


Yeah, I thought about generating these edges on the fly, also.  Seems
like this doesn't provide much of an advantage.  I suppose it allows you
to maintain the getOutEdges or getRelations, so that might be useful. 
But it forces the user to create those methods, when they might never
need them.  For example, in the situation like a grid, it seems rare
that a user would call getOutEdges, but it would still need to exist to
maintain the interface contract.  Perhaps I'm not seeing something
here.  Obviously, it wouldn't be difficult to handle the grid example,
but I'm thinking more about when people create their own spaces.


[...]
> I would implement the scenario you describe above as having a 'spatial context'
> that defines what location is a neighbor to what other location. That's 
> obviously
> static. Then I'd have a '"partner" context', which would define the agent's
> 'partners'. This latter's implementation would be based on the 'spatial 
> context'.
> That is, it'd simply query the former to get the actual neighbors.
> 
> Now, it might be, again, bending the model towards the implementation 
> artifacts...
> 

If I understand what you mean here, I think this has a lot of
potential.  Basically, the network (or context) acts as a set of
containers that can hold agents (at least in a spatial context). 
Basically a square lattice of buckets.  Then the agents query that to
determine their own edges.  This is actually what I was thinking about
when we were first having these discussions, but I never quite settled
on it.  But it makes sense.  If we assume that the network represents
the agents' relationships (which your model certainly does), then the
spatial relationships, would be somewhat exterior to the agent.  Spatial
relationships are exogenous to the actors afterall.  I think that this
could work with a limited overhead, because, as you say, the agents can
still be accessed using the matrix structure.  In this situation, I
would think that we would encourage users to use the getTo/getFrom Node
type methods, with added getVonNuemannNodes, etc.  As long as people
used these methods, they could swap spaces with no problem.  It may be
bending the model, but it does make sense to me.  I still think the
semantics of a spatial model are different, but I think that if users
want space swapability(sic from myself), they will have to use these
kinds of abstractions.

I would say, though, that I think it should be a "neighbor" context, not
a partner context.  

> >My second concern is that all agents will have to
> >extend some base class (DefaultNode, RelNode, etc.).  This eliminates
> >some of the flexibility people could use to extend other classes.  This
> >has been a concern for both Nick and I and is one reason why we so
> >desparately want to use aspects.
> 
> True, and I know about this concern. To some extend I share it, too.
> My main reason for going with the base class solution was clarity.
> I guess, the whole framework could be implemented based on interfaces, too,
> (I never tried, though), but I wanted to keep the benefits of having a clean
> notation and a clean model code in the end.

I still have concerns about this, but our network stuff has a base agent
class, so. . .  The other thing is that if people want to use the
network as a set of containers for agents (since a spatial network like
a grid will be static), then this doesn't apply because, they can put
any class in a node on the network.

> 
> >The third concern I have has to do
> >with the Range operator.  I guess this falls under computational
> >expense, but it is a little different.  If someone needs to do a range
> >query, the agent would need to find the shortest path to each of the
> >other objects.  That would be prohibitively expensive.
> >I wonder, do you have any thoughts on how to get around this problem?
> 
> This is true and this is something I did not think about before. Still,
> if we could keep the option of plugging in 'smart implementations'
> then this one, too, goes away. I mean, then it boils down to the
> common trade-off between putting in more efforts during the implementation
> phase or spending more time on completing the experiments


Like you say, as long as we have concrete space classes that have range
operators, this shouldn't be a problem.  It just won't be abstracted
out.


Having said all this, I think that there is a semantic argument still to
made here.  I think that your identification of spaces as contexts is
particularly important.  IF we think of them as spaces, this will never
be consistent. (A social network is different than a grid).  But if they
are contexts, which can be layered and represent different kinds of
relationships, then the semantic difference is eliminated.  Some
contexts are static others are dynamic.  I think that this has potential
to be the way forward.  What do others think?

-Tom


> >On Thu, 2002-11-21 at 22:52, Laszlo Gulyas wrote:
> > > Hi Guys,
> > >
> > > I'm sorry for taking so long reacting, but there's so many things
> > > going on right now. (Not excluding selling the furniture and the car
> > > in preparation to moving back to Europe.) So, my schedule was and
> > > is a bit hectic. Fortunately, though, both Anita (my wife) and I have
> > > saved up some days off, so we're gonna take off for a last vacation
> > > soon. Hopefully, I get back for the last couple of days much more
> > > relaxed/productive...
> > >
> > > However, I wanted to get back to you on this before that happens.
> > > I think, Mike has summarized our discussion rather well. The only
> > > thing remained to say is about displaying these things. In principle,
> > > the Drawable interface works well: it basically maps an agent into
> > > a 2D coordinate system, plus provides a way for it to draw itself.
> > > This should be general enough.
> > >
> > > Except that it kind of makes it hard for an agent to participate in
> > > several [switchable] 'spaces' or to display itself on different
> > > displays
> > > of the same [possibly N-dimensional] space. Now, I don't necessarily
> > > think that it is time now [just before 2.0] to blow up the whole gui
> > > package.
> > > However, I've been doing some experimentation and created my
> > > own ContextMapping (well, I call them contexts, but they are, kind
> > > of, generalized topologies) interface whose methods take an agent and
> > > - map it into an (X,Y) /screen/ coordinate,
> > > - return its Dimension,
> > > - draw it on the screen.
> > >
> > > I just thought I'd share this with you. (See the attachment.)
> > > Please, do not look at its performance yet! On the other hand,
> > > it's kind of complex, so I won't blame you not want to start
> > > with it right now.
> > >
> > > - - - - -
> > >
> > > OK. In this model, I've taken the 'space/topology' issue a step
> > > further. (?) [Don't think I'm suggesting you should start implementing
> > > any of this. Rather, I just want to share my crazy visions with you.]
> > >
> > > Now I think that the bottom line of all these 'space/topology'
> > > issues is the concept of a Relation. It is really nothing else, but an
> > > Edge
> > > on a network, so one nice thing about this approach is that it
> > > provides
> > > a natural way to unify the 'grid-based' and the network models.
> > >
> > > OK, so I call them relations, not Edges, what's the difference?
> > > Technically, my implementation is nothing more than providing
> > > ways to sort out edges according to their types. This way, I have
> > > general methods to say, "Give me the related nodes according to
> > > relation R", R being a parameter.
> > >
> > > My 'contexts' create and update the relations and all the Model/Agent
> > > do is to query and use them, via these general methods. This way, by
> > > replacing the context, you can place the agents into vastly different
> > > environments, as long as they all define the same relations.
> > >
> > > From this point of view, the topologies/spaces just define special,
> > > perhaps
> > > parametrized [with distance] 'neighborhood' or 'close-to' relations.
> > > Storing
> > > the agents on a grid internally is just an efficient way of
> > > implementing this.
> > > (Naturally, it is debatable whether the relations/edges define special
> > > kinds
> > > of topologies, or the other way around, but this time, I just went
> > > with the
> > > latter option.)
> > >
> > > Well, let me know what do you think. Note, however, that I'll be out
> > > of
> > > town till December 3. So, don't get mad at me if I won't answer them
> > > immediately. (Well, that's kind of usual from me, sadly enough.)
> > >
> > > Take care!
> > >
> > > Gulya
> > >
> > > PS: I can't resist to put this in here: as a long shot off the
> > > 'relation burble':
> > > this could, in fact, finally lead to the 'DB-based' simulation I've
> > > been
> > > 'visioning' for a while. I mean, if relations are a central concept in
> > > the
> > > architecture, and the model's and the agents' logic is formulated
> > > according
> > > to this, it could be possible to actually implement them by storing
> > > them
> > > in a relational DB. Then, in principle, one could do cool stuff, like
> > > defining 'dynamic relationships' via joints, or creating triggers,
> > > etc.
> > > I'm not sure if it's necessarily more efficient, but wouldn't it be
> > > cool?! ;-)
> > > [Enough of me now! :-)]
> > >
> > > At 07:15 PM 11/15/2002 -0600, North, Michael wrote:
> > >
> > > > Tom:
> > > >
> > > >
> > > >
> > > > The topology issues that we discussed might be represented as
> > > > follows:
> > > >
> > > >
> > > >
> > > > 1.)   An abstract Topology class or interface can be defined:
> > > >
> > > > a.      The class has a method, getDistance(Object o1, Object o2),
> > > > that returns the distance between any two objects.
> > > >
> > > > b.     The Topology class has appropriate methods to get neighbors
> > > > within a certain range such as getNeighbors(Object o1, double range)
> > > > .
> > > >
> > > > 2.)   Three or more concrete Topology implementation classes can
> > > > then be defined:
> > > >
> > > > a.      An implementation for Moore neighborhoods, von Neumann
> > > > neighborhoods, and hexagonal neighborhoods based on the current grid
> > > > implementation can be defined.  This would use the current
> > > > array-based grid storage and maintain backward compatibility.  Since
> > > > it is essentially the current implementation, it would run as fast
> > > > as the current code.
> > > >
> > > > b.     An implementation for metric spaces can be defined that uses
> > > > trees to store objects and find neighbors.  This can be done since
> > > > the rules of a metric space allow tree storage.  For example see
> > > > http://www.vldb.org/conf/1997/P426.PDF. Other implementations are
> > > > also available, especially for large lists.  For example, see
> > > > http://portal.acm.org/citation.cfm?id=328959&dl=ACM&coll=portal.
> > > > This implementation would run slower than the current code but it
> > > > would still be reasonable for most problems.  The price of slower
> > > > execution is made up for by the added flexibility.
> > > >
> > > > c.      An implementation for completely abstract (i.e. non-metric)
> > > > spaces can be defined that uses a simple list to store objects and a
> > > > naïve all pairs matching algorithm to find neighbors.  The algorithm
> > > > will simply test the distance between each object to find
> > > > neighbors.  This implementation will be much slower than the current
> > > > code for large lists but the slower execution will be made up for by
> > > > the increased flexibility, at least for initial testing.  Users that
> > > > find they need a particularly abstract notion of space are free to
> > > > develop optimized versions of the Topology class as they see fit.
> > > >
> > > > 3.)   Users select the fastest concrete implementation class that
> > > > supports their model's notion of space.  Of course, users are also
> > > > free to extend or add to the existing concrete classes.
> > > >
> > > >
> > > >
> > > > Mike
> > > >
> > > >
> > > >
> > > >
> >--
> >Tom Howe
> >Social Science Research Computing
> >University of Chicago
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Repast-developer mailing list
> Rep...@li...
> https://lists.sourceforge.net/lists/listinfo/repast-developer
-- 
Tom Howe
Social Science Research Computing
University of Chicago

[Repast-developer] Bug Alert

[Nick C. <nic...@ve...>]

Hi,

We've discovered a potentially bad bug in RePast 2.0 in the DefaultEdge
class. The bug will occur under the following conditions:

DefaultNode i = new DefaultNode();
DefaultNode j = new DefaultNode();
DefaultNode k = new DefaultNode();
DefaultEdge edge = new DefaultEdge(i, j);
i.addOutEdge(edge);
j.addInEdge(edge);

// this much above is fine. The line below is the problem.

edge.setTo(k);

At this point the edge knows its from node is i and its to node is k.
However, we are now caching some connection information in the nodes
themselves for efficient lookups of what other nodes a particular node
is connected to. DefaultEdge.setTo and DefaultEdge.setFrom doesn't
update the nodes' caches correctly and so DefaultNode.hasEdgeTo/From
queries may not return the correct answer. Note that if you never call
edge.setTo or edge.setFrom then, you will not be effected.

A new repast.jar that fixes this problem can be found at:

http://repast.sourceforge.net/repast.jar.zip

Unzip the jar and replace the one in repast/lib/ with this new one. We
should have updated distributions on the web page in few days. If you
are confused over whether or not you may be affected by this bug, feel
free to email me. Lastly, this new jar also fixes the random stream
problem in the Fruch graph layout mentioned a few days ago.

Nick

-- 
Nick Collier 
Social Science Research Computing 
University of Chicago 
http://repast.sourceforge.net

Re: [Repast-developer] Topology Notes

[Laszlo G. <gu...@la...>]

Hi Tom and all,

I'm very excited that we got to talking about this! ;-)
Obviously, most of your comments and concerns are true.
I've been thinking along some of these lines, too, back in
November. Let me see what I can remember from those thoughts...

At 09:55 AM 1/22/2003 -0600, Thomas R. Howe wrote:
>[...]
>First, I see a problem with conclusion in our previous discussions that
>metric spaces can unify the space library.  Metric spaces only apply to
>symmetric relationships, d(x,y) =3D=3D d(y,x).  The network library has
>complete support for asymmetric relationships: d(x,y) !=3D d(y,x) or
>d(y,x) =3D=3D null.  In fact this is the most general case.  Symmetric
>networks are the special case (albeit a rather substantial one). So it
>seems that, at least for that part of the space library, metrics don't
>apply.  Now it seems totally reasonable to unify, at least, all of the
>grid type spaces, and perhaps even symmetric networks, using the metric
>approach.

You're absolutely right here. (Even though, one could imagine and
implement a  'distance function' that is not symmetric; it should never
be called a 'metric'.) But this is really just a side-note.


>Gulya, Nick and I were talking about the relation stuff you came up with
>yesterday.  That is a super neat way to unify the network stuff with the
>spatial stuff.  I have some concerns, (I'm sure you can guess what they
>are).  The first is performance, both memory and computation.  If there
>is a large grid, the set of edges created by a Moore neighborhood will
>be huge.  Computationally, I'm concerned about the update method in the
>contexts.

My intention with the current implementation was to be a 'proof-of-concept'
thing. Also, I figured that a particular relation type can always be=20
implemented
in a 'smart way'. Meaning that the functionality defined in RelNode can=
 always
be overridden to capitalize on the additional information known about the=20
space.
This could mean a class 'between' RelNode and the class of the actual=
 relation.

According to this scenario, if the modeler (or the programmer) knows a=
 better
data structure/algorithm to store the edges and reproduce them upon request
(e.g., when getRelatedTo() is called) than the naive set of HashMaps used in
RelNode, and it s/he thinks it worths the effort in that particular=20
project, then
s/he should definitely implement it that way. If s/he decides otherwise, the
project can still fall back on the standard implementation.

Now, with spaces provided by Repast itself, it's obviously a bit different.
I always imagined that grid spaces would be based on matrices in the=
 background
(It's hard to imagine anything more efficient.) But, the same time, they=
 would
respond to the same set of methods. That is, it's much like the current=20
'getNeighbors()'
thing, except that it comes from a standard set applicable to more general=
=20
spaces.
And that it would return Edges or Nodes...

Obviously, this would come at the price of actually storing the space twice
(once in the matrix, and once in the graph). :(

Also, I might be overlooking something. For example, I always thought edges
could be generated 'on the fly' (e.g., when the actual method is called).=20
And, I am
sure, this is true for most cases. Still, one never knows when the user=
 might
feel like starting, say, a breadth-first graph-search. And then, s/he would=
=20
fail
miserably if not all edges are generated yet...

>If agents are moving, and constantly changing their
>neighborhoods, the update method (where relations are updated) will be
>extremely expensive.

Yes. But if the setup I outlined above works, it might not be. On the other=
=20
hand,
I would implement the scenario you describe above as having a 'spatial=
 context'
that defines what location is a neighbor to what other location. That's=20
obviously
static. Then I'd have a '"partner" context', which would define the agent's
'partners'. This latter's implementation would be based on the 'spatial=20
context'.
That is, it'd simply query the former to get the actual neighbors.

Now, it might be, again, bending the model towards the implementation=20
artifacts...

>My second concern is that all agents will have to
>extend some base class (DefaultNode, RelNode, etc.).  This eliminates
>some of the flexibility people could use to extend other classes.  This
>has been a concern for both Nick and I and is one reason why we so
>desparately want to use aspects.

True, and I know about this concern. To some extend I share it, too.
My main reason for going with the base class solution was clarity.
I guess, the whole framework could be implemented based on interfaces, too,
(I never tried, though), but I wanted to keep the benefits of having a clean
notation and a clean model code in the end.

That is to say, I won't necessarily fight for this design... Again, I might
be overlooking something. It's been a while (2 months) that I worked on
this...


>The third concern I have has to do
>with the Range operator.  I guess this falls under computational
>expense, but it is a little different.  If someone needs to do a range
>query, the agent would need to find the shortest path to each of the
>other objects.  That would be prohibitively expensive.
>I wonder, do you have any thoughts on how to get around this problem?

This is true and this is something I did not think about before. Still,
if we could keep the option of plugging in 'smart implementations'
then this one, too, goes away. I mean, then it boils down to the
common trade-off between putting in more efforts during the implementation
phase or spending more time on completing the experiments.

I don't know if this helps anything, but these are my thoughts now.
I am happy to continue the discussion (hopefully, with shorter delays on
my side).

Take care!

Gulya


>On Thu, 2002-11-21 at 22:52, Laszlo Gulyas wrote:
> > Hi Guys,
> >
> > I'm sorry for taking so long reacting, but there's so many things
> > going on right now. (Not excluding selling the furniture and the car
> > in preparation to moving back to Europe.) So, my schedule was and
> > is a bit hectic. Fortunately, though, both Anita (my wife) and I have
> > saved up some days off, so we're gonna take off for a last vacation
> > soon. Hopefully, I get back for the last couple of days much more
> > relaxed/productive...
> >
> > However, I wanted to get back to you on this before that happens.
> > I think, Mike has summarized our discussion rather well. The only
> > thing remained to say is about displaying these things. In principle,
> > the Drawable interface works well: it basically maps an agent into
> > a 2D coordinate system, plus provides a way for it to draw itself.
> > This should be general enough.
> >
> > Except that it kind of makes it hard for an agent to participate in
> > several [switchable] 'spaces' or to display itself on different
> > displays
> > of the same [possibly N-dimensional] space. Now, I don't necessarily
> > think that it is time now [just before 2.0] to blow up the whole gui
> > package.
> > However, I've been doing some experimentation and created my
> > own ContextMapping (well, I call them contexts, but they are, kind
> > of, generalized topologies) interface whose methods take an agent and
> > - map it into an (X,Y) /screen/ coordinate,
> > - return its Dimension,
> > - draw it on the screen.
> >
> > I just thought I'd share this with you. (See the attachment.)
> > Please, do not look at its performance yet! On the other hand,
> > it's kind of complex, so I won't blame you not want to start
> > with it right now.
> >
> > - - - - -
> >
> > OK. In this model, I've taken the 'space/topology' issue a step
> > further. (?) [Don't think I'm suggesting you should start implementing
> > any of this. Rather, I just want to share my crazy visions with you.]
> >
> > Now I think that the bottom line of all these 'space/topology'
> > issues is the concept of a Relation. It is really nothing else, but an
> > Edge
> > on a network, so one nice thing about this approach is that it
> > provides
> > a natural way to unify the 'grid-based' and the network models.
> >
> > OK, so I call them relations, not Edges, what's the difference?
> > Technically, my implementation is nothing more than providing
> > ways to sort out edges according to their types. This way, I have
> > general methods to say, "Give me the related nodes according to
> > relation R", R being a parameter.
> >
> > My 'contexts' create and update the relations and all the Model/Agent
> > do is to query and use them, via these general methods. This way, by
> > replacing the context, you can place the agents into vastly different
> > environments, as long as they all define the same relations.
> >
> > From this point of view, the topologies/spaces just define special,
> > perhaps
> > parametrized [with distance] 'neighborhood' or 'close-to' relations.
> > Storing
> > the agents on a grid internally is just an efficient way of
> > implementing this.
> > (Naturally, it is debatable whether the relations/edges define special
> > kinds
> > of topologies, or the other way around, but this time, I just went
> > with the
> > latter option.)
> >
> > Well, let me know what do you think. Note, however, that I'll be out
> > of
> > town till December 3. So, don't get mad at me if I won't answer them
> > immediately. (Well, that's kind of usual from me, sadly enough.)
> >
> > Take care!
> >
> > Gulya
> >
> > PS: I can't resist to put this in here: as a long shot off the
> > 'relation burble':
> > this could, in fact, finally lead to the 'DB-based' simulation I've
> > been
> > 'visioning' for a while. I mean, if relations are a central concept in
> > the
> > architecture, and the model's and the agents' logic is formulated
> > according
> > to this, it could be possible to actually implement them by storing
> > them
> > in a relational DB. Then, in principle, one could do cool stuff, like
> > defining 'dynamic relationships' via joints, or creating triggers,
> > etc.
> > I'm not sure if it's necessarily more efficient, but wouldn't it be
> > cool?! ;-)
> > [Enough of me now! :-)]
> >
> > At 07:15 PM 11/15/2002 -0600, North, Michael wrote:
> >
> > > Tom:
> > >
> > >
> > >
> > > The topology issues that we discussed might be represented as
> > > follows:
> > >
> > >
> > >
> > > 1.)   An abstract Topology class or interface can be defined:
> > >
> > > a.      The class has a method, getDistance(Object o1, Object o2),
> > > that returns the distance between any two objects.
> > >
> > > b.     The Topology class has appropriate methods to get neighbors
> > > within a certain range such as getNeighbors(Object o1, double range)
> > > .
> > >
> > > 2.)   Three or more concrete Topology implementation classes can
> > > then be defined:
> > >
> > > a.      An implementation for Moore neighborhoods, von Neumann
> > > neighborhoods, and hexagonal neighborhoods based on the current grid
> > > implementation can be defined.  This would use the current
> > > array-based grid storage and maintain backward compatibility.  Since
> > > it is essentially the current implementation, it would run as fast
> > > as the current code.
> > >
> > > b.     An implementation for metric spaces can be defined that uses
> > > trees to store objects and find neighbors.  This can be done since
> > > the rules of a metric space allow tree storage.  For example see
> > > http://www.vldb.org/conf/1997/P426.PDF. Other implementations are
> > > also available, especially for large lists.  For example, see
> > > http://portal.acm.org/citation.cfm?id=3D328959&dl=3DACM&coll=3Dportal.
> > > This implementation would run slower than the current code but it
> > > would still be reasonable for most problems.  The price of slower
> > > execution is made up for by the added flexibility.
> > >
> > > c.      An implementation for completely abstract (i.e. non-metric)
> > > spaces can be defined that uses a simple list to store objects and a
> > > na=EFve all pairs matching algorithm to find neighbors.  The algorithm
> > > will simply test the distance between each object to find
> > > neighbors.  This implementation will be much slower than the current
> > > code for large lists but the slower execution will be made up for by
> > > the increased flexibility, at least for initial testing.  Users that
> > > find they need a particularly abstract notion of space are free to
> > > develop optimized versions of the Topology class as they see fit.
> > >
> > > 3.)   Users select the fastest concrete implementation class that
> > > supports their model's notion of space.  Of course, users are also
> > > free to extend or add to the existing concrete classes.
> > >
> > >
> > >
> > > Mike
> > >
> > >
> > >
> > >
>--
>Tom Howe
>Social Science Research Computing
>University of Chicago

Re: [Repast-developer] Topology Notes

[<gu...@la...>]

Hi,

Just a note on aspects. Back in the old MAML days at CEU,
we've been talking about the 'model aspect' and the 'observer
aspect' of a simulation. In fact, MAML implemented this explicitely
and the compiler had a feature to 'weave'these two together into a singl=
e 
Swarm model. 

See, abstract: http://www.sztaki.hu/~gulyas/Abstracts/AOPSS.txt
     paper: http://www.sztaki.hu/~gulyas/Papers/AOPSS.zip

Regards,

Gulya

PS: Tom, I'll answer to the essence of this thread, too. But that
takes a bit more time! :-)

Id=E9z=E9s "Thomas R. Howe" <th...@sr...>:

> I can forward the emails, if you are interested.  By aspects, I mean
> aspect oriented programming.  Basically aop is based on the idea that
> some common semantics cut across class hierarchies.  For example, in a=
bm
> world, many different agents can move, but we wouldn't call movement
> necessarily their defining feature.  If we had a movement aspect, it
> could cut across the agent hierarchies.  This way we wouldn't have to
> inherit movement behaviour.  This, of course, is oversimplifying a bit=
,
> but if you are interested, check out http://aosd.net and
> http://www.aspectj.org.  aose is the Aspect-Oriented Software
> Development page and aspectJ is a very nice java extension for aspect
> oriented programming that uses BCEL.
> 
> -Tom
> 
> 
> On Wed, 2003-01-22 at 12:52, ge...@te... wrote:
> > Thomas R. Howe writes:
> >  > This has been a concern for both Nick and I and is one reason why
> >  > we so desparately want to use aspects.
> > 
> > I couldn't find the reference in the email archives.  What do you
> > mean by "aspects"?
> -- 
> Tom Howe
> Social Science Research Computing
> University of Chicago
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Scholarships for Techies!
> Can't afford IT training? All 2003 ictp students receive scholarships.
> Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
> www.ictp.com/training/sourceforge.asp
> _______________________________________________
> Repast-developer mailing list
> Rep...@li...
> https://lists.sourceforge.net/lists/listinfo/repast-developer
> 

Re: [Repast-developer] Topology Notes

[Thomas R. H. <th...@sr...>]

I can forward the emails, if you are interested.  By aspects, I mean
aspect oriented programming.  Basically aop is based on the idea that
some common semantics cut across class hierarchies.  For example, in abm
world, many different agents can move, but we wouldn't call movement
necessarily their defining feature.  If we had a movement aspect, it
could cut across the agent hierarchies.  This way we wouldn't have to
inherit movement behaviour.  This, of course, is oversimplifying a bit,
but if you are interested, check out http://aosd.net and
http://www.aspectj.org.  aose is the Aspect-Oriented Software
Development page and aspectJ is a very nice java extension for aspect
oriented programming that uses BCEL.

-Tom


On Wed, 2003-01-22 at 12:52, ge...@te... wrote:
> Thomas R. Howe writes:
>  > This has been a concern for both Nick and I and is one reason why
>  > we so desparately want to use aspects.
> 
> I couldn't find the reference in the email archives.  What do you
> mean by "aspects"?
-- 
Tom Howe
Social Science Research Computing
University of Chicago