Page 133 -

130 J.M. Galán et al.

simplification; i.e. the executable model and the programmer’s specifications are
by definition the same (see Fig. 7.3). (We consider two models to be the same
if and only if they produce the same outputs when given the same inputs.) The
programmer’s job consists “only” in writing the executable model in a programming
5
language. If the programmer does not make any mistakes, then the implemented
model (e.g. the code) and the executable model will be the same.
Any mismatch between someone’s specifications and the actual model he passes
to the next stage is considered here an error (see Fig. 7.3). As an example, if the
code implemented by the programmer is not the same model as his specifications,
then there has been an implementation error. Similarly, if the computer scientist’s
specifications are not complete (i.e. they do not define a unique model that produces
a precise set of outputs for each given set of inputs), we say that he has made an
error since the model he is producing is necessarily fully specified (by definition of
the role). This opens up the question of how the executable model is defined: the
executable model is the same model as the code if the programmer does not make
any mistakes. So, to be clear, the distinction between the role of computer scientist
and programmer is made here to distinguish (a) errors in the implementation of a
fully specified model (which are made by the programmer) from (b) errors derived
from an incomplete understanding of how a computer program works (which are
made by the computer scientist). An example of the latter would be one where
the computer scientist’s specifications stipulate the use of real arithmetic, but the
executable model uses floating-point arithmetic.
It is worth noting that in an ideal world, the specifications created by each role
would be written down. Unfortunately the world is far from ideal, and it is often the
case that the mentioned specifications stay in the realm of mental models and never
reach materialisation.
The reason for which the last two roles in the process are called “the computer
scientist” and the “programmer” is because, as mentioned before, most agent-
based models are implemented as computer programs and then explored through
simulation (for tractability reasons). However, one could also think of, e.g. a
mathematician conducting these two roles, especially if the formal model provided
by the modeller can be solved analytically. For the sake of clarity, and without great
loss of generality, we assume here that the model is implemented as a computer
program, and its behaviour is explored through computer simulation.
Once the computer model is implemented, it is run, and the generated results are
analysed. The analysis of the results of the computer model leads to conclusions on
the behaviour of the computer scientist’s model, and, to the extent that the computer
scientist’s model is a valid approximation of the modeller’s formal model, these
conclusions also apply to the modeller’s formal model. Again, to the extent that

5
There are some interesting attempts with INGENIAS (Pavón and Gómez-Sanz 2003)touse
modelling and visual languages as programming languages rather than merely as design languages
(Sansores and Pavón 2005;Sansoresetal. 2006). These efforts are aimed at automatically
generating several implementations of one single executable model (in various different simulation
platforms).