Big Idea 3: Algorithms and Programming · Topic 3.16 · Coding Practice
Simulations — Code It Yourself
Write real code and check it against the expected output. Pick Python or JavaScript; the AP pseudocode reference is there when you need it.
You warmed these up on paper in the Trace the Rain Simulation and Audit for Bias exercises. Now build and run the same weather model for real, hardest last. Because RANDOM makes the raw output change every run, each problem grades a DETERMINISTIC property or summary of many trials — never a single random draw. Predict what will print before you run it.
Problem 1 of 4
Simulate one day of weather. Set chance to 40, roll a RANDOM number from 1 to 100, and make the day "rain" if the roll is 40 or less, otherwise "shine". The raw outcome changes each run, so instead print whether the outcome is a valid state: print valid if the day is "rain" or "shine".
This is the abstraction from class: the whole sky collapses to two states. Build sky with an if/else, then a second if checks that sky is "rain" or "shine" — which is always true — so it prints valid no matter what RANDOM rolled.
Problem 2 of 4
Now run the model 1000 times. Loop 1000 days; each day roll RANDOM(1, 100) and count it as rainy if the roll is 40 or less. The rainy count changes every run, so don't print it. Instead count how many days you simulated and print that number (it should be 1000).
Expected output: 1000
Show AP pseudocode reference
days ← 0
rainy ← 0
REPEAT 1000 TIMES
{
days ← days + 1
IF(RANDOM(1, 100) ≤ 40)
{
rainy ← rainy + 1
}
}
DISPLAY(days)
Add 1 to days on every pass of the loop, and add 1 to rainy only when the roll is 40 or less. The number of TRIALS (days) is deterministic — it is exactly 1000 — even though rainy is different each run.
Problem 3 of 4
Turn the run into an inference. Simulate 1000 days and count the rainy days. Compute the rainy fraction (rainy / 1000). This fraction wobbles near 0.40 each run, so instead print valid if the fraction is a legal probability between 0.0 and 1.0 inclusive.
The fraction rainy/1000 is the inference the model exists to produce, and it lands near 0.40 but never exactly. A count of rainy days can never be below 0 or above 1000, so the fraction is always between 0.0 and 1.0 — that property is what you grade on.
Problem 4 of 4
Write a procedure rainyDays(chance, days) from scratch. Inside it, loop days times; each day roll RANDOM(1, 100) and add to a rainy counter if the roll is ≤ chance, otherwise add to a shine counter. Every day must be counted exactly once, so rainy + shine must equal days. Return "balanced" if that invariant holds, else "leak". Then call rainyDays(40, 1000) and print the result.
This is the abstraction as an invariant: because the model classifies every day as exactly one of two states, rainy + shine must equal days no matter what RANDOM rolls. If you forget the else and only count rainy, the totals won't add up and it prints "leak" — so "balanced" proves your two-state logic is correct.
Your code runs on a secure external service. Answers are checked automatically — nothing is stored.
Get in Touch
Whether you're a student, parent, or teacher — I'd love to hear from you.
Just want free AP CS resources?
Enter your email below and check the subscribe box — no message needed.
Students get daily practice questions and study tips. Teachers get curriculum resources and teaching strategies.
Typically responds within 24 hours
✓
Message Sent!
Thanks for reaching out. I'll get back to you within 24 hours.