Re: OO consideration

[Rick Riolo]

Maybe I'm missing something, but with respect to mousetraps
why can't there be absorbing (Iron) agents in the agent list?
Then when a ball gets tossed to a random agent in the list,
sometimes its to a mousetrap (and so cause more events to be
schedule), sometimes its to an absorbing agent (who doesn't
schedule more events).

Again, the way I think of it, mousetraps works because in effect it 
assumes everywhere the ball could fall, there is an trap there.
If that's not strictly true, you could have special non-trap
agents in the list, too.   
In effect, the agent list *is* the environment, and all
each mousetrap (agent) knows is that the environment is there
and when a ball is tossed at it, it will fall somewhere in the environment.

Or you could have balls tossed to "the space", and the space
can decide what to do with the ball.  Eg if its a 2d space,
the space can see if there is an agent (trap,iron) at the location where
the ball is going to fall, and if so, it passes the ball on.
You might want to do this if balls can only travel so far
and you want to bias where they can land to some subset of
agents near the tossing agent.

 - r

Rick Riolo                       address@hidden
Program for Study of Complex Systems (PSCS)
1061 Randall Lab     University of Michigan
Ann Arbor MI 48109-1120
http://pscs.physics.lsa.umich.edu/PEOPLE/rlr-home.html

On Thu, 22 May 1997, Benoit Desrosiers wrote:

> Date: Thu, 22 May 1997 23:04:50 -0400
> From: Benoit Desrosiers <address@hidden>
> To: address@hidden
> Subject: OO consideration
> 
> Hi, I have a philosophical question about Mousetrap.
> 
> In Mousetrap, if you follow the logic, the model start the simulation 
> by throwing a ball on a trap then this trap sends its 2 balls to two
> other traps and on and on...
> 
> My question is: How does a trap knows about the other traps?
> 
> I explain: from an OO point of view, the trap knows only that it is
> in a given system, so all it should do is to send the balls to this
> system and this one would do what it wants with the balls. Suppose
> that we would like to simulate the effect of putting something that
> slows down the reaction (an iron (or carbon) pipe for real reactor)
> then the effect would be to catch some of the ping pong ball that 
> went on. But with this simulation, we cannot do that.
> 
> I know, this is just a toy application, but the reason why I got to 
> this reflection is because in my simulation, my model have to start
> 2 different randomly selected agents on the grid at every simulation.
> If I take the mousetrap simulation, then the trap (or for my simulation
> the agent) have to select another trap every time it is called. I 
> don't like this approach because of the above reason (the iron pipe). 
> 
> What would be the best way to do my application? Here is some solutions
> that I thought of:
> 
> 1) the model have a schedule with a setRepeatInterval:1. On this 
> schedule I put an action at 0 [createActionTo:self message: M(step)]. 
> And in model>>step I call the 2 agent directly [anAgent attack]. 
> 
> 2) the model have a schedule with no repeatInterval. Here again, I put
> a step event at 0. In model>>step, I put an event for agent>>attack at
> getCurrentTime().  This time, since there is no repeatInterval, I put
> another model>>step event at getCurrentTime() +1 at the end of step. 
> 
> 3) I use the same technique used in mousetrap: the agent put an event
> for another agent.
> 
> 
> Here are the pros and cons of every solution:
> 
> 1) con: by calling the agent directly in model>>step, I broke the event
> paradigm used in swarm
>    pro: it work, and it is flexible (iron pipe)
> 
> 2) con: I have to put back manually a call to step
>    pro: it work, and it is flexible too
> 
> 3) con: not flexible, the agent knows too much about it environment
>    pro: it work
> 
> 
> 
> Any suggestions?
> 
> thanks
> Benoit
> 
>                   ==================================
>    Swarm-Support is for discussion of the technical details of the day
>    to day usage of Swarm.  For list administration needs (esp.
>    [un]subscribing), please send a message to <address@hidden>
>    with "help" in the body of the message.
>                   ==================================
> 

                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.
                  ==================================