DSCI 512 Lecture 1 : Introduction and Time Complexity

Sky (Kehan) Sheng

Meet your instructor

• Sky (Kehan) Sheng, PhD
• My research bridges AI fairness, animal welfare and data science.
• Contact
  • 📧: skysheng@cs.ubc.ca
  • 💼: ICCS Building Room 187
  • 💬: @Sky on Slack
  • 🕰️ MDS calendar for office hours.

My path to data science:

• Grew up loving animals and wanted to be a vet when i was young
• Volunteered for wildlife rescue in Costa Rica, learned about tracking wild rhino using small satellites, which sparked my curiosity about the behaviour and movement patterns hidden in animal data
• Learned programming and how to analyze animal movement data, which led to a PhD using data science to study animal behaviour, preferences, friendships, and rivalries
• That work grew into research on AI fairness, how human values get embedded (and sometimes distorted) in AI systems

1. Data scientists come from all kinds of backgrounds, that’s what makes this field so interesting.
2. This class is diverse: different majors, experiences, and starting points.
3. You always has something to learn from each other.

DSCI 512 overall learning objectives

• Fundamental data structures and algorithms
• Complexity analysis (time complexity and space complexity)
• Techniques for improving Python code performance.

Course structure

• Lecture notes is a good starting point for you to review the material in advance.
• There are some recommended readings/videos for you to review in advance.
• TA will host weekly review sessions on Friday or Monday, please check out MDS calendar.
• The course is extremely compressed of a “classic” undergraduate course on algorithms and data structures.
• We will use Python.
• Lectures in this section are being recorded, for personal study only as requested by the Centre for Accessibility. The recordings will not be posted or shared.

anything students say out loud may end up on the recording, and that the recording stays with that student for studying.

Grading breakdown

Note

In-person attendence for lab quiz is mandatory.

Assessment	Weight
Lab 1	9%
Lab 2	9%
Lab 3	9%
Lab 4	9%
Lab Live Coding Quiz (Week 1)	4%
Lab Live Coding Quiz (Week 2)	4%
Lab Take-home Coding Quiz (Week 3)	2%
Lab Live Coding + Reasoning Quiz (Week 4)	4%
Quiz 1	25%
Quiz 2	25%

iClicker Set Up for Section 002

join.iclicker.com/AGFP

no marks for iClicker, only for easier in class participation.

What is an algorithm?

Q: what is an algorithm? what is not?

“Season to taste, cook until it looks right.” is not an algorithm.

What is an algorithm? Really.

• An algorithm is a well-defined computational procedure designed to solve a problem.
• provides a sequence of precise steps for transforming input into output in order to arrive at a solution.

Ingredients ≈ input

Recipe ≈ algorithm

cooking recipe is in a way like an algorithm.

What is a data structure?

• A data structure is a way to organize and manage data.

some data structures are faster for you to access the data you are searching for, some data structures are faster to create, update or delete data. Some data structures can store duplicated items, some absolutely refuse to do so. we will learn about when to use what, the pros and cons of using them.

Challenges Past Students Have Faced in This Course

• Difficulty/pace
• Python coding
• Some topics did not seem relevant to data science/AI

this would not be a easy A class, so do need to spend lots of time going through the logic, the algorithms yourself after class. questions always welcome! no stupid question in class the last one –> iclicker question next page

iClicker: Do we still need to learn algorithms and data structures in the AI era?

(A) YES! AI can’t replace my brain!

(B) NO! My bestie ChatGPT knows it all!

(C) Strategically indecisive: “It depends…”

(D) I’m still figuring out what data science is…

Hint: There is no correct answer for this question.

show of hands for each option.

Why learn algorithms and data structures in the AI era?

There is no shortcut to learning how to think

• You can’t outsource your thinking to AI. Exams do test whether you remember python syntax, but the long-term goal of this course isn’t memorizing code, AI is already great at that.

• My own experience: Java was my first language, rarely use it after I graduated, but the logical thinking skills stuck with me.

• This course trains you to be an independent thinker, life-long learner, and problem solver, to approach and solve new problems on your own. To practice systematic thinking and develop algorithmic problem-solving skills. There’s no shortcut to that.

• If you copy-paste AI’s answers into your worksheets, you’re practicing copying and pasting, not thinking. That’s why AI isn’t allowed on tutorials, worksheets, or exams, you need to go through the process yourself, step by step.

• You’ll make mistakes, get stuck, and see scary error messages: that’s how you grow (my personal record is 8 hours debugging one issue!). Think of it like going to the gym: you have to lift the heavy weights yourself to build stronger problem-solving muscles.

• Your judgment and ability to think critically are what will make you stand out in this era.

• Read the book yourself, with your own brain. If you have AI read it for you, the machine is learning — not you.

AI updates every 6 months, but algorithmic fundamentals don’t go out of fashion

• There’s a saying in AI: “If you learn slow enough, you’ll never need to learn again.”
• The best AI models and practices change every ~6 months. Techniques I’ve taught before (prompt engineering → system prompts → agentic workflows → MCP → harnesses) keep going out of date.
• It’s a better investment to spend your time learning the fundamentals — nobody can keep up with every new AI tool all the time.

DSCI 512: Absolute fundamentals a data scientist needs to know

• This course will be very helpful for your technical interviews. algorithmic problem-solving is often tested directly in data science interviews
• Some things don’t go out of fashion no matter how slowly you learn them, these are the absolute fundamentals every data scientist is expected to know.
• Example: in a future job interview, if you’re asked how to calculate time complexity of your code, “let me ask ChatGPT” won’t be the right answer.
• DSCI 512 covers the absolute fundamentals of algorithms and data structures that a data scientist needs to know.

AI evaluation (AI eval) is a fancier term for data science

• Hamel husain is well-known ML engineer (formerly Airbnb, GitHub). he argues that AI evals is a new opportunity/home for data scientists.

every company is rushing towards integerating LLM into their products. but they all struggle with one thing: how do you know if the LLM is performing well?

