A RePast Tutorial by John T. Murphy, University of Arizona & Arizona State University (contact)
Let's consider what will be the user-settable parameters. For now we will use:
For now, to make this change we need to do three things:
The code, thus modified, is:
// CarryDropModel
package demo;
import uchicago.src.sim.engine.Schedule;
import uchicago.src.sim.engine.SimModelImpl;
public class CarryDropModel extends SimModelImpl {
private int numAgents;
private int worldXSize;
private int worldYSize;
private Schedule schedule;
public String getName(){
return "Carry And Drop";
}
public void setup(){
}
public void begin(){
buildModel();
buildSchedule();
buildDisplay();
}
public void buildModel(){
}
public void buildSchedule(){
}
public void buildDisplay(){
}
public Schedule getSchedule(){
return schedule;
}
public String[] getInitParam(){
String[] initParams = { "NumAgents" , "WorldXSize", "WorldYSize"};
return initParams;
}
public int getNumAgents(){
return numAgents;
}
public void setNumAgents(int na){
numAgents = na;
}
public int getWorldXSize(){
return worldXSize;
}
public void setWorldXSize(int wxs){
worldXSize = wxs;
}
public int getWorldYSize(){
return worldYSize;
}
public void setWorldYSize(int wys){
worldYSize = wys;
}
public static void main(String[] args) {
}
}
// CarryDropAgent
package demo;
public class CarryDropAgent {
}
// CarryDropSpace
package demo;
public class CarryDropSpace {
}
Note: Good programming practice would take one other step here and would guard against errors that could be created by parameter settings that are in some way out of bounds. For example, the variable 'worldYSize' is just a Java variable, and could easily store values that are either far too large for our model or are completely inappropriate (like zero or even a negative number). The behavior in some of these cases is unpredictable and could cause code crashes or oddness in the model's results- the latter being worse than a code crash because the code might appear to run well but actually be doing something odd that skews the results.
If the application were to be distributed widely, this kind of defensive programming would be requisite. However, if one is writing a program for one's own use, it is not always necessary to guard against such misuse, and one can simply avoid bad input and focus on parameters that are reasonable for the task for which the model was written.
I'm omitting such defenses in this tutorial for a different reason: to keep the code simple. Adding extra lines that prohibit every possible kind of predictable error would be a distraction from the main point, which is getting a RePast model to run. This means, however, that in playing with the parameter settings, the user of this model should 'play fair' and keep the values within reasonable ranges.
Next: Compiling and Running the Basic Model
Go to Table of Contents
A RePast Tutorial by John T. Murphy, University of Arizona & Arizona State University (contact)