Answer: Discrete and Nominal.

Remember that a column’s feature type (what the values mean) is not the same as its data type (how pandas stores it).

• Discrete: "bikers", "t-shirts", and "snacks" are all counts of people or items. They’re numeric — it makes sense to add them and average them — but they can only take on whole-number values, so they’re discrete rather than continuous.
• Continuous: none. A continuous feature is one that could take on any value in a range, like a height, a weight, or a duration. Nothing in bike is measured on that kind of scale.
• Ordinal: none. An ordinal feature is categorical with a meaningful order, like "small", "medium", "large". None of the categorical columns in bike have an inherent ranking.
• Nominal: "location", "neighborhood", and "site captain" are all unordered categories. So is "zip"! Zip codes are stored as ints, but arithmetic on them is meaningless — you’d never average two zip codes — which makes them nominal, just like phone numbers or Social Security Numbers.

Difficulty: ⭐️

The average score on this problem was 93%.

Answer: Options 2 and 4.

(bike.dropna()["t-shirts"] <= bike.dropna()["bikers"]).sum() == bike.dropna().shape[0]
bike["location"].str[0:2].apply(lambda s: s not in ["NE", "NW", "SE", "SW"]).sum() == 0

Recall the four pillars of data quality checks from Lecture 5 — scope, measurements and values, relationships, and analysis. A reasonable check has to be an assertion that is guaranteed by the context, not merely something we’d expect to be true. If a plausible dataset can make the expression False without anything being wrong, the check fails the second condition.

Option 1 ❌ — bike["site captain"].value_counts().iloc[0] == 1. Since value_counts() sorts in descending order, .iloc[0] is the number of times the most frequent site captain appears, so this asserts that no site captain name shows up twice. Nothing in the setup requires that: one enthusiastic volunteer could run two pit stops, and two different volunteers could easily share a last name and first initial (there is more than one “Smith, J” in San Diego). Not a valid check.

Option 2 ✅ — (bike.dropna()["t-shirts"] <= bike.dropna()["bikers"]).sum() == bike.dropna().shape[0]. This is a relationships check: are related features in agreement? Bikers may or may not take a shirt, but nobody can take more than one, so the number of t-shirts handed out at a pit stop can never exceed the number of bikers who stopped there. Summing a boolean Series counts the Trues, so this asserts that the inequality holds in every row. Any row where it fails must be an error. (The dropna() matters — the comparison is only meaningful on rows where both values were actually recorded, and both sides use the same subset, so the indexes line up.)

Option 3 ❌ — bike["snacks"].sum() >= bike["bikers"].sum(). Bikers can take as many snacks as they’d like, which includes zero. If most people grabbed a shirt and skipped the snacks, total snacks would be legitimately below total bikers. The expression evaluating to False tells us nothing is necessarily wrong, so it’s not a valid check.

Option 4 ✅ — bike["location"].str[0:2].apply(lambda s: s not in ["NE", "NW", "SE", "SW"]).sum() == 0. This is a measurements and values check. Every "location" is formatted like "NE corner of Regents Road and Nobel Drive", so the first two characters must be one of the four corner abbreviations. The lambda returns True when a prefix is invalid, so the sum counts invalid rows, and == 0 asserts there are none. A False here means some location wasn’t recorded in the required format.

Option 5 ❌ — bike["location"].str.count("and").nunique() == 1. It’s tempting to think each location contains exactly one "and" — the delimiter between the two street names — but .str.count counts substrings, not words. A location like "SE corner of Highland Avenue and Euclid Avenue" contains "and" twice, once inside "Highland". The number of matches can legitimately differ from row to row, so False doesn’t imply an error.

Difficulty: ⭐️⭐️⭐️

The average score on this problem was 67%.

Answer:

1. missing completely at random (MCAR)
2. an unbiased estimate

Walk down the flowchart from Lecture 7. It’s not MD — we can’t recover the number of bikers from the other columns. It’s not MNAR — a device breaking has nothing to do with how many bikers happened to show up. And it’s not MAR — nothing in bike ("location", "zip", "neighborhood", "site captain", …) tells us anything about whether a captain’s device was defective. Which device you got handed is essentially a coin flip, so the chance a value is missing is independent of both the other columns and the missing value itself: MCAR.