Say at work your boss asks you to evaluate an LLM’s ability to write code, you will need the tool kits to know how to judge if the code written by LLM is correct and efficient; how to judge if the LLM is writing clean, readable, and maintainable code; and steer the AI towards your goal if it goes off track.

that’s when you need to know identify slow or inefficient code, assess time complexity and space complexity, and that’s exactly what you will learn in today’s class.

Outline of Today’s Lecture

• Course overview ✅
• 🚗 Today’s story: how does Uber find you a ride?
• ⏱️ Code profiling: measure where the time goes
• 📈 Time complexity: predict how the time grows with \(n\)

One story for the whole lecture: Uber. Every piece of code today is something Uber’s app has to do, in the order a ride happens: a rider logs in (do they already have an account?), the app notifies nearby drivers, then matches riders with drivers by estimating pickup times.

🚗 Today’s story: how does Uber find you a ride in seconds?

🚗 Uber’s promise: optimizing everyone’s time

• A ride has 4 stages: request, pick up, drive, drop off. Riders hate waiting, drivers hate idle time.
• Uber claims its matching algorithm saves 10 years of people’s time every day. That number comes from an algorithm, not from a faster phone or a faster server.
• Ask: what does the app actually have to compute between “request” and “pick up”?

🚗 A better algorithm, not a faster computer

• Early days: first to request gets the closest driver. Simple, but across a city the waiting adds up.
• Now: wait a few seconds, collect a batch of riders and drivers, then match the whole batch to minimize everyone’s wait.
• Same drivers, same cars, same phones. The only thing that changed is the algorithm. That’s what this course is about.

🚗 Today, you are Uber’s first data scientist

2010, Vancouver

🚕 🚕 🚕 🚕 🚕 🚕 🚕 🚕 🚕 🚕

\(n = 10\) drivers

Any code works.

Today

🚕 × millions of drivers, billions of trips a year

\(n = 10{,}000{,}000\)

Does your code still work?

The question of the day: if \(n\) (drivers, riders, requests) grows from 10 to 10 million, what happens to the runtime of my code?

• ⏱️ Code profiling: measure it.
• 📈 Time complexity: predict it, before Uber gets big.

• Set up the story: you wrote the first version of the matching code when Uber had 10 drivers. Everything was instant. Then the company took off.
• Real-world version of this question: what would be the runtime of your algorithm if your company rose from 100 customers to 1 million customers?
• Two tools today: profiling (look at the stopwatch) and time complexity (do the math before you run it).

⏱️ Code Profiling

Measure where your code spends its time.

🚗 Scenario 1: does this rider already have an account?

A rider opens the app and logs in. Before anything else, Uber checks: is this rider already in our system, or do we show the sign-up page?

n = 10_000_000                    # 10 million riders (the _ does not change the value, it's for readability)
rider_accounts = list(range(n))   # account IDs of every registered rider: 0, 1, ..., 9_999_999
new_rider = -1                    # someone opening the app for the first time: no account yet
new_rider in rider_accounts       # does this rider already have an account?

False

False → show the sign-up page. But to say False, Python had to compare -1 with all 10 million IDs.

We test using a list to store all the rider ID

• Assume each registered rider has a unique account ID from 0 to 9,999,999.
• We ask about a brand-new rider on purpose: -1 is not in the list, so Python has to compare against every ID before it can say False. This is the worst case (we come back to best/worst case at the end).

⏱️ timeit: search in a list vs. a set

Look up the new rider in a list of 10 million accounts:

import timeit
rider_accounts = list(range(n))
seconds = timeit.timeit("new_rider in rider_accounts", number=10, globals=globals())  # total for 10 runs
print(f"{seconds / 10 * 1e3:.1f} ms per lookup")

70.8 ms per lookup

Look up the new rider in a set of 10 million accounts:

rider_accounts = set(range(n))
seconds = timeit.timeit("new_rider in rider_accounts", number=1_000_000, globals=globals())  # total for 1 million runs
print(f"{seconds / 1_000_000 * 1e9:.1f} ns per lookup")

18.5 ns per lookup

1 ms = 1,000,000 ns. Same question, same riders, different data structure.

• timeit is in the standard library. timeit.timeit runs the statement number times and returns the total seconds, so we divide by number to get the time for one lookup.
• globals=globals() lets the statement see our variables (new_rider, rider_accounts).
• 1 ms = 1,000,000 ns. Read the units carefully: the set is roughly 6 million times faster than list here.
• Why the set is so fast will be explain in the future lectures (hashing). Today: measure first, explain later.

Q: should we just always use set then?

• Why run it many times? One lookup is too fast to measure precisely on its own. So we run it number times, measure the total, then divide by number to get the time for one lookup. The set lookup is so fast that we need a million runs to get a total we can measure.

⏱️ But building the collection costs time too

Time to build the list of 10 million account IDs:

seconds = timeit.timeit("list(range(n))", number=1, globals=globals())  # build it once
print(f"{seconds * 1e3:.0f} ms to build the list")

371 ms to build the list

Time to build the set of 10 million account IDs:

seconds = timeit.timeit("set(range(n))", number=1, globals=globals())  # build it once
print(f"{seconds * 1e3:.0f} ms to build the set")

477 ms to build the set

The set is slower to build but much faster to search. So which one wins over a whole day of logins?

• Trade-off: pay more up front to build the set, win on every single lookup afterwards.
• Uber builds the collection once (when the server starts), then answers “does this rider have an account?” for every login, all day.

🚗 Build once, look up all day: who wins?

Total time = time to build the collection + (number of logins) × time per lookup, using the numbers we just measured.

viewof logins = Inputs.radio(login_chart.choices,
                             {value: 1, label: "logins today", format: d3.format("~s")})

