Lesson map
Lesson 04 published. Map, example, EX010.
flowchart TD
N0["Learning outcomes"]
N1["4.1 First analysis program"]
N2["Lab — Summarising weekly report counts"]
N3["4.2 Handling personal data"]
N4["4.3 Reading the result"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX010"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["4.1 First analysis program"]
N2["Lab — Summarising weekly report counts"]
N3["4.2 Handling personal data"]
N4["4.3 Reading the result"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX010"]
[Learning outcomes]
|
v
[4.1 First analysis program]
|
v
[Lab — Summarising weekly report counts]
|
v
[4.2 Handling personal data]
|
v
[4.3 Reading the result]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX010]
Learning outcomes
You will (1) write simple programs to analyse behaviour data; (2) handle personal data carefully in code; (3) test programs with known cases.
4.1 First analysis program
Aiko writes her first Python program to summarise synthetic weekly report counts from Greyford's report button. It reads a list of numbers, computes the total, the average and the week with the most reports, and prints the result. She tests it with a short list where she knows the answer by hand. Testing with known cases is a basic engineering habit, because a program that runs without errors can still give wrong answers if a loop skips the last week or divides by the wrong count.
Lab — Summarising weekly report counts
# Summarise weekly report-button counts after a campaign (synthetic).
weeks = [12, 30, 41, 35, 27, 22, 19, 18, 17, 17, 16, 16]
total = sum(weeks); peak = max(weeks); pw = weeks.index(peak) + 1
print(f"weeks {len(weeks)}, total {total}, average {total / len(weeks):.1f}, peak week {pw} ({peak})")
for i, w in enumerate(weeks, 1): print(f"week {i:2d} {'#' * (w // 2)} {w}")
Run with python3 lab_weekly.py. Verified output:
weeks 12, total 270, average 22.5, peak week 3 (41)
week 1 ###### 12
week 2 ############### 30
week 3 #################### 41
week 4 ################# 35
week 5 ############# 27
week 6 ########### 22
week 7 ######### 19
week 8 ######### 18
week 9 ######## 17
week 10 ######## 17
week 11 ######## 16
week 12 ######## 16
4.2 Handling personal data
Prof. Kerr warns that behaviour data can be personal. Aiko's program works on counts per week, not on names. If she ever needs individual records, she will replace names with random codes and keep the key separately. She writes this rule at the top of her script. Programs that process staff data should collect the minimum needed, because once data is in a spreadsheet it tends to be copied, and copies are hard to track or delete. Prof. Kerr checks the rule during code review.
4.3 Reading the result
The lab shows twelve weeks of reports, peaking in week three after a campaign and settling at a lower level. Aiko notes that the average hides this shape, so she adds a simple printed bar for each week. Seeing the shape matches her calculus model from chapter 1. She learns that a program's output should support the decision at hand: here, when to schedule the next reminder, which the weekly bars make obvious. She saves the output with the date so that later campaigns can be compared against the same weekly pattern and baseline.
Worked example
Aiko writes and tests a program summarising weekly reports, keeps it to counts rather than names and adds a simple bar display to reveal the shape.
Synthetic case. Counts are synthetic.
Errors and limits
Averages hide patterns. Pseudonymised data can still identify people in small groups.
Exercises
- EX010 — Testing habit. Why test with a list whose answer is known?
Show marking criteria
Rubric: 3 = a program can run but still give wrong answers;; 2 = correctness;; 1 = vague;; 0 = none. - EX011 — Lab peak. Which week had the most reports in the lab, and how many?
Show marking criteria
Rubric: 3 = week 3 with 41 reports;; 2 = week 3;; 1 = vague;; 0 = none. - EX012 — Data rule. What rule did Aiko write at the top of her script?
Show marking criteria
Rubric: 3 = use counts; pseudonymise with a separate key if individuals are needed;; 2 = minimum data;; 1 = vague;; 0 = none.
Synthesis
Simple, tested programs on minimal data can reveal patterns that support practical decisions.
Continue studying — chapter 04 of 50
← Chapter 03 (draft) · Course chapter index · Chapter 05 (draft) →