Because MCAR data is a random subset of all the data, the observed "bikers" values are representative of all the "bikers" values. Filling in the missing entries with the mean of the observed ones therefore gives an unbiased estimate of the true mean.

Difficulty: ⭐️⭐️⭐️

The average score on this problem was 67%.

Answer:

1. missing at random (MAR)
2. This part was not graded — see below.

The chance that "bikers" is missing depends on the "neighborhood" column: pit stops in Mira Mesa are much more likely to be missing attendance than pit stops anywhere else. Since "neighborhood" is a column we actually have, that’s the definition of MAR — the missingness depends on other columns, but not on the missing value itself. Notice it isn’t MD, since we can’t determine the number of bikers from "neighborhood"; some Mira Mesa pit stops recorded attendance and some didn’t.

Part 2 was thrown out because the answer isn’t determined by the information given. (You can see this in the scoring: every other part of this problem split its 4 points evenly between the two questions, but here all 4 went to part 1.) Mean imputation on MAR data is biased if the group driving the missingness differs from the rest on the variable being imputed — but nothing here tells us whether Mira Mesa pit stops draw more, fewer, or about the same number of bikers as pit stops elsewhere in San Diego. If Mira Mesa is a typical neighborhood, the estimate happens to come out unbiased; if it’s busier or quieter than average, it doesn’t.

The fix, as in Lecture 8, would be to impute within groups — fill in each missing Mira Mesa value with the mean of the observed Mira Mesa values — which is unbiased for MAR data.

Difficulty: ⭐️⭐️⭐️

The average score on this problem was 66%.

Answer:

1. missing not at random (MNAR)
2. an underestimate

Here the chance that a value is missing depends on the value itself: the bigger the true number of bikers, the more likely the captain lost count. That’s MNAR (also called “non-ignorable” — the fact that a value is missing is itself informative).

Since it’s precisely the largest counts that go missing, the values we do observe are systematically too small. Filling the gaps with the mean of those observed values pulls the overall mean down, so mean imputation gives an underestimate of the true mean. This is the mirror image of the classic income-survey example from Lecture 7: when high earners decline to report, ignoring the missingness biases the mean salary low.

Difficulty: ⭐️⭐️⭐️

The average score on this problem was 69%.

Answer:

1. missing completely at random (MCAR)
2. an unbiased estimate

This one is worth reading carefully, because it looks like MAR at first glance. The missingness does depend on a variable — the site captain’s age — but that variable is not in bike. The "site captain" column only holds a last name and first initial, which tells us nothing about how old someone is.

Recall the definition: data is MAR if the chance of being missing depends on other columns, and MCAR if it’s independent of the other columns and of the missing value. Relative to the data we actually have, forgetting is unrelated to every column in bike and unrelated to the number of bikers itself, so the missingness is MCAR — and mean imputation gives an unbiased estimate.

The lesson is that missingness mechanisms are a property of the dataset in front of you, not of the world. If we went back and collected a "captain age" column, the very same missingness would be reclassified as MAR, and we could then impute within age groups.

Worth knowing: part 1 here was the hardest question on the entire exam, at 22% — most people saw “depends on age” and answered MAR without checking whether age was actually a column. Part 2 fared better at 46%. If you got this one wrong, you’re in good company, but it’s the single best part of this exam to go back and re-read.

Difficulty: ⭐️⭐️⭐️⭐️

The average score on this problem was 34%.

Answer:

1. "bike"
2. "day"
3. "work"
4. "bike"

The trap in this question is that puzzle’s row labels and column labels are the integers 1 and 0, in that order. So the label 1 and the position 1 refer to different things everywhere, and loc and iloc come apart.