// Draw only: every point and label was computed in Python (login_chart).
{
  const series = ["list", "set"];
  const rows = login_chart.curves;
  const picked = login_chart.picks[logins];      // the two dots for the chosen number of logins
  return Plot.plot({
    width: 860, height: 330, marginLeft: 80, marginRight: 60, marginBottom: 48,
    style: {fontSize: "16px", background: "transparent"},
    x: {type: "log", label: "number of logins →", labelAnchor: "center", grid: true, tickFormat: "~s",
        ticks: [1, 10, 100, 1e3, 1e4, 1e5, 1e6, 1e7]},
    y: {type: "log", label: "↑ total time (s)", grid: true, tickFormat: ",~g",
        ticks: [0.1, 1, 10, 100, 1e3, 1e4, 1e5]},
    color: {domain: series, range: ["#2a78d6", "#eb6834"], legend: true, swatchSize: 16},
    marks: [
      Plot.line(rows, {x: "logins", y: "seconds", stroke: "s", strokeWidth: 2}),
      Plot.ruleX([logins], {stroke: "#52514e", strokeDasharray: "4 4"}),
      Plot.dot(picked, {x: "logins", y: "seconds", fill: "s", r: 6, stroke: "white", strokeWidth: 2}),
      // label the two dots: list label above its dot, set label below it (above it near the
      // right edge, where below would hit the x-axis). dy is a constant, so one mark per series.
      ...[["list", -14], ["set", logins < 1e5 ? 14 : -14]].map(([s, dy]) =>
        Plot.text(picked.filter(d => d.s === s), {x: "logins", y: "seconds", text: d => `${d.s}: ${d.label}`,
                  dx: logins < 1e5 ? 10 : -10, dy, textAnchor: logins < 1e5 ? "start" : "end", fontWeight: "bold"})),
      Plot.tip(rows, Plot.pointer({x: "logins", y: "seconds",
                                   title: d => `${d.s}\n${d3.format(",.0f")(d.logins)} logins\n${d.label}`}))
    ]
  });
}

{
  const breakEven = login_chart.break_even;      // computed in Python
  return html`<div class="ojs-readout">The set has paid for its slower build after only
    <b>${breakEven}</b> login${breakEven === 1 ? "" : "s"}.
    Uber handles millions of logins a day.</div>`;
}

• This is the pattern for the whole course: which data structure is fast for the operation you do most often?
• Both axes are log scale: each grid line is 10× the previous one.

🚗 Scenario 2: notify the nearby drivers

A rider requests a ride. The app sends a push notification to each of the \(n\) nearby drivers.

def notify_drivers(n):
    for driver in range(n):
        time.sleep(0.1)  # 0.1 s each for push notification

cProfile tells us how much time was spent in each function:

import cProfile
cProfile.run("notify_drivers(5)", sort="cumulative")

         9 function calls in 0.501 seconds

   Ordered by: cumulative time

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
        1    0.000    0.000    0.501    0.501 {built-in method builtins.exec}
        1    0.000    0.000    0.501    0.501 <string>:1(<module>)
        1    0.000    0.000    0.501    0.501 1030441696.py:1(notify_drivers)
        5    0.501    0.100    0.501    0.100 {built-in method time.sleep}
        1    0.000    0.000    0.000    0.000 {method 'disable' of '_lsprof.Profiler' objects}

column	what it means
ncalls	how many times the function was called (time.sleep: 5)
tottime	time spent inside the function only, not counting the functions it called
percall (first)	tottime / ncalls, one call on its own (time.sleep: 0.501 / 5 ≈ 0.100 s)
cumtime	time in the function plus everything it called
percall (second)	cumtime / ncalls

We expect 5 × 0.1 s ≈ 0.5 s. Reading our rows:

• builtins.exec, <module>, notify_drivers: cumtime 0.501 but tottime 0.000. They are wrappers: all their time is spent in what they called.
• time.sleep: 5 calls, tottime 0.501. This is where the time goes, the row to fix.

⏱️ LineProfiler: profile line by line

def notify_drivers(n):
    for driver in range(n):
        time.sleep(0.1)  # 0.1 s each

The LineProfiler class from the line_profiler library shows the time on each line:

lp = LineProfiler()
lp.add_function(notify_drivers)
lp.runcall(notify_drivers, 5)
lp.print_stats()

Timer unit: 1e-09 s

Total time: 0.501366 s
File: /tmp/ipykernel_2358/830238303.py
Function: notify_drivers at line 1

Line #      Hits         Time  Per Hit   % Time  Line Contents
==============================================================
     1                                           def notify_drivers(n):
     2         6      17135.0   2855.8      0.0      for driver in range(n):
     3         5  501349029.0    1e+08    100.0          time.sleep(0.1)  # 0.1 s each

• Hits = how many times the line ran, Time = total time on that line, % Time = share of the total.
• Q: why does the for line ran 6 times ? (5 iterations + 1 to find out the loop is over), sleep ran 5 times and took ~100% of the time.

🚗 Twice as many drivers: \(n = 10\)

lp = LineProfiler()
lp.add_function(notify_drivers)
lp.runcall(notify_drivers, 10)
lp.print_stats()

Timer unit: 1e-09 s

Total time: 1.0012 s
File: /tmp/ipykernel_2358/830238303.py
Function: notify_drivers at line 1

Line #      Hits         Time  Per Hit   % Time  Line Contents
==============================================================
     1                                           def notify_drivers(n):
     2        11      29982.0   2725.6      0.0      for driver in range(n):
     3        10 1001171521.0    1e+08    100.0          time.sleep(0.1)  # 0.1 s each

{
  const calls = ["notify_drivers(5)", "notify_drivers(10)"];
  const data = profiled.filter(d => calls.includes(d.call));
  return Plot.plot({
    width: 560, height: 260, marginLeft: 70, marginTop: 30,
    marginBottom: 48, style: {fontSize: "16px", background: "transparent"},
    x: {label: null, domain: calls},
    y: {label: "↑ measured runtime (s)", grid: true, domain: [0, d3.max(data, d => d.seconds) * 1.2]},
    marks: [
      Plot.barY(data, {x: "call", y: "seconds", fill: "#2a78d6", rx: 4, insetLeft: 40, insetRight: 40}),
      Plot.text(data, {x: "call", y: "seconds", text: d => d.seconds.toFixed(2) + " s", dy: -10, fontWeight: "bold"}),
      Plot.ruleY([0])
    ]
  });
}

