Week 14 / Build a checkable report
Connect the steps and explain the result to another engineer.
Each week supplied part of this workflow: represent a value, apply a rule, process observations, write reusable calculations, handle failures and save the result.
The project supplies 20 records from temperature, humidity and pressure sensors. Build the existing sensor-log summary using these records and the stated validation rules.
Start with the problem
Choose one valid record and one faulty record from the supplied file. Sketch where each should go: read → validate → group → summarise → save. Decide how you will check the result.
Use the Python tools you already know to connect the stages. The main work is agreeing on their inputs and outputs and checking that information survives each step.
By the end: Walk another person through the cleaned CSV, summary and one handled fault. Explain one limitation of the result using evidence from your own run.
The input schema is timestamp,sensor,value. Read → validate → group → summarize → save. Each stage should have a clear input and output so a discrepancy can be localized. Validate structure, known sensor, timestamp, numeric conversion, finiteness and the sensor-specific range.
The supplied fixture has 15 retained and 5 rejected records. Temperature has 6 readings with mean 23.02 °C; humidity has 5 with mean 45.38%; pressure has 4 with mean 1012.86 hPa. These are reference results for the supplied file, not targets to hard-code.
A 75% retained-row rate describes your validation policy on this file. It is not a sensor-accuracy score or proof that the machine is healthy. Valid-range data can still contain bias, stale readings or a swapped sensor label.
If a sensor has no valid values, display count 0 and N/A for statistics. Do not call min() on an empty group or substitute zero. Keep units separate; comparing temperature and pressure means numerically has no shared physical meaning.
Read the example alongside the explanation. Run it in a new notebook cell and change one input to see how it behaves.
temperature_c = [22.5, 23.1, 22.8, 23.5, 24.0, 22.2]
retained = 15
rejected = 5
assert retained + rejected == 20
print(f'Temperature mean: {sum(temperature_c) / len(temperature_c):.2f} C')
print(f'Retained-row rate: {100 * retained / (retained + rejected):.1f}%')Temperature mean: 23.02 C Retained-row rate: 75.0%
This short cell is an independent arithmetic check, not the pipeline implementation. Build and test the complete program through notebook milestones EX01–EX10. Teaching acceptance ranges are temperature −50–60 °C, humidity 0–100%, and pressure 800–1200 hPa, all inclusive.
The sensor project composes reading, validation, grouping, summarising and writing. Each stage must state its accepted input, output and failure policy. A plausible final average cannot establish that the entire pipeline is correct.
Draw a pipeline and track four rows: T1=10, T1=20, T1=missing and T2=30, with compatible units and values allowed by the sensor contracts. Keep accepted and rejected counts beside the flow.
Predict before running. What should T1’s count and mean be? Can sorting, dropping duplicates or replacing the missing value with zero silently change the answer?
Preserve raw data and distinguish per-sensor results from the total accepted-row count. Repeated equal readings may be legitimate observations. Explain the all-invalid case and check the reopened report.
Change one thing. AA asks the next question: can repeated per-sensor scans and a single-pass dictionary compute exactly this same result, and how does their work grow? That comparison is optional here; CP1 first establishes reliable behaviour.
Türkçe: Her aşamanın girdi, çıktı ve hata kuralını belirt. Küçük veriyi elle özetleyerek bütün hattı kontrol et; makul görünen sonuç tek başına kanıt değildir.
Each example changes something about the same problem. Open the ones you want to explore and follow the worked explanation.
20 records; 15 retained; 5 rejected; temperature sum 138.1 over 6 readings
Question: Predict the retained-row rate and displayed temperature mean.
These checks test counts and arithmetic. They do not replace checking each rejected row and the saved output.
After validation, pressure has no retained values
Question: What should count, min, max and mean show?
An explicit absence is a legitimate result. A numeric zero would invent a pressure measurement.
Add 5 °C to every valid temperature in the supplied fixture
Question: Will range validation necessarily detect this bias?
A plausible value is not necessarily an accurate measurement. Investigating bias needs independent evidence such as a reference sensor.
Interactive walkthroughs of Mini Project — Sensor Log Summary. Enable JavaScript to step through code, variables, collections and output. The companion notebook remains available below.
Use the notebook to try the ideas yourself. The steps below connect this week's example to the programming practice.
Something to take away: sensor_data_clean.csv, sensor_report.txt, a rejection record, and a brief handover explaining one independent check and one deliberately injected fault.
Read the notebook's teaching cells before these exercises.
Use the notebook's core and optional labels to choose your workload. This activity fits within guided class time.
Notes stay in this browser. Download a copy to keep them.
Use AI to propose or review individual stages. Keep a record of one suggestion you accepted or corrected and the evidence behind that decision. During practice, ask it to generate adversarial input, then establish the expected outcome yourself. Follow the instructor's AI rules for exams.
You can also review the supplied example with a partner. Use the same inputs to compare the reasoning. Follow the syllabus rules for assessed work.