Barnes D.J., Chu D. Introduction to Modeling for Biosciences

Подождите немного. Документ загружается.

3.3 The Game of Life in Repast S 93

Fig. 3.6 Property for the Game of Life agent

the Value cell but the two key ones are Everyone and Only Me. These correspond

to Java’s public and private visibilities, respectively. Our preference would be

to use Only Me as far as possible, in order to apply full encapsulation to agents’

properties. However, this makes a number of things more difﬁcult in the Repast

environment—such as interactively inspecting agents’ states in the display view—so

we will tend to compromise with Everyone for the sake of simplicity. Nevertheless,

we will still have other components of the model read and write the values of an

agent’s properties via the automatically-generated accessor and mutator (getter and

setter) methods, should this be necessary. Leave Everyone, therefore, for step 4. In

Chap. 2.3 we described an agent’s state in terms of the values 0 and 1. This suggests

the use of an integer type for step 5: click in the Value area of the property panel

and select int from the drop-down list. The default initial value of 0 for step 6 ﬁts

in with this choice of type. Select Save and we now have the beginning of an agent

deﬁnition as shown in Fig. 3.6.

94 3 ABMs Using Repast and Java

3.3.2.2 The Issue of Update Ordering

In many models there is an underlying assumption that agents update their state

simultaneously at each time step, ready for the next time step. In a program it is

not practically possible for all agents to act concurrently. Instead, they are given

the chance to update sequentially—one after the other—at notionally the same time

step. Where agent behavior is independent of each other this is not a problem, but

this is often not the case. We pointed out in Sect. 2.3, for instance, that there will

be a different outcome if one Game of Life agent changes its state for the next time

step before its neighbors have determined their own next state.

What this means in practice for the model programmer is that agents often need

to be written to maintain some additional properties (that are not strictly part of

their state) in order to overcome the limitations of necessarily sequential execution

of what should properly be simultaneous update. The approach we will take with our

Game of Life agents is to add an additional property to Agent called nextState.

When an agent determines its new state from the state of its neighbors, it actually

stores the calculated value in nextState rather than currentState. That way,

when an agent is asked for its current state by its neighbors it will still be able to

return the “old” value. Once every agent has calculated its next state, each can then

be told to update the currentState property with the value of nextState,

ready for a repeat of this process at the next time step. We add a Next State property

along these lines to our agent. This time, we can use Only Me for step 4 because

we anticipate that no other part of the model needs to be aware of this internal

contrivance—it is not a genuine part of an agent’s externally-presented state, but an

artifact of implementational limitations.

3.3.2.3 Behavior and Interaction

The behavior of agents deﬁning their interactions is programmed in Repast by link-

ing together a sequence of ﬂowchart symbols. The ﬂowchart language provided

allows all the standard programming elements to be used: variable assignments,

arithmetic calculations, choices between alternative actions, repeated actions, and

so on. An agent may have as many behaviors as desired. As we shall see, however,

an agent with even just a few, moderately complex behaviors can quickly become

quite difﬁcult to manage via the ﬂowchart editor. A particular advantage of Repast

in this respect is that it is relatively simple to switch from using ﬂowcharts to Java or

Groovy (or even use a mixture of all three), without having to abandon the Repast

environment, with its rich set of features.

We will start programming the agent’s behaviors with the simplest operation—

that of copying the calculated next state into the currentState variable. This

will serve to illustrate the basics of behavior programming.

Behaviors are started by selecting the Behavior icon—a triangle—from the

ﬂowchart palette. By default this will appear with the label Step in the program-

ming area. There are nine steps that can be ﬁlled out, six of which are indicated as

3.3 The Game of Life in Repast S 95

Table 3.2 The steps

of a behavior

Step 1: A comment that describes the behavior

Step 2: A human-readable diagram label

Step 3: The behavior’s execution schedule (optional)

Step 4: Trigger conditions for the behavior (optional)

Step 5: The behavior’s accessibility (optional)

Step 6: The behavior’s return type (optional)

Step 7: A compilable name for the behavior

Step 8: The behavior’s parameters (optional)

Step 9: Any exceptions thrown by the behavior (optional)

Table 3.3 The execution

schedule of a behavior

Step 3a: The behavior’s starting time

