Simulations: Study Guide (Computer Science Principles 3.16)

Engineers cannot crash a hundred real aircraft to test a new wing design, doctors cannot try a drug on millions of patients before knowing how it spreads, and astronomers cannot run a galaxy forward a billion years. Instead they build simulations: programs that imitate a real thing so that you can experiment on the imitation. This topic explains what a simulation is, why it always simplifies the real world, how random numbers add realistic variation, and how to judge what a simulation can and cannot tell you.

Notation. The exam uses its own pseudocode, not a real programming language. The code in this pack is Marlbridge’s rendering of that reference notation, not a copy of the official sheet: ← is assignment, = tests equality, lists start at index 1, DISPLAY shows a value, and braces mark blocks. Use the Exam Reference Sheet from your teacher for the official wording.

What a simulation is

A simulation is an abstraction of a more complex object or phenomenon, built for a specific purpose. It is a representation that uses varying sets of values to reflect the changing state of the phenomenon. A flight simulator keeps track of height, speed and wind; a weather simulation keeps track of temperature and pressure on a grid; a queue simulation keeps track of how many people are waiting.

Simulations are used to draw inferences: to find out what is likely to happen. They allow you to investigate a phenomenon without the constraints of the real world, and they are most useful when the real-world event is impractical to experiment on because it is:

• too big or too small (a galaxy; the inside of a cell);
• too fast or too slow (a car crash; the movement of continents);
• too expensive or too dangerous (testing a spacecraft; the spread of a disease).

Simulations also facilitate the formulation and refinement of hypotheses. You can try “what if the speed limit were lower?” in seconds, see a result, and use it to decide what to test in the real world.

Abstraction: what to leave out

Every simulation is an abstraction, so building one means removing specific details or simplifying functionality. A traffic simulation might track only each car’s position and speed, ignoring its colour, its passengers and the radio station. That is a good choice, because those details do not affect traffic flow. The skill is to keep the details that matter to the question and to leave out the rest.

Because details are chosen by people, a simulation can contain bias. Bias in a simulation comes from the choices of which real-world elements were included or excluded. If a flood simulation leaves out blocked drains, it will under-predict flooding. The program can be perfectly correct and still give misleading answers because the model is incomplete.

Random numbers and variability

The real world is full of variability: not every day brings the same weather, and not every shopper arrives at the same minute. Random number generators can be used to simulate the variability that exists in the real world. The exam notation has RANDOM(a, b) for this (Topic 3.15). Because results vary, one run of a simulation is a single possible outcome. Running it many times shows what is typical and how much it varies.

Worked example 1: a simple simulation

A weather game uses a simulation of 10 days. Each day has a 30% chance of rain, modelled by RANDOM(1, 10) ≤ 3 (three of ten equally likely values). Count the rainy days.

rainy ← 0
REPEAT 10 TIMES
{
  IF(RANDOM(1, 10) ≤ 3)
  {
    rainy ← rainy + 1
  }
}
DISPLAY(rainy)

Because the result depends on RANDOM, we cannot state the output. We can trace one run by supposing the ten calls returned, in order, 2, 9, 5, 1, 7, 10, 3, 8, 6, 4:

Day	RANDOM(1, 10)	≤ 3?	rainy after
1	2	true	1
2	9	false	1
3	5	false	1
4	1	true	2
5	7	false	2
6	10	false	2
7	3	true	3
8	8	false	3
9	6	false	3
10	4	false	3

Step 1. In this run the values 2, 1 and 3 are at most 3, so there are 3 rainy days: 3.

Step 2. Expect variation. The expected number of rainy days is 10 × 0.3 = 3, but real runs vary. When Marlbridge ran the program five times with different random sequences it counted 3, 4, 2, 5 and 4 rainy days. One run is one possible outcome; many runs show the typical range.

Step 3. What the model leaves out. Real rain comes in spells (a wet day makes another more likely) and depends on the season. This simulation treats each day as independent, so it may predict too many isolated rainy days and too few long wet spells. That simplification is a source of bias.

Check. The count (3) matches the expected value, and the table shows every ≤ 3 result, so no rainy day was missed.

Worked example 2: judging a simulation

A school canteen manager builds a simulation of the lunch queue to decide whether to hire another server. The model assumes:

• a student arrives each minute with a 50% chance (RANDOM(1, 2) = 1);
• one server serves exactly one student per minute;
• students always wait, however long the queue.

Step 1. Say what it includes and excludes, and the effect.

Real-world detail	In the model?	Likely effect on results
Random arrivals	Yes (via RANDOM)	Captures variability from minute to minute
Rush when a class is dismissed	No	Real queues are longer at the start of lunch, so the model under-estimates waiting
Students who give up and leave when the queue is long	No	Real queue lengths are shorter than modelled at the worst times
Time to pay differs by student	No (fixed 1 minute)	Real service is slower for some students, so waiting is under-estimated
Server breaks	No	Real capacity is lower for short periods

Step 2. Draw a conclusion. Two of the omissions push the real queue to be longer than modelled and one pushes it to be shorter. Overall the model probably under-estimates the peak queue, so using it alone could lead to the wrong decision about hiring.

Step 3. Improve the model. Make arrival probability higher for the first 10 minutes, add a random service time, let students leave above a queue length, then compare the output with real counts collected on a few days. If they disagree, refine the model again.

Step 4. Is a simulation appropriate? Yes: it is quick and cheap to test different numbers of servers, and a real experiment (hiring and firing staff to see what happens) would be expensive. But the answer is only as good as the choices made about what to include. A simulation supports a decision; it does not replace checking with real data.

Simulation or real-world experiment?

Choose a simulation when the real thing is too big, small, fast, slow, expensive or dangerous, or when you want to try many variations quickly. Choose a real-world test when the real thing is easy to measure and a faithful model is hard to build. Often you use both: simulate first to narrow the options, then test the best option for real.

Common misconceptions

• “A simulation gives the true answer.” It gives what the model predicts. The model leaves details out and may be biased.
• “More detail always makes a simulation better.” Extra detail can make it slower and harder to check. Include what matters to the question.
• “If the program has no bugs, the simulation is accurate.” Bugs and bias are different. A correct program can still model the wrong thing.
• “One run of a random simulation is enough.” One run is one possible outcome; run it many times.
• “Simulations replace real-world experiments.” They complement them, especially when real experiments are impractical.
• “Simulations contain no bias because computers are objective.” Bias comes from the choices about what to include or exclude.

Where this leads

The last two topics of the unit ask what computers can and cannot do well: Topic 3.17 on how long algorithms take, and Topic 3.18 on problems no algorithm can solve. Simulations return in Unit 5, where bias and the effects of computing on society are examined.

Next steps: try the practice questions, skim the revision notes the night before, and tick off the topic checklist. The next topic is Topic 3.17, Algorithmic Efficiency.