1. puzzle.loc[1, 1] uses labels for both: the row labeled 1 (the top row) and the column labeled 1 (the left column), giving "bike".
2. puzzle.iloc[1, 1] uses positions for both: row position 1 is the second row (the one labeled 0), and column position 1 is the second column (the one labeled 0), giving "day".
3. puzzle[1] uses [] on a DataFrame, which selects a column by label — the column labeled 1, which is the Series ["bike", "work"] with index [1, 0]. Then .iloc[1] takes the element in position 1 of that Series, which is "work".
4. puzzle.loc[1] selects the row labeled 1 as a Series, {1: "bike", 0: "to"}, whose index is the column labels. Then .loc[1] grabs the entry labeled 1, which is "bike".

Note the contrast between 3 and 4: puzzle[1] gives a column while puzzle.loc[1] gives a row, even though both are indexed with 1.

(And if you read the four answers in the order the DataFrame displays them — "bike", "to", "work", "day" — you get the old name of the event.)

Scores fell steadily across the four, from 81% on the first to 60% on the last, which is about what you’d expect: the plain loc/iloc lookups are the warm-up, and the chained ones are where confusing a label with a position actually costs you.

Difficulty: ⭐️⭐️⭐️

The average score on this problem was 70%.

Answer:

1. DataFrame with 2 rows and 1 column.

2. DataFrame with 2 rows and 2 columns.

3. Passing a list of column labels to [] always returns a DataFrame, even when the list has just one element. puzzle[[1]] keeps only the column labeled 1, so we get a DataFrame with both rows and one column. Compare this to puzzle[1] from the previous part, which passes a single label and returns a Series.

4. puzzle.index is [1, 0], so puzzle.index <= 1 is the boolean array [True, True] — both row labels are less than or equal to 1. Passing that mask to .loc keeps every row and every column, so the result is the entire DataFrame: 2 rows and 2 columns. It’s easy to see the <= 1 and assume it filters something out, but the index here isn’t [0, 1, 2, ...].

Difficulty: ⭐️⭐️⭐️

The average score on this problem was 64%.

Answer:

def add_join_key(df):
    df = df.copy()

    def streets(s):
        return str(sorted(s[13:].split(" and ")))

    df["join key"] = df["location"].apply(streets)
    return df

Two locations are equivalent when they name the same two streets, so the join key has to throw away everything that doesn’t matter and put what’s left in a canonical form. There are exactly two things to get rid of:

• The corner. Every location starts with the same 13-character prefix pattern — "NE corner of ", "SW corner of ", and so on — so s[13:] slices it off and leaves just "Regents Road and Nobel Drive".
• The order of the streets. Splitting on " and " gives a list of the two street names, and sorted puts them into alphabetical order, so "Regents Road and Nobel Drive" and "Nobel Drive and Regents Road" both become ["Nobel Drive", "Regents Road"].

Finally, the question asks for string values, so we wrap the sorted list in str. Any canonical string works — the point is that equivalent locations must produce identical strings. A .str-based one-liner does the same job:

df["join key"] = df["location"].str[13:].str.split(" and ").apply(lambda pair: " & ".join(sorted(pair)))

Don’t forget df = df.copy() at the top (it’s already given here) — without it, the function would modify the caller’s DataFrame in place.

Difficulty: ⭐️⭐️⭐️

The average score on this problem was 51%.

Answer: "['Nobel Drive', 'Regents Road']"

df.pipe(f) is just another way of writing f(df), so this adds the join key column to bike and grabs its first entry. Row 0 of bike has location "NE corner of Regents Road and Nobel Drive", so we trace through streets:

• s[13:] → "Regents Road and Nobel Drive"
• .split(" and ") → ["Regents Road", "Nobel Drive"]
• sorted(...) → ["Nobel Drive", "Regents Road"] (alphabetically, "N" comes before "R")
• str(...) → "['Nobel Drive', 'Regents Road']"

The answer is a string that happens to look like a list — quotes, brackets, and all. That’s the whole point of the str call: merge needs to compare hashable values, and a list isn’t one.

Difficulty: ⭐️⭐️⭐️⭐️

The average score on this problem was 45%.

Answer:

• (a): ["join key", "prev"]
• (b): "right"