Step 3b: The number of randomly selected agents performing

the behavior (optional)

Step 3c: A repeat interval (optional)

Step 3d: An execution priority (optional)

Step 3e: An execution duration (optional)

Step 3f: Whether to shufﬂe scheduling ties (optional)

being optional (Table 3.2). The triangle represents the starting point for what will

become a Java method, and the steps conﬁgure the method’s header and scheduling

details of the behavior.

Steps 1, 2 and 7 are used to describe and name the behavior. We will label it

(step 2) as “Update the current state” and use the compiled name switchState

(step 7). The name for step 7 must conform to the Java rules for method names, and

it is a convention to start method names with an initial lower-case letter. Steps 4, 5,

6, 8 and 9 can be left at their default values for this particular behavior. For instance,

in contrast to properties, we typically want behaviors to be accessible to Everyone

(step 5). That leaves step 3, which is optional. The + symbol immediately to the left

of step 3 signiﬁes that there are several sub-steps involved, 3a through 3f (Table 3.3).

These details determine such things as when the behavior will start to be used (3a)

and how often (3c). Because our agents have their overall behavior broken down

into two sub-steps—ﬁrstly determine the next state; then update the current state—

we will schedule the determination behavior to start at time step 1 and occur every

1 time step, and the update step to start at time step 1.5 and occur every 1 time step.

So we ﬁll in 1.5 for step 3a and 1 for step 3b.

Step 3f allows us to shufﬂe the order in which agents get to act. In some models,

this can be important feature for avoiding bias; for instance, imagine a large number

of agents trying to access a limited number of resources. If the same set of agents

always get to have ﬁrst pick then results could be distorted by this effect. In our

case, order does not matter so we select false for 3f to avoid the unnecessary cost

of shufﬂing.

96 3 ABMs Using Repast and Java

Table 3.4 The steps of a task

Step 1: A comment that describes the task

Step 2: A human-readable diagram label

Step 3: The type of task (optional)

Step 4: A description of the task (optional)

Step 5: Part 1 of the task

Step 6: Part 2 of the task (optional)

Step 7: Part 3 of the task (optional)

Step 8: Part 4 of the task (optional)

Step 9: Part 5 of the task (optional)

The next stage is to deﬁne the actions that will occur each time this behavior is

invoked. We only need to perform a simple assignment from one variable to another,

rather than making any decisions or repeating any operations. Assignment is sup-

ported by the Task ﬂowchart symbol, a square. This is placed beneath the Behavior

triangle. There are nine steps to a task, but steps 5 through 9 all support breaking

down a single task into separate components (Table 3.4). As before, steps 1 and 2

are for a comment and labeling in the diagram. Step 3 offers a sophisticated drop-

down list of possible actions. “Assign an Agent Field” best describes what we want

to do,

and the result of selecting this adds template text to steps 4 and 5. However,

the template text (a=1) does not exactly match the assignment we want so we

change step 5 to read

currentState = nextState

That is all the code we need for this behavior, so we indicate the end of the behav-

ior by adding the End ﬂowchart symbol, an inverted T. This has no steps associated

with it. All that remains is to link the three symbols using the Connection tool from

the ﬂowchart palette. Join the base of the Behavior triangle to the top of the Task

square, and the bottom of the square to the top of the End symbol. The symbols and

lines can be dragged to make a neater appearance, if desired. Use the Select tool for

this. The Select tool can also be used to draw a box around multiple symbols and

then move them together. Figure 3.7 shows how things should now look.

Each time an agent ﬂowchart is saved, an equivalent ﬁle of Groovy source code

is written. This ﬁle can be found via the package explorer under Life → src → life.

Double-click the ﬁle Agent.groovy and browse through the code. It is worth

noting that a lot of additional code is generated automatically from the ﬂowcharts.

For instance, each Property variable has a pair of getter and setter methods. Famil-

iarity with how the ﬂowchart version maps to the Groovy version might make it

easier later on when trying to track down problems with models that do not behave

as expected.

Although note that “agent ﬁeld” should really be “property” in Repast terminology.

3.3 The Game of Life in Repast S 97

Fig. 3.7 Flowchart for updating the current state

3.3.2.4 Setting a Random Initial State