Double the drivers → double the runtime.

• 10 hits on sleep, 1.0 s total. The bar chart is drawn from the measured numbers above.
• One loop over \(n\) things: runtime grows in proportion to \(n\).

🚗 Scenario 3: match every rider with every driver

Uber collects a batch of \(n\) riders and \(n\) drivers. For every rider, it estimates the pickup time from every driver.

🤔 How long would it take to match 5 riders with 5 drivers?

def match_riders(n):
    for rider in range(n):
        for driver in range(n):
            time.sleep(0.1)  # 0.1 s each

lp = LineProfiler()
lp.add_function(match_riders)
lp.runcall(match_riders, 5)
lp.print_stats()

Timer unit: 1e-09 s

Total time: 2.50309 s
File: /tmp/ipykernel_2358/2699516187.py
Function: match_riders at line 1

Line #      Hits         Time  Per Hit   % Time  Line Contents
==============================================================
     1                                           def match_riders(n):
     2         6       6348.0   1058.0      0.0      for rider in range(n):
     3        30      79927.0   2664.2      0.0          for driver in range(n):
     4        25 2503004614.0    1e+08    100.0              time.sleep(0.1)  # 0.1 s each

• 5 riders × 5 drivers = 25 estimates = 2.5 s.
• Q: Why is: inner for line: 30 hits? why the sleep line: 25 hits?

🚗 Double the batch: \(n = 10\)

🤔 How long does it take if we double the number of riders and drivers?

lp = LineProfiler()
lp.add_function(match_riders)
lp.runcall(match_riders, 10)
lp.print_stats()

Timer unit: 1e-09 s

Total time: 10.0124 s
File: /tmp/ipykernel_2358/2699516187.py
Function: match_riders at line 1

Line #      Hits         Time  Per Hit   % Time  Line Contents
==============================================================
     1                                           def match_riders(n):
     2        11      10434.0    948.5      0.0      for rider in range(n):
     3       110     300382.0   2730.7      0.0          for driver in range(n):
     4       100        1e+10    1e+08    100.0              time.sleep(0.1)  # 0.1 s each

{
  const calls = ["notify_drivers(5)", "notify_drivers(10)", "match_riders(5)", "match_riders(10)"];
  const data = profiled.filter(d => calls.includes(d.call));
  return Plot.plot({
    width: 760, height: 250, marginLeft: 70, marginTop: 30,
    marginBottom: 48, style: {fontSize: "16px", background: "transparent"},
    x: {label: null, domain: calls},
    y: {label: "↑ measured runtime (s)", grid: true, domain: [0, d3.max(data, d => d.seconds) * 1.15]},
    color: {domain: ["notify_drivers", "match_riders"], range: ["#2a78d6", "#eb6834"], legend: true, swatchSize: 16},
    marks: [
      Plot.barY(data, {x: "call", y: "seconds", fill: "func", rx: 4, insetLeft: 25, insetRight: 25}),
      Plot.text(data, {x: "call", y: "seconds", text: d => d.seconds.toFixed(1) + " s", dy: -10, fontWeight: "bold"}),
      Plot.ruleY([0])
    ]
  });
}

One loop: double \(n\) → 2× the time.

Nested loop: double \(n\) → 4× the time.

• 10 × 10 = 100 estimates = 10 s. Doubling \(n\) quadrupled the runtime.
• Now imagine \(n\) = 10,000 riders and drivers in a city at rush hour: 100 million estimates. At 0.1 s each that’s about 4 months for one batch. The algorithm, not the computer, is the problem.

🚗 Same \(n = 5\), each estimate twice as slow

🤔 When we get slow network, the communication time doubles, how long does it take now?

def match_riders_slow(n):
    for rider in range(n):
        for driver in range(n):
            time.sleep(0.2)  # now 0.2 s each

lp = LineProfiler()
lp.add_function(match_riders_slow)
lp.runcall(match_riders_slow, 5)
lp.print_stats()

Timer unit: 1e-09 s

Total time: 5.0031 s
File: /tmp/ipykernel_2358/2699578360.py
Function: match_riders_slow at line 1

Line #      Hits         Time  Per Hit   % Time  Line Contents
==============================================================
     1                                           def match_riders_slow(n):
     2         6       8573.0   1428.8      0.0      for rider in range(n):
     3        30      85967.0   2865.6      0.0          for driver in range(n):
     4        25 5003008577.0    2e+08    100.0              time.sleep(0.2)  # now 0.2 s each

• Same 25 hits, each one slower. This is for example, what a slower network does: it scales the whole thing by a constant.

🚗 How does runtime changes?

// Draw only: runtimes and ratios were computed in Python (slow_vs_growth).
{
  const data = slow_vs_growth;
  const after = data.filter(d => d.bar === "after");
  return Plot.plot({
    width: 820, height: 320, marginLeft: 70, marginTop: 64, marginBottom: 34,
    style: {fontSize: "16px", background: "transparent"},
    fx: {label: null, axis: "top", padding: 0.12, domain: [...new Set(data.map(d => d.panel))]},   // one panel per kind of doubling, titles on top
    x: {axis: null, domain: ["before", "after"], padding: 0.25},
    y: {label: "↑ measured runtime (s)", grid: true, domain: [0, d3.max(data, d => d.seconds) * 1.3]},
    color: {domain: ["baseline", "constant factor", "growth with n"], range: ["#b8b6b0", "#2a78d6", "#eb6834"]},
    marks: [
      Plot.barY(data, {fx: "panel", x: "bar", y: "seconds", fill: "kind", rx: 4}),
      Plot.text(data, {fx: "panel", x: "bar", y: "seconds", text: d => d.seconds.toFixed(1) + " s", dy: -10}),
      // the headline: how many times longer than the baseline
      Plot.text(after, {fx: "panel", x: "bar", y: "seconds", text: d => d.ratio.toFixed(1) + "×",
                        dy: -32, fontSize: 22, fontWeight: "bold", fill: "kind"}),
      Plot.text(data, {fx: "panel", x: "bar", y: 0, text: "call", dy: 14, fill: "#52514e"}),   // call name under each bar
      Plot.ruleY([0])
    ]
  });
}

