Earlier, I referred to the fact that computers manipulate tokens in the form of bits, variables and complex data structures. And, as I suggested, to play chess the computer must work with some representation of the state of the board as it changes from move to move. Interpreted computer systems, whatever their purpose, all contain representations of this kind. Many computer systems are, of course, imitations in this sense: they are what we daily refer to as models.
Jot down your own definition of the term model.What is a computer model?
I thought the best way of putting it is that a model is a simplified picture of reality. It may be helpful here to think of the sort of models that children like to build. A plastic model of a battleship will reproduce the ship's main structures – guns, decks, hull, superstructure, and so on – but will probably leave out most of the internal workings. It certainly will not include details that are too small to matter, such as the individual cogs of a windlass, or are considered irrelevant, such as flecks of rust on the hull, or a seagull sitting on the stern.
A computer model is obviously more abstract than this, but is essentially the same idea. It is a representation on a computer of some aspect of reality. Since even the tiniest segments of the real world are immensely more complex than anything that could possibly be represented exactly on any known – or foreseeable – computer, models are always simplifications.
But a model of some system found in the world is not necessarily one kind of thing. Broadly speaking, there are three possibilities:
- a simulation of a natural system is a model that captures the functional connections between inputs and outputs of the system;
- a replication of a natural system is a model that captures the functional connections between inputs and outputs of the system and is based on processes that are the same as, or similar to, those of the real-world system;
- an emulation of a natural system is a model that captures the functional connections between inputs and outputs of the system, based on processes that are the same as, or similar to, those of the natural system, and in the same materials as the natural system.
In other words, a simulation provides the correct output for every input that is given to it, but does it using processes that may be quite unlike those of the system it is a model of. A replication arrives at correct outputs using procedures that model the actual processes of the real-world system itself. As for emulations, not only do they produce correct outputs from replications of the processes of the real-world system, the model is made from the same physical substances as that system. If this still seems a bit unclear, it may be helpful to consider a few examples.
This is quite a challenging question, but try to think of at least one example of each of the three kinds of model above. Your examples don't necessarily have to be computer models.
Simulation – A good example of a simulation might be an electronic calculator. It mimics the processes by which we do arithmetic, in that it captures the connection between a certain input, say 2 + 2, and the output (4) that a human would give if presented with this sum. However, you are well aware that the actual processes the computer uses are based on binary arithmetic, which are nothing like the models we would base our own calculations on. The kinds of automata we looked at earlier are also examples of simulations. In the case of such artefacts, the old maxim, 'it walks like a duck, it quacks like a duck, then by God it is a duck!' is simply untrue: they produce duck-like responses to certain stimuli, but internally they don't even faintly resemble ducks.
Replication – You might have found it harder to come up with an example of a replication. Many computer models are based on mathematical abstractions that are nothing like the phenomena they are claiming to represent – so they are simulations. However, other kinds of models do come closer to the phenomena they represent. Models of the Earth's atmosphere, for instance, used by meteorologists for weather prediction, are usually based on fairly explicit representations of the interaction of the air with the land, the oceans and the energy of the sun, so factors such as pressure, temperature, humidity, wind speed, along with the laws that relate them, are generally represented explicitly. In General Circulation Models, for example, the Earth's surface is partitioned into a rectangular grid, with each rectangle the base of a column, extending from the surface to high in the atmosphere. Each column is divided into layers, thus splitting the whole atmosphere into a network of three-dimensional boxes. In each box the temperature, pressure, humidity, wind speed and direction, and other features are recorded. Although it is obviously not possible, with any conceivable computer, to model every single particle of air, such models do attempt to represent the natural phenomena they are based on. A chess-playing computer program is also a good example of a replication: pieces, their positions on the board, moves and constraints are all represented explicitly in the model.
Emulation – In the early 1950s Stanley L. Miller, working at the University of Chicago, conducted an experiment that attempted to clarify what chemical reactions had occurred on the primitive Earth. He created a model of the Earth's oceans by heating water in a flask and forcing water vapour to circulate through the apparatus. The flask also contained a model of the Earth's early atmosphere, consisting of methane, ammonia, hydrogen and the circulating water vapour. Miller then passed a continuous electrical discharge (a model of lightning) through the flask, causing the gases to interact. Water-soluble products of those reactions then passed through a condenser and dissolved in the model ocean. The experiment yielded several amino acids, the building blocks of proteins. Miller's model used the actual chemical constituents that may have existed on the early Earth, and so is an example of an emulation.
Returning to Vaucanson's Duck for the last time, do you think it was an emulation, a simulation or a replication?
A tricky question! To express this in the vocabulary I've just developed, we know that the duck could not have been an emulation (since it was made of metal and not protoplasm). But it's not clear to what extent it was just a simulation (just a lifelike imitation), and to what extent a replication (copying the inner workings of a real duck). And could a replication, in some way, approach the real living thing?
It seems pretty clear that computer models can never be emulations, where it is crucial that the model is built out of the same kinds of physical substance as the real-world system. Pretty well all the models we discuss in this course are attempts at replications of one form or another. To what extent realistic models of intelligence can be genuine replications rather than just simulations is a knotty problem. Defenders of strong artificial intelligence would argue that perfect replications are theoretically possible and that these replications would be intelligent – would be minds. Most researchers would probably deny this.
It's reasonable to think of typical computer replications as large, intricate things. To take our chess example again, the representation of the board and the rules that manipulate it will be a single, very complex model, with many interlocking features. However, one kind of model – one which will turn up a lot in the course – is rather different. It is a model in which many smaller, simple models – usually they are all the same model – are put together and made to interact with one another. There are lots of names for this kind of system. I'll refer to it as a distributed interactive system, or simply a complex system. To clarify this idea and to prepare for later practical work, try the following experiment.
Computer exercise 1
This experiment has two purposes:
- 1 First, to help you build a few basic NetLogo programming skills. Although this course is not principally concerned with programming, a certain amount of familiarity elementary NetLogo will be necessary. Furthermore, many of you may enjoy programming and will want to explore NetLogo in greater depth.
- 2 More significantly, the model you are going to build is intended to give you an insight into some of the ways a system containing a number of simple objects that interact with one another might behave. Such systems turn out often to have quite surprising properties, and the kind of behaviour they display is one of the cornerstones of our investigations in the course.
Before you start this exercise, download the NetLogo programme.
In this simple system, we begin with a line of invisible turtles each sitting on a patch in the topmost row of patches at the top of the microworld. Initially, every patch in the microworld is coloured black except the middle patch of the topmost row, which is coloured red.
Each turtle obeys a very simple procedure. It inspects the colour of the patch it is sitting on, the colour of the patch immediately to its left, and the colour of the patch immediately to its right. Depending on what it finds there, it sets the colour of the patch immediately in front of it either to red or to black, and then marches forward one space to sit on this patch. Every turtle repeats this procedure until the row of turtles has reached the bottom of the screen.
Since the fact of whether the turtle colours the patch in front of it black or red will depend on the colours of its own patch and the patches either side of it, there are clearly lots of possibilities (how many?). Let's start by saying that our turtle obeys this rule:
- IF (left is black AND centre is black AND right is red)
- THEN colour patch in front red
- ELSE colour patch in front black
We can sum up the rule diagrammatically as follows:
Before we move on, note the interactivity of this little model. Not only do turtles interact with the patches around them, but they also interact with each other. Turtles do not affect each other directly; but by affecting the state of the patches around them they also indirectly affect the behaviour of other turtles.
Building the model
- 1 Open a blank NetLogo file.
- 2 First of all, it's going to be important to track exactly where the turtles and the patches are in our world, so we need a system of co-ordinates to track them.
NetLogo gives you complete control over all this. Press the Edit button at the top of the microworld. A dialogue box opens that allows you to set up the system of co-ordinates and the size of the patches. Enter the following settings:
- Location of origin: Center
- max-pxcor: 120
- max pycor: 60
- World wraps horizontally (not vertically)
- Patch size: 2.0
- Font size: 10
Note carefully the co-ordinate system that you've set up. What will be the co-ordinates of the middle patch of the top row?
- 3 We will not build a fancy user interface at this stage: you can always polish it up later on, if you wish. Create two buttons, one to set up the simulation by calling a procedure called setup , and the other to start it off by calling a procedure named go.
- 4 Start programming by writing the setup program. Recall that we want to begin with all patches black except the middle patch in the top row. To do this you will need a couple of NetLogo functions that you've not encountered so far. The y position of the top row of the screen is returned by the function max-pycor and the x position of the centre of the row is 0. patch-at x y returns the patch at x and y ; pcolor-of returns the colour of a patch. Note that x and y are not absolute co-ordinates, but are from the point of view of a particular patch, so pcolor-of patch-at -1 0 will return the colour of the patch immediately to the west of the patch making the call. Write lines in the setup procedure to clear the screen and create our initial setting of the patch colours.
Continue with the setup procedure. We now want to create and initialise our turtles. We can use various shortcuts. Ask all patches to sprout one turtle for us. Naturally, we only want the patches on the top row of the screen to do this, so we can use the command ask patches with [ Conditions ] [ Commands ] to set up the patches. The sprout command is of the form sprout [ Commands ] , where the commands say what we want each sprouted turtle to do. In this case, we want them to turn to a heading of 180 degrees (down the screen) and cloak themselves. You can use the command ht (hide turtle) to do this.
This is all a bit more complex, but try programming it yourself. Pressing the Check button at the top of the Procedures screen, when it is green, will check your code and offer help if you make a mistake. The completed set up procedure is here.
Set up procedure
- 5 Now we can start on the go procedure. Look back at the specification of our model again. We want the procedure to make each turtle examine its own patch and the patches on either side of it, colour the patch in front of it appropriately and then step forward, repeating this process until the line of turtles reaches the bottom of the screen.
So we want to ask all turtles to evaluate their rule, colour the patch in front and then step forward. If they have reached the bottom of the screen - in other words if the y position of their current row of patches, given by pycor , reaches the minimum, that is the end of the simulation and we can make all the turtles vanish, using the handy command die . Then we can make the simulation stop gracefully by using the NetLogo function stop together with the function any? turtles which returns false if the set is empty.
Have a go at this yourself, remembering that you can check the syntax of your code with the Check button. Don't write the code for the rule check and colouring yet; we'll put that in a separate function apply-rule which we will write next.
Note that I inserted an empty procedure apply-rule to please the syntax checker. This does nothing at the moment, obviously; so if I run the simulation, nothing appears to happen, although the invisible turtles have ploughed down to the bottom of the screen.
- 6 Let's now finish up by filling in the apply-rule procedure and see what's happening. Look back at the rule we are applying. Obviously, we need an if-then-else formation. In NetLogo, this looks like
- ifelse Conditions [ Commands1 ] [ Commands2 ]
- If the Conditions evaluate to true, Commands1 is executed, if to false,
- Commands2 is executed.
It's useful to note that the x and y positions of a particular turtle will always be 0, because this is the world seen from its own, egocentric point of view. So the colour of the patch on which the turtle sits is given by pcolor . Look back to the setup procedure for the use of pcolor-of and patch-at .
Apply rule procedure
- 7 Now run your simulation and consider the result.
- 8 Try reversing the rule to become
and run the simulation again.
- 9 However, there are still plenty of other possibilities. Try
You have to make slightly more radical changes to the apply-rule procedure, bringing in the OR logical connective. Alter the rule and run the simulation again.
- 10 This is still a bit bland, but note that even very small changes to the rule mean quite different outcomes. But there are more exciting possibilities: try
You have to make a simple change to the OR condition. Alter the rule and run the simulation again.
- 11 With only another change, you'll get yet another - and different - intricate pattern. Change the procedure to apply this rule.
You may wish to experiment with further rules, or amend the world to wrap vertically, so that you can observe the progress of the rule over a greater number of iterations. The main point of the whole exercise is to demonstrate the power of interaction. The turtles interact with the patches, and indirectly with each other. Given the right circumstances, such a system can produce intricate and surprising patterns. If this seems rather a trivial demonstration, think again. These kinds of systems are known as cellular automata and have been a focus of research in computing and science for many years.