Chapter 1 — Calculus I
Lesson map
Lesson 01 published. Map, example, EX001.
flowchart TD
N0["Learning outcomes"]
N1["1.1 The project behind the course"]
N2["1.2 Rates of change"]
N3["1.3 Functions of time"]
N4["1.4 Why rates matter for design"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX001"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["1.1 The project behind the course"]
N2["1.2 Rates of change"]
N3["1.3 Functions of time"]
N4["1.4 Why rates matter for design"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX001"]
[Learning outcomes]
|
v
[1.1 The project behind the course]
|
v
[1.2 Rates of change]
|
v
[1.3 Functions of time]
|
v
[1.4 Why rates matter for design]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX001]
Learning outcomes
You will (1) use rates of change to describe how endpoint problems grow; (2) read simple functions of time; (3) connect calculus ideas to the course's engineering project.
1.1 The project behind the course
Mateo Rossi is an engineering student at the fictional Ardmore Institute of Technology. Throughout this five-year course he works with the fictional Fernhill Library Network, which offers 300 public-access computers across three branches: Central, Eastgate and Millbrook. Last spring a patron found another person's CV and bank statement left on a public PC, and staff regularly find toolbars and games installed by users. Fernhill's IT lead, Marta Silva, wants a public PC service that resets itself to a known, hardened state every night. Mateo's supervisor, Dr Hana Novak, agrees that this will be his running engineering project.
1.2 Rates of change
Calculus studies how quantities change. If unwanted software accumulates on unmanaged PCs at a roughly steady rate, the number of affected PCs grows linearly with time; if one infected PC spreads problems to others on the same network, growth can become faster than linear. The derivative describes the rate at that moment.
For Fernhill the difference matters. Steady accumulation can be handled by periodic clean-ups; faster growth means waiting makes each clean-up harder. Mateo checks which pattern Fernhill's records show before choosing a design.
1.3 Functions of time
Mateo models the share of PCs with leftover personal files as a function f(t) of days since the last manual clean-up. Fernhill's records suggest about three new cases per day across the network, so f grows by roughly one per cent of the fleet each day until staff intervene.
The function is simple, but it already answers a useful question: after a week without attention, about a fifth of the fleet would hold someone else's files. Mateo states that estimate with its assumptions.
1.4 Why rates matter for design
A nightly restore resets f to zero every 24 hours. Instead of letting problems accumulate for weeks, the design limits exposure to a single day. Thinking in rates makes the benefit of frequent resets visible.
The same reasoning applies to unwanted software. A toolbar installed in the morning disappears by the next opening, so it can affect at most one day of patrons. Mateo writes this down as the main argument for the project, because it explains the benefit without technical terms. It also shows the limit: anything that happens during a single day is still exposed until the reset, so other controls are needed for the hours in between.
1.5 Limits and approximation
Real data are noisy; a smooth function is an approximation. Engineers use it to reason, then check it against measurements.
Mateo's model assumes three cases a day, every day. Fernhill's records show quieter Sundays and busier Mondays, so the real curve has steps rather than a straight line. He keeps the simple model for explaining the idea to managers and compares it with the counted cases each month. If the two drift apart, the model is revised rather than the data being ignored. A model that is never checked becomes a story people repeat.
Worked example
Mateo plots Fernhill's manual clean-up records over three months. Between clean-ups, the count of PCs with leftover files rises almost linearly, about three per day, then drops to near zero after each clean-up. He sketches the same curve under nightly restore: a saw-tooth that never rises above a day's worth of cases.
Synthetic case. Mateo, Dr Novak, Marta and Fernhill are synthetic.
Errors and limits
A model fitted to a few months may not hold during busy periods such as exam season.
Exercises
- EX001 — Project goal. What does Marta want the public PC service to do? Rubric: 3 = reset nightly to known hardened state; 2 = partial; 1 = vague; 0 = none.
- EX002 — Growth rate. How fast did leftover-file cases grow between clean-ups? Rubric: 3 = about three per day, roughly linear; 2 = partial; 1 = vague; 0 = none.
- EX003 — Saw-tooth. Describe the curve under nightly restore. Rubric: 3 = saw-tooth limited to one day's cases; 2 = partial; 1 = vague; 0 = none.
Synthesis
Rates of change show why frequent resets limit exposure.