When the Game of Life model starts, we want each agent to be in a random state

of either alive or dead. For this, we will deﬁne an initialization behavior in a similar

way to the update behavior. This will make use of Repast’s randomization features.

In addition, it will differ from the update behavior in that we will not deﬁne a sched-

ule for it: once it has been executed at the start of the simulation, agents won’t need

to execute it again.

We start with a Behavior icon and set its compiled name (step 7) to initial-

izeState. We leave step 3 blank to indicate that this behavior should not be

scheduled. This means that we will have to write code elsewhere to invoke it. We

will see how to do this when writing the model initializer in Sect. 3.3.3.

We will break the behavior down into two separate tasks: ﬁrst drawing a random

number in the range 0.0to1.0, and then using a value less than 0.5 to set an initial

state of 0 and other values to set a state of 1. After placing a task icon, select the

drop-down list in step 3. There is a block of actions headed Statistics that allow

use of a range of different random number generation techniques, such as drawing

from Exponential, Gamma, and Poisson distributions. We will choose the option,

“Assign a uniform random number between 0.0 and 1.0”. The result is the template

code

x = RandomDraw()

98 3 ABMs Using Repast and Java

added to step 5. We need to add a type to the variable in order to declare it, so we

edit the template text to read

double x = RandomDraw()

If we wished, we could add further code in steps 6–9, but we prefer to make the

assignment to currentState in a separate task immediately under this one. This

is just a matter of taste, however. In the new task we select, “Assign an Agent Field”

for step 3. There are various ways in which we could turn the random number into

either a zero or one, such as

currentState = (int) (x + 0.5)

This shifts the range of values in x to be 0.5 ...1.5 and then uses integer truncation

to yield either 0 or 1. Instead we prefer

currentState = (x < 0.5?0:1)

which assigns 0 to currentState if x is less than 0.5, and assigns 1 otherwise.

Both versions require less ﬂowchart code than using a Decision.

The behavior

is completed, as before, with an End symbol and connecting the four symbols.

3.3.2.5 Calculating the Next State

The process of calculating the model’s next state is the most complex behavior to

be programmed. It gives us the chance to see how both decisions and loops are

programmed in the ﬂowchart editor. The process for determining the next state of

an agent is outlined in Sect. 2.3 on p. 31. We restate it here in pseudo-code that is

closer to the form we want to program it in:

intcount=0

for each neighbor in the Moore neighborhood of this cell

add the neighbor’s currentState value to count

end for

if count is less than 2 or count is greater than 3

then nextState = 0

else if currentState is 1

then nextState = 1

else if count is 2

then nextState = 0

else nextState = 1

end if

Of course, the intermediate variable x could have been avoided altogether by using Random-

Draw() directly in its place in the second task.

3.3 The Game of Life in Repast S 99

Here are the stages we use to deﬁne this behavior in full. You might like to look

ahead to Fig. 3.9 to see how this will ultimately look.

• Start with a Behavior symbol, naming it determineNextState,givingita

starting time of 1 (step 3a) and a repeat interval of 1 (step 3c).

• Add a Task to initialize a count variable to zero for recording neighbor states.

This is done by simply writing

int count = 0

in step 5 of the task’s properties.

• Add a task to obtain the Moore neighborhood for the agent. This is easily done

using the drop-down list under step 3 of the task. The section labeled “Queries”

has numerous options categorized by different projection types, for instance to

ﬁnd all agents within a particular distance within a continuous projection, or ﬁnd

all connected neighbors in a network project. The Game of Life uses a grid pro-

jection so scroll down to “Queries for Grids” and select, “Get all the itemsList

in the Moore neighborhood of a given item”. Step 5 will be ﬁlled out with the

following template text:

Iterator list =

new MooreQuery(grid, agent, 3, 3).query(

optNestedQueryResult).iterator()

This template text is not quite ready to use as it represents a generic Moore

query of an agent’s neighbors, rather than one that is speciﬁc to our needs.

The optNestedQueryResult is not needed and can be deleted. The agent

name refers to the agent whose neighbors we want to ﬁnd. It should be replaced

by this, which is Java’s way of referring to the current agent. The two 3 values

relate to how far in the x and y directions we want to look for neighbors. We are

