Re: [Repast-interest] Re: [Repast-developer] agent base interface

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

At 08:50 AM 2/25/2003 -0500, Nick Collier wrote:
>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
>

So if you liked that, how about this next possible role for a referee?

Time.

Perhaps for slightly different reasons, there is a case to be made that 
some sort of referee pattern can also be used to decouple an agent's notion 
of time from the time as implemented by the schedule. Imagine if you will 
that instead of the agents scheduling things directly onto the schedule, 
they instead submit their desired event to the referee, and the referee 
then acts as a "filter" for scheduling that event onto the real schedule.

Imagine, for example, an agent written as if time were continuous. If the 
person that wrote the simulation wants things to execute only at regular 
intervals, the referee could take the agent's request for an event at time 
t in a float format and then round it in some appropriate way to the 
nearest interval. We talked about this in the context of parallel 
processing for example: events happening simultaneously are ideal for 
parallel computing. But events scheduled in continuous time ruin that. So, 
here the referee can be used to "smear" the time of events so that many of 
them happen simultaneously. Another scenario is controlling the fidelity of 
a simulation dynamically, without having to have programmed this capability 
into the agents themselves. If you bump up the size of the "interval" at 
which things are scheduled, you can arguably be sacrificing some fidelity 
for a decrease in execution time, exactly analogous to the tradeoff that is 
seen in choosing timesteps in an ODE/PDE solver (caveat: for this to work 
may require a slight semantic change in the definition of what an agent 
requests from the referee/schedule...). A third use of the referee acting 
as a filter around the schedule is similar to its use in modulating the 
"physics" of a simulation: it can "enforce rules" about time for the 
simulation. Perhaps a simulation writer does not want to allow the same 
agent to schedule events closer than 5 minutes to each other for the sake 
of fairplay. If the agents are required to schedule events through the 
referee, the referee can enforce this rule. Otherwise, the simulation 
writer must rely on the author of the agents to obey this rule... Not only 
does the referee provide a nice "error checker" for unwitting errors, but 
in the case that agents and simulations are written in a decoupled fashion, 
the author of the agent may not have even been aware of this rule when the 
agent was written. Or, the rule could have been changed since the agent was 
written. Here, there is one place for the rule, so there is no need to rely 
on the agents agreeing on the rule. And in fact, the rule can be changed 
dynamically if that made modeling sense, without going back and changing 
the agents.

So, just like I envision a Referee "has a" environment, I also envision it 
as "has a" schedule. Agents do not have either: they see the world only 
through the referee (arguably; this is the strong form of this idea). The 
referee decides what they see, what they effect, when they effect it, when 
and what effects them (but not *HOW*: an object always is responsible for 
its own internal changes of state), etc.

BTW, while I am talking about the "referee" pattern, I'm doing so now 
because a big part of its motivation is that I see it helping to decouple 
agents from simulations, and that dovetails nicely with the current 
discussion on creating Agent interface(s). It strikes me that if the 
referee pattern becomes widespread, there may be opportunities to see more 
"common methods" for Agent interface(s).

Cheers,
Andy