(a) last has all seven of the same columns as bike. If we merged the whole thing, every shared column name would show up twice in the result with _x and _y suffixes — a mess, and not “one additional column.” So before merging we cut last down to only what we need: the column we’re joining on, "join key", and the column we’re after, "prev". Note the double brackets — passing a list of labels to [] keeps a DataFrame.

(b) The left DataFrame is last and the right is bike, and we want to keep every row of bike, including this year’s brand-new pit stops that have no match in last. That’s a right join. The other options all fail:

• "inner" would silently drop this year’s new pit stops.
• "left" would keep last year’s pit stops, including ones that were removed this year.
• "outer" keeps everything, so it would add rows for removed pit stops that aren’t in bike at all.

Rows of bike with no match in last get NaN in "prev" — which is exactly the signal the next part uses to tell new pit stops apart from old ones.

Difficulty: ⭐️⭐️⭐️

The average score on this problem was 54%.

Answer:

growth = (merged["bikers"] / merged["prev"]).median()
merged["bikers"] = merged["bikers"].fillna(merged["prev"] * growth)
merged["bikers"] = merged["bikers"].fillna(merged["bikers"].mean())
merged["bikers"] = merged["bikers"].astype(int)

Step 1. Dividing two Series lines them up row by row, and any arithmetic involving NaN produces NaN — so the ratio is automatically null exactly where either year’s count is missing, just as the question describes. .median() then skips those nulls by default, so no dropna() is needed. The median is used rather than the mean because a single pit stop that went from 2 bikers to 100 would blow up the average growth ratio.

Step 2. fillna accepts a Series, and it aligns on the index: each missing "bikers" entry is replaced by the value in the corresponding row of merged["prev"] * growth. Rows where "prev" is itself NaN (the new pit stops) stay missing, which is what step 3 is for.

Step 3. Plain mean imputation, which is what’s left for pit stops that are new this year and so have nothing to scale from. Note this uses the updated "bikers" column, so the mean already includes the values filled in during step 2.

Step 4. Steps 2 and 3 introduced floats. astype(int) truncates toward zero, which is exactly what the question asks for. Be careful with alternatives: .round() rounds to the nearest integer rather than truncating, and np.floor leaves the column as floats.

Difficulty: ⭐️⭐️⭐️

The average score on this problem was 55%.

Answer: Options 1, 2, and 4 — everything except “0s in the first and second rows.”

First, get oriented. piv has one row per value of "new" and one column per neighborhood, and False sorts before True, so the first row is old pit stops and the second row is new pit stops. Each cell is the total number of bikers at pit stops of that kind in that neighborhood.

A 0 can only appear because of fill_value=0: that combination of neighborhood and "new" had no rows in bike at all. (It can’t come from adding up actual counts, since every "bikers" value is a positive integer.) So each option is really asking about which combinations of pit stops a neighborhood can have.

1. ✅ A 0 in the first row means the neighborhood has no old pit stops — every pit stop there is new this year. Perfectly plausible for a neighborhood that just joined the event.
2. ✅ A 0 in the second row means the neighborhood got no new pit stops this year — all of its pit stops carried over from last year.
3. ❌ Impossible. A neighborhood only gets a column in piv if it appears somewhere in bike, and every pit stop in bike has a positive number of bikers. So at least one of the two cells in the column must be nonzero.
4. ✅ The most ordinary case of all: the neighborhood has both old and new pit stops.

Difficulty: ⭐️⭐️⭐️

The average score on this problem was 70%.

Answer:

piv.loc[True, "Hillcrest"] / piv["Hillcrest"].sum()

This is a conditional probability, so it’s a cell of the table divided by the total of the group we’re conditioning on:

P(\text{new} \mid \text{Hillcrest}) = \frac{\text{bikers at new Hillcrest pit stops}}{\text{bikers at all Hillcrest pit stops}}

Because each biker stops at exactly one pit stop, adding up bikers is the same as counting people, so these totals really do behave like counts of outcomes. The numerator is the cell in the True row of the "Hillcrest" column, and the denominator is the sum of that whole column.

