Using packages
[Agent practical 5 of 9]

This practical we're going to use some of the classes in the Java distribution to improve our code. Specifically we're going to randomise the order our Agents get called to run, and we're going to get our Agents to check whether a neighbourhood is clear of other Agents before eating there.

First up, randomising the order of our Agents.

One of the problems of modelling is accurately representing reality inside something that isn't the real system. The most obvious issue is whether we've captured all the behaviour of the real system we need in order to model it in the way we need (a simple thing to say, but a very complicated issue). The second is avoiding the fact that we are running a model *as a model* bleeding into the results. It is quite easy to build model behaviours such that they produce "model artifacts" that is, artificial patterns in the model that are only there *because* it is a model, not a real system.

An example might help. Imagine you have a model that is based on a grid, and the behaviour you are modelling is that if the cell above-and-left of a cell is black, the cell you are dealing with becomes black as well. In one iteration we'll examine *all* the cells and report the colour of the cells before running through them all again for the next time step/iteration. If we start with the following grid:

	a
		b
			c

and take *one* time step, we might expect the following result

	a
		b
			c

however, if we run through our grid cells a row at a time, and left-to-right across our rows, what we actually get in a single time step is this:

	a
		b
			c

because by the time we reach the cell "b", cell "a" has already turned black, and then by the time we reach "c", "b" has turned black. This is purely an artifact of the order in which we update the cells -- if we ran bottom-to-top we wouldn't get it. This, then, is a model artifact -- it has more to do with how the model is running *as* a model, than the reality it is trying to model.

With grid-neighbourhood based models like this, the solution is to put the results into a different grid than the one you're assessing and then copy the results over the assessment grid after all the cells have been assessed at the end of each time step. This ensures the model results of a step don't contaminate the ongoing assessment.

However, for ABM, where agents could be anywhere on the grid, a more classic method is just to randomise the order in which the agents are dealt with. For example, in a economic model, if we always treated the first agent in an array first, they might end up with a negotiating advantage that wouldn't be the case in the real world, where they may come in at different stages of negotiations. Randomisation ensures that no agent is treated continually in a way they wouldn't be in the real world simply because of their order in the model structure.

These kinds of issues are hard to spot, so it is very usual to just, by default, built randomised ordering into ABM. Given this, let's now implement this for our model.