• Each step twice as slow → runtime 2× (2.5 s → 5 s). A constant factor.
• Twice as many riders and drivers → runtime 4× (2.5 s → 10 s). Growth with \(n\).
• Big O notation (next section) cares about the second kind, not the first.

the slow-ness of one opeation does not really hurt that much in the long run. \(n\) matters the most in the long run, which measures how does the number of steps grow as \(n\) gets bigger. - Doubling \(n\) changed the number of steps; doubling the sleep changed the cost per step.

📈 Time Complexity

Predict how the runtime grows as \(n\) gets bigger, before Uber gets big.

Q: what are liitations with just measuring runtime through experiment?

Limitataions with measuring runtime through experiment: - what if your n is too large and it takes forever to run? - the actual run time is affected by other things like how fast your laptop is, how many other tabs you have open, etc.

Important to quantify how many steps approximately the algorithm will take before running it.

📈 The experiment: run both for \(n = 1, 2, \dots, 30\)

Same two Uber functions, but each step now takes 1 ms instead of 0.1 s so we can try many values of \(n\).

def notify_drivers_1ms(n):
    for driver in range(n):
        time.sleep(0.001)

def match_riders_1ms(n):
    for rider in range(n):
        for driver in range(n):
            time.sleep(0.001)

• We profiled \(n = 5\) and \(n = 10\). Now we measure \(n\) from 1 to 30 and look at the shape.

📈 Drag \(n\) and watch the runtime grow

viewof n_max = Inputs.range([1, 30], {step: 1, value: 5, label: "n (riders = drivers)"})

{
  const at = f => growth.find(d => d.function === f && d.n === n_max).seconds;
  return html`<div class="ojs-readout">
    At n = <b>${n_max}</b>:
    <span class="notify">notify_drivers</span> (one loop) = ${at("notify_drivers_1ms").toFixed(3)} s &nbsp;·&nbsp;
    <span class="match">match_riders</span> (nested loop) = ${at("match_riders_1ms").toFixed(3)} s</div>`;
}

{
  const names = ["notify_drivers (one loop)", "match_riders (nested loop)"];
  const shown = growth.filter(d => d.n <= n_max);                 // measured in Python
  const last = names.map(l => shown.filter(d => d.label === l).at(-1));   // where to put the line labels
  return Plot.plot({
    width: 860, height: 360, marginRight: 200, marginLeft: 70,
    marginBottom: 48, style: {fontSize: "16px", background: "transparent"},
    x: {label: "n (riders = drivers)", labelAnchor: "center", domain: [0, 31], grid: true},
    y: {label: "↑ measured runtime (s)", domain: [0, d3.max(growth, d => d.seconds) * 1.08], grid: true},
    color: {domain: names, range: ["#2a78d6", "#eb6834"], legend: true, swatchSize: 16},
    marks: [
      Plot.line(shown, {x: "n", y: "seconds", stroke: "label", strokeWidth: 2}),
      Plot.dot(shown, {x: "n", y: "seconds", fill: "label", r: 4, stroke: "white", strokeWidth: 1}),
      Plot.text(last.filter(d => d.n >= 8), {x: "n", y: "seconds", text: "label",
                       dx: 10, textAnchor: "start", fontWeight: "bold"}),
      Plot.tip(shown, Plot.pointer({x: "n", y: "seconds",
                                    title: d => `${d.label}\nn = ${d.n}\n${d.seconds.toFixed(4)} s`})),
      Plot.ruleY([0])
    ]
  });
}

• Start at \(n = 5\), drag slowly. The one-loop function grows in a straight line; the nested-loop function bends upward.
• At \(n = 10\) vs \(n = 20\): one loop doubles, nested loop quadruples. Same rule as with the profiler, now for every \(n\).
• Ask: where would \(n = 10{,}000\) be on this plot? (Off the top of the room.)
• The 1 ms step is just a scaled-down 0.1 s: the shape is what matters, not the units.

📈 Big O notation

• Time complexity is commonly written with big O notation, which measures the approximate number of steps an algorithm performs as a function of the input size \(n\).
• Big O notation only cares about how fast it grows as \(n\) gets larger.

Uber function	steps	big O	name
notify_drivers(n): one loop	\(n\)	\(O(n)\)	linear
match_riders(n): nested loop	\(n \times n\)	\(O(n^2)\)	quadratic

• Definition (optional): \(f(n)\) is \(O(g(n))\) if there is a positive number \(M\) such that \[f(n) \leq M\, g(n) \text{ for all large enough } n.\]

• Big O is the vocabulary for the shapes we just saw: the straight line is \(O(n)\), the curve is \(O(n^2)\).
• \(M\) absorbs the cost per step (0.1 s, 1 ms, a faster computer): big O does not care about that constant.

📈 The doubling rule

Big O	name	double \(n\) → runtime
\(O(1)\)	constant	same
\(O(\log n)\)	logarithmic	+ a constant
\(O(n)\)	linear	2×
\(O(n \log n)\)	linearithmic	a bit more than 2×
\(O(n^2)\)	quadratic	4×
\(O(n^3)\)	cubic	8×
\(O(n^k)\)	polynomial	\(2^k\)×
\(O(2^n)\)	exponential	squared

• Why 8× for \(n^3\): \(\dfrac{g(2n)}{g(n)} = \dfrac{(2n)^3}{n^3} = 8\).
• Why “squared” for \(2^n\): \(g(2n) = 2^{2n} = (2^n)^2\).
• ⚠️ Exponential is the worst! Adding just one rider already doubles it: \(\dfrac{2^{n+1}}{2^n} = 2\).
• \[1 \;<\; \log n \;<\; n \;<\; n \log n \;<\; n^2 \;<\; n^3 \;<\; 2^n\]

Note for self: - Write down the math for O(n), O(n^2), O(log n) step by step