Conditioning on Hillcrest means we only ever look at the "Hillcrest" column — this is the same “divide by the column sum to get a conditional distribution” move from Lecture 4. Note that piv.loc[True, "Hillcrest"] uses the actual boolean True as a label, not the string "True".

Difficulty: ⭐️⭐️⭐️

The average score on this problem was 51%.

Answer:

piv.max(axis=1)

We want one number per row of piv — the biggest entry in the old row, and the biggest entry in the new row — so we collapse across the columns. In pandas, axis=1 means the operation runs along each row, one row at a time, leaving the row index intact. That’s exactly the requirement that the result have the same index as piv.

The common mistake here is piv.max(axis=0) (or just piv.max(), since axis=0 is the default), which gives the largest value in each column — one number per neighborhood, indexed by neighborhood. A good sanity check when you’re unsure which axis to use: ask what the index of the result should be, and pick the axis that preserves it.

Difficulty: ⭐️⭐️⭐️⭐️

The average score on this problem was 31%.

Answer:

• (a): ["neighborhood", "new"]
• (b): sum
• (c): "new"
• (d): max

The strategy is to rebuild piv and then take the row maximums, in two passes.

(a) and (b): grouping on both columns and summing "bikers" gives the total number of bikers for every (neighborhood, new) combination — the same numbers that fill piv, just stacked into a Series with a MultiIndex instead of spread across a grid. Either order works, ["new", "neighborhood"] is equally fine, because the next step flattens the index anyway.

.reset_index() then turns that Series into a DataFrame with three ordinary columns: "neighborhood", "new", and "bikers". This is the key step — it promotes the MultiIndex levels back into columns so we can group by one of them again.

(c) and (d): now group those per-neighborhood totals by "new" alone and take the max of "bikers". That’s the largest single-neighborhood total among old pit stops and among new pit stops, indexed by "new" — matching piv.max(axis=1) exactly.

The empty parentheses after (b) and (d) are a hint: the blanks must be built-in aggregation methods like sum and max that take no arguments, not something like .agg("sum") or a lambda.

Watch out for the tempting shortcut of grouping only by "new" and taking the max in one pass — that would give the largest number of bikers at any single pit stop, not the largest neighborhood total.

Difficulty: ⭐️⭐️⭐️

The average score on this problem was 56%.

Answer: No.

The citywide totals are nothing more than the sums of the neighborhood totals. If \text{old}_i > \text{new}_i in every neighborhood i, then adding those inequalities up gives

\sum_i \text{old}_i > \sum_i \text{new}_i

so old beats new citywide too. There’s no way around it.

The reason this isn’t Simpson’s paradox is that we’re comparing sums, not averages or rates. Simpson’s paradox happens because a group average is a weighted average of subgroup averages, and lopsided group sizes can flip the direction of the comparison — that’s what makes the Lecture 4 examples (batting averages, admission rates, the dog-weight tables on past exams) work. Sums have no weights to distort, so aggregation can’t reverse the inequality.

If the question had asked about the mean number of bikers per pit stop instead of the total, the answer would have been yes.

Difficulty: ⭐️⭐️⭐️⭐️⭐️

The average score on this problem was 22%.

Answer: A permutation test.

The rule of thumb from Lecture 6 is to ask what you’re comparing.

• In a standard hypothesis test, you have one sample and a fully specified model of how the data was generated under the null, so you can simulate directly from that model — like flipping a fair coin 100 times, or drawing from a known population distribution.
• In a permutation test, you have two samples and no information about any population, and you’re asking whether they look like they came from the same underlying distribution.

Here we have two groups of numbers pulled from the same dataset — the "bikers" values at new pit stops and at old pit stops — and nothing that tells us what “the” distribution of bikers per pit stop should be. Under the null, the "new" label carries no information about "bikers", so we can simulate by shuffling one column relative to the other and recomputing the statistic each time.

Difficulty: ⭐️⭐️⭐️

The average score on this problem was 59%.

Answer: The distribution of the number of bikers at new pit stops looks like a shifted version of the distribution of the number of bikers at old pit stops.

