|
From: Andy C. <ac...@ll...> - 2003-02-26 02:42:30
|
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 |