• \(O(1)\) is the set lookup from Scenario 1 (account check); \(O(n)\) is the list lookup and the notify loop; \(O(n^2)\) is the matching loop.
• \(n \log n\): \(\frac{2n \log(2n)}{n \log n} = 2\left(1 + \frac{1}{\log_2 n}\right)\), a bit more than 2× that gets closer to 2× as \(n\) grows.

📈 Pick the curves, zoom \(n\), flip to log-log

viewof classes = Inputs.checkbox(complexity_classes, {value: complexity_classes, label: "show"})

viewof n_top = Inputs.range([5, 40], {step: 1, value: 20, label: "n up to"})

viewof loglog = Inputs.toggle({label: "log-log axes", value: false})

{
  const order = complexity_classes;
  const palette = ["#2a78d6", "#eb6834", "#1baf7a", "#eda100", "#e87ba4", "#008300", "#4a3aa7"];
  // steps were computed in Python; keep the ticked classes up to the chosen n
  const rows = complexity_curves.filter(d => classes.includes(d.c) && d.n <= n_top);
  const data = loglog ? rows.filter(d => d.steps > 0) : rows;   // log axis can't show log2(1) = 0
  // line labels: every line on log-log, only the tallest one on linear axes (the rest overlap)
  const ends = order.map(c => data.filter(d => d.c === c).at(-1)).filter(Boolean);
  const top = ends.length ? ends.reduce((a, b) => (b.steps > a.steps ? b : a)) : null;
  const last = loglog ? ends : (top ? [top] : []);
  return Plot.plot({
    width: 860, height: 340, marginRight: 90, marginLeft: 80, marginTop: 30,
    marginBottom: 48, style: {fontSize: "16px", background: "transparent"},
    x: {label: "n", labelAnchor: "center", type: loglog ? "log" : "linear", grid: true},
    y: {label: "↑ number of steps", type: loglog ? "log" : "linear", grid: true,
        tickFormat: d => d3.format("~s")(d).replace("G", "B")},   // 1k, 1M, 1B, 1T
    color: {domain: order, range: palette, legend: true, swatchSize: 16},
    marks: [
      Plot.line(data, {x: "n", y: "steps", stroke: "c", strokeWidth: 2}),
      Plot.text(last, {x: "n", y: "steps", text: "c", dx: 8, textAnchor: "start", fontWeight: "bold"}),
      Plot.tip(data, Plot.pointer({x: "n", y: "steps", title: d => `${d.c}\nn = ${d.n}\n${d3.format(",.2~f")(d.steps)} steps`}))
    ]
  });
}

• Linear axes first: \(2^n\) swallows everything. Untick it to see the rest.
• Then flip to log-log: every polynomial becomes a straight line, and the slope is the exponent (\(n^2\) is twice as steep as \(n\)). \(2^n\) still curves upward, even on log-log.
• why log-log? [1] turn polynomial to straight line [2] often times n increases by many orders of magnitudes, so we want to see the rate of change
• Drag \(n\) up to 40: \(2^{40}\) is about a trillion steps.

📈 Big O is asymptotic, keeps only the fastest-growing term

Imagine we have an algorithm that does these three things: [1] find the rider’s account by binary search in a sorted list (\(\log n\)), [2] notify \(n\) drivers(\(n\)), each notification takes 2 seconds and [3] the algorithm waits for 5 seconds before matching drivers with riders (\(5\)). The algorithm’s runtime is:

\[f(n) = \log n + 2n + 5 \quad\Longrightarrow\quad O(n)\]

• We drop multiplicative constants: \(2n\) steps (notify every driver twice) is still \(O(n)\).
• We drop lower-order terms and additive constants: \(\log n\) would be dropped because \(\log n\) grows slower than \(n\). \(5\) would be dropped because it is a constant.
• ⚠️ Additive vs. multiplicative: \(n + \log n\)’s Big O notation is \(O(n)\), but \(n \cdot \log n\)’s Big O notation is \(O(n \log n)\).

📈 Visualization: \(n + \log n + 5\) is “just” \(O(n)\)

viewof n_zoom = Inputs.range([10, 5000], {step: 10, value: 10, label: "n up to"})

{
  const {extra, pct} = lower_order_extra[n_zoom];   // computed in Python
  return html`<div class="ojs-readout">At n = <b>${n_zoom}</b>: the extra log n + 5 is
    <b>${extra.toFixed(1)}</b> steps, which is <b>${pct.toFixed(1)}%</b> on top of n.</div>`;
}

{
  const rows = lower_order_curves.filter(d => d.n <= n_zoom);
  const last = ["n", "n + log n + 5"].map(c => rows.filter(d => d.c === c).at(-1));   // where to put the line labels
  return Plot.plot({
    width: 860, height: 360, marginRight: 150, marginLeft: 80,
    marginBottom: 48, style: {fontSize: "16px", background: "transparent"},
    x: {label: "n", labelAnchor: "center", grid: true},
    y: {label: "↑ number of steps", grid: true},
    color: {domain: ["n", "n + log n + 5"], range: ["#2a78d6", "#eb6834"], legend: true, swatchSize: 16},
    marks: [
      Plot.line(rows, {x: "n", y: "steps", stroke: "c", strokeWidth: 2}),
      Plot.text(last, {x: "n", y: "steps", text: "c", dx: 8, textAnchor: "start", fontWeight: "bold"}),
      Plot.tip(rows, Plot.pointer({x: "n", y: "steps", title: d => `${d.c}\nn = ${d.n}\n${d.steps.toFixed(1)} steps`}))
    ]
  });
}

• when n is small, there is a big gap between the 2 lines, but both grow linearly-ish
• as n grows, the gap becomes smaller and 2 lines are overlapping.

⚠️ When \(n\) is small, big O can mislead

You are given 2 algorithms by your colleague at Uber, algorithm A takes \(100\sqrt{n}\) steps, \(O(\sqrt{n})\), and algorithm B takes \(n\) steps, \(O(n)\). So we should always pick algorithm A, right?