A difference in means only summarizes a difference between two distributions faithfully when the distributions have roughly the same shape and differ by a horizontal shift. That’s what makes “on average, one group is lower than the other” a fair description of what’s going on.

If the two distributions had genuinely different shapes, the difference in means would be a poor choice: as Lecture 8 shows, two very different distributions can have identical means, so a difference in means near zero would fail to detect a real difference. That’s precisely the situation where you’d reach for the Kolmogorov-Smirnov statistic instead.

The other options don’t work:

• If the data showed no difference at all, there’d be no point running the test.
• A difference in spread with the same center is exactly what a difference in means can’t see.
• A noticeable difference in shapes is an argument against using the difference in means.

Difficulty: ⭐️⭐️⭐️

The average score on this problem was 66%.

Answer: None of the above.

The alternative hypothesis is directional — it doesn’t say new pit stops are different, it says they get fewer bikers. A valid test statistic for a one-sided alternative has to be one where large values point toward that specific direction. All three candidates throw the direction away:

• Absolute difference in mean bikers. Taking the absolute value collapses “new got far fewer” and “new got far more” into the same large value, so a big statistic no longer means what the alternative claims. It’s the right statistic for the two-sided alternative (“the numbers are different”), not this one.
• Total variation distance. The TVD compares two categorical distributions — it’s a sum of absolute differences in proportions across categories. "bikers" is a numerical column, and TVD is both non-directional and inapplicable here.
• Kolmogorov-Smirnov statistic. The K-S statistic is the largest vertical gap between two CDFs. It works on numerical data, but like the TVD it’s a distance: it detects any difference in distribution and is never negative, so it can’t distinguish “fewer” from “more.”

Difficulty: ⭐️⭐️⭐️

The average score on this problem was 61%.

Answer: -5

Start with which tail the p-value lives in. The statistic is the mean for new pit stops minus the mean for old pit stops, and the alternative says new pit stops get fewer bikers — so the alternative predicts a negative statistic, and “as or more extreme than the observed” means “less than or equal to the observed.” The p-value is therefore the area in the left tail:

(simulated_stats <= observed).mean()

So we need the value on the horizontal axis with about 2% of the histogram’s area to its left. The vertical axis is a probability density, so “area” means bar height times bin width, and the bars over the whole plot enclose a total area of 1.

The null distribution is centered near 0 with most of its area in the middle, so 2% puts us well out in the left tail. Sweeping in from the left edge and accumulating area as we go, the bars stay short until around -5, where the running total reaches roughly 2%; past that the bars grow quickly and the total climbs much faster. Reading off the axis and rounding to the nearest integer gives -5.

Two useful checks on your answer: it must be negative (a positive statistic would mean new pit stops did better, which could never give a small p-value here), and it must be out in the tail rather than near the bulk (a p-value of 0.02 is small, so the observation has to be rare under the null).

Since 0.02 < 0.05, we would reject the null hypothesis at the 0.05 significance level.

Difficulty: ⭐️⭐️⭐️⭐️

The average score on this problem was 48%.

Answer: Old pit stops generally get more bikers than new pit stops.

Since the p-value of 0.02 is below the 0.05 significance level, we reject the null in favor of the alternative: our data are not consistent with new and old pit stops drawing the same number of bikers, and the direction of the alternative is that new pit stops draw fewer. Saying old pit stops get more is just the other way of saying that.

Every other option fails, for one of two reasons.

They accept the null, or contradict the direction. “New and old generally get the same number” is the null hypothesis, and we can never accept the null — the most we could ever have said is that we failed to reject it, and here we rejected it outright. “New pit stops generally get more bikers” points the opposite way from our alternative.

They claim a cause. Both the advertising options assert why the difference exists. A hypothesis test compares an observation against what the null predicts; it cannot tell you the mechanism behind a difference it detects. Fewer people knowing about new pit stops is a perfectly reasonable conjecture, but nothing in this test provides evidence for it over any other explanation, and the last option additionally contradicts the direction we found.

Difficulty: ⭐️⭐️

The average score on this problem was 80%.