only interested in immediate neighbors, so these values are both replaced with 1.

The remaining item is grid, which needs to be replaced with a reference to

the Grid projection of the agents. Agents do not automatically contain references

to either their projections or their contexts—recall that they could be in an ar-

bitrary number of either. Therefore, we have to search for the projection in two

stages: ﬁrst obtain the agent’s context, and then the speciﬁc projection (named

World in this particular case) from that context. The ContextUtils class

helps us to obtain the context. This is how we obtain a reference to the grid

ContextUtils.getContext(this).getProjection("World")

This sort of lookup of context and projection is very common when programming

agent behaviors, so it is worth paying particular attention to it. The full, rewritten

query is as follows

Iterator list =

new MooreQuery(

ContextUtils.getContext(this).

getProjection("World"), this, 1, 1).

query().iterator()

100 3 ABMs Using Repast and Java

The beauty of this query operation is that it takes care of all the tricky details of

querying neighbors, such as what to do if the agent is on the edge of the grid and

has fewer neighbors than an internal agent, and how to avoid including the agent

itself in the list.

• The result of the Moore query is a standard Java Iterator object. This allows

us to iterate over the list of neighbors of the current agent using a loop structure.

Add a Loop symbol below the task. This has four steps to be ﬁlled out, with a

drop-down list available for step 3. Selecting this shows a range of templates for

typical looping operations, such as

inti=0;i<10;i++

The one that ﬁts our requirements best is

a in List

because we want to iterate through every item in a named list. Select this and edit

the template text in step 4 to be something like

neighbor in list

Notice that list must correspond to the name of the iterator from the Moore

query, and neighbor is the name that we will use for each agent in the list in

turn as the loop is executed.

• The body of the loop is simple: we want to update the count variable with

the current state of the neighbor being considered on this iteration. We add a task

symbol and place it to the right of the loop symbol. There is no particular template

text for this speciﬁc situation, so we opt for Assign a variable in step 3, and ﬁll

out step 5 as

count += neighbor.currentState

The += symbol increments the variable on the left with the value on the right.

No further code is required in the body of the loop but the task must be linked

to the loop symbol. Loops symbols can have two links from them, one directed to

the tasks in the body of the loop and the other directed to the tasks that follow the

loop once the iteration is completed. The ﬁrst will be displayed with a true label

and the second with false.Thetrue exit is always assumed to be the ﬁrst one

linked from the loop symbol. Add a link the loop symbol to the assignment task.

The assignment task does not need a connection out from it.

• The steps so far have allowed us to ﬁnd out how many of the current agent’s

neighbors are alive. Now we have to apply a sequence of tests to count and the

agent’s current state to determine the next state of this agent. Place a Decision

symbol (diamond shape) beneath the loop symbol and link from the loop to the

decision. This link should have a false label automatically attached to it. A suit-

able label for the decision (step 2) might be, “Too many or too few?” From the

It may be worth noting that it is not necessary in Java to use a get- or set-method when objects of

the same type access each other’s properties, regardless of whether they are private or not.

3.3 The Game of Life in Repast S 101

Fig. 3.8 Loop and decision symbols

step 3 list the template described as “A sample Or check” is appropriate, which

gives the template text

(attribute < 10) || (time > 5)

in step 4. This text needs some work because neither the variable names nor the

values ﬁt our particular requirements. Click in the Value part of step 4 and select

Edit Using Text Box Dialog.. . from the drop-down list. This brings up a simple

editing window where we can make the necessary changes to turn the template

text into

(count < 2) || count > 3)

Figure 3.8 shows the current state of the agent’s behavior.

• A decision symbol has two connections, one to the tasks to be performed if the

decision is true, and the other if it is false. If the decision is true, a simple as-

signment task is required that sets nextState to be 0, indicating that this agent

will be dead at the next step. If the decision is false, a further decision is required

to test whether the currentState is 1. A further decision is required if this

second decision is false. Figure 3.9 shows the complete version of this behavior

with its sequence of decisions and assignments to nextState.

We have now completed the implementation of the Game of Life agent. Once the

model initializer has been completed we will be able to run the model.

102 3 ABMs Using Repast and Java

Fig. 3.9 A sequence of

decisions to determine the

next state