viewof n_small = Inputs.range([20, 40000], {step: 20, value: 20, label: "zoom: n up to"})

{
  const rows = sqrt_curves.filter(d => d.n <= n_small);   // computed in Python
  const cs = sqrt_labels;
  const x0 = sqrt_crossover;
  const last = cs.map(c => rows.filter(d => d.c === c).at(-1));   // where to put the line labels
  return Plot.plot({
    width: 860, height: 340, marginRight: 190, marginLeft: 80,
    marginBottom: 48, style: {fontSize: "16px", background: "transparent"},
    x: {label: "n (drivers)", labelAnchor: "center", grid: true},
    y: {label: "↑ number of steps", grid: true},
    color: {domain: cs, range: ["#eb6834", "#2a78d6"], legend: true, swatchSize: 16},
    marks: [
      Plot.line(rows, {x: "n", y: "steps", stroke: "c", strokeWidth: 2}),
      Plot.text(last, {x: "n", y: "steps", text: "c", dx: 8, textAnchor: "start", fontWeight: "bold"}),
      n_small >= x0 ? Plot.ruleX([x0], {stroke: "#52514e", strokeDasharray: "4 4"}) : null,
      n_small >= x0 ? Plot.text([{n: x0}], {x: "n", y: () => 0, text: d => `crossover: n = ${d3.format(",")(d.n)}`,
                                            dy: -8, dx: 6, textAnchor: "start", fill: "#52514e"}) : null,
      Plot.tip(rows, Plot.pointer({x: "n", y: "steps", title: d => `${d.c}\nn = ${d.n}\n${d3.format(",.0f")(d.steps)} steps`}))
    ]
  });
}

• Vancouver 2010, 20 drivers: B (the “worse” \(O(n)\) algorithm) is far faster: 20 steps vs. about 450.
• Drag out to 40,000 drivers: A crosses below B at \(n = 10{,}000\) and wins from there on.
• Big O is about large \(n\). For small \(n\) the constants and lower-order terms we threw away actually matters
• Big O has limitations, don’t just always trust big O notation as the algorithm’s actual runtime!

🧮 Finding the complexity: count the loops

One ride batch = Scenario 3 (match) followed by Scenario 2 (notify):

Step 1: count the steps. Nested loop: \(n \times n \times k\). Second loop: \(n \times k\). So \(f(n) = k n^2 + k n\).

Step 2: drop constant factors and lower-order terms. \(k\) is a constant, \(n\) is lower order than \(n^2\), so \(f(n) = O(n^2)\).

• dispatch is the two Uber scenarios glued together: match every rider with every driver, then tell every driver the result.
• Run it live: \(n = 10\) gives 110 steps (\(100 + 10\)), \(n = 20\) gives 420 (\(400 + 20\)). Doubling \(n\) gave roughly 4×: the \(n^2\) part is in charge.
• The step counter is a hidden cell on this slide: every constant-time helper just adds 1 to steps.

See the steps: every dot is one step

viewof n_grid = Inputs.range([1, 12], {step: 1, value: 3, label: "n (riders = drivers)"})

{
  const kinds = dispatch_kinds;
  // steps recorded in Python; notify steps (rider = null) go in their own row, one empty row below the grid
  const dots = dispatch_steps[n_grid].map(d => ({...d, row: d.rider ?? n_grid + 2}));
  return Plot.plot({
    width: 620, height: 340, marginLeft: 70, marginBottom: 40,
    style: {fontSize: "16px", background: "transparent"},
    x: {label: "driver →", domain: [0.5, 12.5], ticks: 12},
    y: {domain: [14.7, 0.3], axis: null},           // reversed so rider 1 is at the top
    color: {domain: kinds, range: ["#eb6834", "#2a78d6"], legend: true, swatchSize: 16},
    marks: [
      Plot.dot(dots, {x: "driver", y: "row", fill: "kind", r: 9, stroke: "white", strokeWidth: 2}),
      Plot.text([{row: (n_grid + 1) / 2, t: "riders ↓"}, {row: n_grid + 2, t: "notify"}],
                {x: 0.5, y: "row", text: "t", textAnchor: "end", dx: -8, fill: "#52514e"}),
      Plot.tip(dots, Plot.pointer({x: "driver", y: "row",
        title: d => d.kind === kinds[1] ? `notify driver ${d.driver}` : `rider ${d.row} × driver ${d.driver}`}))
    ]
  });
}

{
  const {estimates, notifications, total, pct_n2} = dispatch_counts[n_grid];   // counted in Python
  return html`<div class="ojs-readout">n = <b>${n_grid}</b>:
    <span class="match">${estimates}</span> estimates + <span class="notify">${notifications}</span> notifications
    = <b>${total}</b> steps. The n² part is <b>${pct_n2.toFixed(0)}%</b> of the work.</div>`;
}

• Each orange dot is one estimate_pickup_time, each blue dot one notify_driver.
• Drag \(n\) from 1 to 12: the orange square grows in two directions, the blue row grows in one. At \(n = 12\) the square is 92% of the work, and the share keeps growing with \(n\). That is why we keep \(n^2\) and drop \(n\).

🧮 Two variables: \(n\) riders and \(m\) drivers

At rush hour there are more riders than drivers; at 3 am, the reverse. Now the two counts differ:

The time complexity is \(O(nm + m) = O(nm)\).

• \(nm + m = (n+1)m\), and we don’t distinguish \(n\) from \(n+1\).
• If \(m = n\) (as many drivers as riders) it becomes \(O(n^2)\).
• \(O(n^2 + n + m)\) is just \(O(n^2 + m)\): we can drop \(n\) (dominated by \(n^2\)) but not \(m\).
• \(O(n^2 + nm + m)\) is \(O(n^2 + nm)\): we can’t drop either term, because we don’t know whether riders or drivers will dominate.

• When two inputs can grow independently, keep both.

🚗 Today’s takeaways

