Unit 4 · Algorithms & Simulation · Lessons 4.11–4.12 · Mini-Project

Build a Simulation

Two days. Pick a model, build it with Unit 3 tools, run it at least a hundred times, and answer a real question with the numbers — then write the paragraph about what your model leaves out.

Big Idea 3 — Algorithms & Programming2 days · 20 points

This page is the instructions. You write your code in your editor and your paragraph on the paper packet you get in class. Keep this open beside them.

The Task

A simulation is a program that models something real so you can ask questions you couldn’t afford, survive, or wait out in real life. You’ll build one, run it many times, and use the results to answer a question. It will be simplified — and knowing what you left out matters as much as the code.

One run is a fact. A thousand runs is evidence. A single dice roll tells you nothing about the die. A thousand rolls can tell you it’s rigged. Your simulation has to run enough times to actually answer something.

Pick One Model

Model	The question it answers	Core mechanic
1. Loaded dice	This die rolls a 6 more often than it should. How many rolls before I’m confident it’s rigged?	Compare a fair die against a weighted one over many trials
2. Disease spread	If each sick person infects 2 others per day, how long until the whole school has it?	A list of people; each day, some healthy ones flip to sick
3. Checkout queue	Is one fast cashier better than two slow ones?	Customers arrive at random; track how long each waits
4. Streaks	How often does a fair coin give 5 heads in a row? Is that “lucky” or just normal?	Flip many times, track the longest run

Scope check. Two days. No graphics, no files, no internet. If your model needs a map, a picture, or downloaded data — shrink it. The best projects here are about 30 lines. The queue model is the most interesting and the easiest to overbuild; if you’re unsure, pick dice or streaks.

Write your question first, on page 1 of the packet, and get it approved. A good question has a countable answer (“how many days?”), not a vague one (“will there be a pandemic?”).

Requirements — all four

Your simulation must have

□ Randomness. Use random to create variability. Real life isn’t identical every time; neither is your model.

□ A list. It holds your population, your results, or your trial outcomes.

□ A procedure with a parameter that changes the outcome — run_trial(days), simulate(num_flips), spread(people, rate). Changing the argument must visibly change the result.

□ Many trials. Run it at least 100 times and report the average, the count, or the distribution — not a single outcome.

Requirement 4 is the one students skip — and it’s the one the whole unit is about. Reporting one trial as your answer is the most common way to lose points on this project. And don’t forget the purpose sentence comment at the top of your program.

The Model

Every one of the four models fits this skeleton. Copy the shape, fill in the middle:

Python — skeleton

# Simulates ___ to find out ___.
import random
def run_one_trial(setting):
    # ONE run. Uses random.
    ...
    return result
results = []
for i in range(1000):
    results.append(run_one_trial(5))
print("Trials:", len(results))
print("Average:", sum(results) / len(results))

Where each requirement lives

# purpose sentence
# randomness
# procedure + PARAMETER
# get ONE run right first
# your model goes here
# hand back one outcome
# the LIST of outcomes
# MANY trials (100+)
# argument you can change
# summarize, don't just
# print one result

Hover or tap a line to light its twin. Day 1 target: run_one_trial working for a single run — print it, trace it. Don’t build the 1000-trial loop until one trial is right. Debugging 1000 wrong runs is miserable.

See One Run — loaded dice

Here’s model 1 behaving the way yours should: a fair die and a die weighted to roll 6 about 25% of the time, compared over many trials. Try a small number of rolls, then a big one. When can you actually tell them apart?

rolls per die:

The Writing — graded hardest

The abstraction paragraph is worth more than any single piece of code. Simulations are useful because they simplify — and dangerous for the same reason. Reserve the last 20 minutes of Day 2 for it.

Your paragraph must answer all three

□ What did your model keep? Name the real-world features you actually represented in code.

□ What did it leave out? Name at least two specific things about the real situation your program does not represent at all.

□ Why does that matter? For at least one omission, explain how it could make your answer wrong or misleading if someone acted on it.

Weak

“My disease simulation is not totally realistic because real life is more complicated.”

Strong

“My model gives every person the same chance of infection each day. In a real school, people cluster in classes and at lunch, so some students have far more contact than others. My model would predict a smooth spread, but a real outbreak would probably hit one friend group hard and barely touch students on the other side of campus — so my ‘whole school in 9 days’ number could be badly wrong about who gets sick and when.”

What the strong version does. It names a specific thing the model assumes, says what reality does instead, and follows the consequence all the way to the answer. “Real life is more complicated” earns nothing — it’s true of every model ever built.

How the 20 Points Split

Program runs and models the chosen scenario3

Uses random to create variability2

Uses a list to hold population or results2

Procedure with a parameter that demonstrably changes the outcome3

Runs 100+ trials and reports a summary, not a single outcome3

States the question and answers it from the numbers produced2

Abstraction paragraph — names 2+ specific omissions3

Abstraction paragraph — explains why an omission could mislead2

Total20

Turn in: your program (purpose sentence at the top), your results (the numbers it produced), a one-sentence answer to your question that points at those numbers, and the paragraph.

If You’re Stuck — and If You’re Done

Stuck

Don’t know where to start: write run_one_trial first. Get one run working. Print it.

Every run gives the same answer: your random call is outside the loop, or you set random.seed() to a fixed value.

The parameter doesn’t change anything: check you actually use it inside the procedure, instead of a hard-coded number. Run it twice with different arguments and compare.

Results look impossible: print one trial’s details and trace it by hand — the Lab 3.10 habit.

Done early — the challenge tier

Change one parameter systematically — infection rate 1, 2, 3, 4, or weight 20%, 25%, 30% — and make a table of how the outcome shifts. That’s Unit 5’s data work arriving early, and your results may get a sequel there.

Why this is on the exam. Simulation questions ask why you’d simulate, what randomness is for, and what a model simplifies. Your paragraph is the third one — the one students answer worst. And a procedure with a parameter that changes the outcome is, not by coincidence, the Create PT’s core requirement.