• 🔧 What affects runtime?
  • Data structures — e.g., set is faster to search than list.
  • Algorithms — does it take \(n\) steps, or \(2n\) or \(100000n\) steps? How complicated is each step?
  • Implementation — language (Python vs. C), libraries (NumPy), hardware, caching/parallelism.
• ⏱️ Profiling measures where time goes (don’t guess, measure!)
  • timeit: time one line of expression.
  • cProfile: how much time in each function.
  • LineProfiler: how much time on each line.
• 📈 Big O predicts how runtime grows as \(n\) increases
  • Count the loops, keep the fastest-growing term, ignore constant factors and lower-order terms.
  • Uber: one loop over \(n\) drivers → double \(n\) gives 2× the time (\(O(n)\)).
  • Uber: nested loop over \(n\) riders × \(n\) drivers → double \(n\) gives 4× the time (\(O(n^2)\)).
• ⚠️ Constants matter when \(n\) is small → big O only tells you which algorithm wins eventually.

• Next lecture: why the set was so fast (hashing), and what all of this costs in memory (space complexity).

❓ Questions?

🎯 (Bonus Slide) Best, worst and average case

Back to Scenario 1: rider_id in rider_accounts when rider_accounts is a list. Python checks the IDs one by one, from the left.

viewof login_pos = Inputs.range([1, scan_ids.length + 1], {step: 1, value: 1,
  label: `who logs in? (position in list, ${scan_ids.length + 1} = new rider)`})

{
  const ids = scan_ids;
  const {target, found, checks} = scan_results[login_pos];   // searched in Python
  const boxes = ids.map((id, i) => {
    const cls = found && i + 1 === checks ? "found" : i < checks ? "checked" : "";
    return html`<div class="scan-box ${cls}">${id}</div>`;
  });
  const who = found ? `rider ${target}` : "a new rider (no account)";
  const verdict = found ? html`<b>True</b>: welcome back` : html`<b>False</b>: show the sign-up page`;
  return html`<div class="scan-row">${boxes}</div>
    <div class="ojs-readout">Looking for ${who}: <b>${checks}</b> of ${ids.length} comparisons,
    then ${verdict}.</div>`;
}

• Best case: the rider is first in the list: 1 comparison.
• Worst case: the rider is last, or has no account yet (our new_rider): \(n\) comparisons.
• Average case: somewhere in the middle: about \(n/2\) comparisons, still \(O(n)\).
• In this course we generally mean the worst case, which for large \(n\) often has the same complexity as the average case anyway.

• Drag from 1 to 12: the number of comparisons equals the position. 13 is a rider with no account: every box gets checked and the answer is False.
• Uber can’t plan around the best case: every new rider who signs up is a worst case.
• With a set, all of these take about the same (tiny) time, whatever the position. Why: next lecture.

(Bonus Slide) iClicker: what is the time complexity of surge_pricing(n)?

• (A) \(O(n)\)
• (B) \(O(n^2)\)
• (C) \(O(n^2 + n)\)
• (D) \(O(n^3)\)

• Answer: B. \(f(n) = kn + kn^2\); drop the constant \(k\) and the lower-order \(n\).
• C is not wrong, it’s just not simplified: \(O(n^2 + n)\) and \(O(n^2)\) are the same thing, and we always write the simplest form.
• After the vote you can check it live: add steps = 0; surge_pricing(10); print(steps) → 110.

(Bonus Slide) 🔧 What else affects the runtime?

• The implementation decides the constants and lower-order terms (0.1 s vs. 0.2 s per step):
  • how fast your language is (Python vs. C),
  • how fast your libraries are (NumPy loops in C),
  • whether you can cache results or compute in parallel.

• Note: there are also \(o\), \(\omega\), \(\Omega\), \(\theta\), \(\Theta\), and more. We only use big O in this course.

• A faster computer or a faster language is a constant factor: it makes the 10 s into 5 s. A better algorithm turns \(n^2\) into \(n\): at \(n = 10{,}000\) that’s the difference between 4 months and 17 minutes (0.1 s per step).

(Bonus Slide) 📈 Where the doubling rule comes from

Compare the runtime at \(2n\) with the runtime at \(n\): \(\dfrac{g(2n)}{g(n)}\).

• \(O(1)\), constant: \(\dfrac{g(2n)}{g(n)} = \dfrac{c}{c} = 1\) → same runtime; \(n\) never enters the formula.
• \(O(n)\), linear: \(\dfrac{g(2n)}{g(n)} = \dfrac{2n}{n} = 2\) → 2× (the notify loop: twice the drivers, twice the work).
• \(O(n^2)\), quadratic: \(\dfrac{g(2n)}{g(n)} = \dfrac{(2n)^2}{n^2} = \dfrac{4n^2}{n^2} = 4\) → 4× (the matching loop).
• \(O(n^3)\), cubic: \(\dfrac{g(2n)}{g(n)} = \dfrac{(2n)^3}{n^3} = \dfrac{8n^3}{n^3} = 8\) → 8×.
• \(O(n^k)\), polynomial: \(\dfrac{g(2n)}{g(n)} = \dfrac{(2n)^k}{n^k} = \dfrac{2^k n^k}{n^k} = 2^k\) → \(2^k\)×.

(Bonus Slide) 📈 The logs and the exponential

• \(O(\log n)\), logarithmic: here the difference is the interesting part, not the ratio. \[g(2n) - g(n) = \log_2(2n) - \log_2 n = \log_2\frac{2n}{n} = \log_2 2 = 1\] → + a constant: doubling \(n\) adds one more step, not one more of everything.
• \(O(n \log n)\), linearithmic: \[\frac{g(2n)}{g(n)} = \frac{2n \log_2 (2n)}{n \log_2 n} = \frac{2n(\log_2 n + 1)}{n \log_2 n} = 2\left(1 + \frac{1}{\log_2 n}\right)\] → a bit more than 2×, and the extra part shrinks as \(n\) grows.
• \(O(2^n)\), exponential: \[g(2n) = 2^{2n} = (2^n)^2 = \big(g(n)\big)^2\] → the runtime is squared, not multiplied by a constant.