Exercises — Reading documentation and debugging

An argument is required when it has no =default after it, and optional when a default value is written.

• start, stop → no defaults → 2 required.
• num=50, endpoint=True, retstep=False → all have defaults → 3 optional.
• Default number of points = the default of num, which is 50.

So: 2 required, 3 optional, 50 points by default.

A traceback is read bottom-to-top. The very last line names the exception; the frame just above it points at the code that raised it.

• Exception type: ==KeyError== — a dictionary was asked for a key it does not contain.
• The failing key is 'price' (that is the error message).
• Where it was raised: the lowest code frame → File "utils.py", line 23, in normalize.
• The frame main.py line 45 only called the chain; it is not where the crash happened.

Answer: utils.py, line 23, KeyError.

linspace places num points evenly from start to stop, and because endpoint=True it includes stop. With num points there are num - 1 gaps, so $\Delta x=\frac{\text{stop}-\text{start}}{\text{num}-1}=\frac{10-0}{5-1}=\frac{10}{4}=2.5$ Starting at $0$ and stepping by $2.5$: $[0.0,2.5,5.0,7.5,10.0]$ Five values, last one is exactly stop = 10. Spacing $\Delta x=2.5$.

With endpoint=False, stop is excluded, so the num points fill only the half-open interval $[0,10)$. Now the divisor is num (not num - 1), because the point at $10$ that used to "cap" the sequence is gone: $\Delta x=\frac{10-0}{5}=2.0$ Points: $[0.0,2.0,4.0,6.0,8.0]$ — note $10$ never appears. Why the change? endpoint=True uses num-1 gaps (both ends pinned); endpoint=False uses num gaps (only the left end pinned). Same count of points, different spacing.

The docs say: "If capturing parentheses are used in the pattern, then the text of all groups is also returned." The (\d+) is a capturing group matching runs of digits, so the matched digits survive in the output list: $\text{[’a’, ’1’, ’b’, ’2’, ’c’]}$ Without the parentheses — re.split(r'\d+', 'a1b2c') — you would get ['a', 'b', 'c'] and lose the digits.

Symptom: with students = [{'name':'A','score':80},{'name':'B','score':90}] we expect $85.0$ but get one student's value or a wrong number. Binary-search the loop body. Print total after the loop: it equals only the last student's score, not the sum. That tells us accumulation is broken inside the loop. Root cause: total = 0 sits inside the for loop, so every iteration wipes the running sum before adding. Only the final iteration's score survives. Trace it: iteration 1 → total=0 then +80 → 80. Iteration 2 → total=0 (resets!) then +90 → 90. After loop total=90, average = 90/2 = 45.0. Fix: move the reset outside the loop:

total = 0
for student in students:
    total += student['score']

Now total = 170, average = 170/2 = 85.0. Correct answer: 85.0.

Each check halves the suspect region. The number of halvings needed to shrink $N$ candidates down to $1$ is $T(N)=\lceil {\log }_{2}N\rceil .$ For $N=128=2^7$: ${\log }_{2}128=7.$ Worst case: 7 checks. Compare to naive linear scanning, which averages $N/2=64$ checks — binary search is dramatically cheaper because the cost grows like ${\log }_{2}N$, not $N$. See the figure below.

groupby creates one output row per distinct group key present in the data. The knob dropna decides whether NaN counts as its own key.

• dropna=True (default): rows with NaN city are excluded entirely. Distinct real keys = {Delhi, Mumbai} → 2 rows. (The 3 NaN rows are dropped.)
• dropna=False: NaN becomes its own group. Distinct keys = {Delhi, Mumbai, NaN} → 3 rows.

Notice the total input rows (12) never changes the number of groups — only the number of distinct keys does. Grouping collapses many rows into one row per key.

Use df.groupby('city', dropna=False).size(). Each group's size is just how many input rows carried that key:

• Delhi → $5$
• Mumbai → $4$
• NaN → $3$

Sum: $5+4+3=12$. ✅ Because size() partitions every row into exactly one group when dropna=False, the counts must total the original row count. (With dropna=True they would sum to $12-3=9$.)

On day $10$ the log has $N=2^{10}=1024$ lines. $\text{checks}=\lceil {\log }_{2}1024\rceil =10.$ The doubling of lines adds only one extra check per day, because ${\log }_2(2^d)=d$. So while the data grows exponentially, the debugging cost grows only linearly in the day number — that is the whole point of a ${\log }_{2}N$ strategy: taming exponential growth into gentle linear effort.

(a) Binary search worst case: $\lceil {\log }_{2}10000\rceil =\lceil 13.28\dots \rceil =14\text{ checks}.$ (Because $2^{13}=8192<10000\le 16384=2^{14}$.) (b) Linear scan average = $N/2=10000/2=5000$ checks. (c) Ratio: $\frac{5000}{14}\approx 357.$ So systematic binary-search debugging is roughly 357× cheaper on average than random linear scanning for a file this size. The figure earlier makes this gap visible: the ${\log }_{2}N$ curve barely rises while the $N/2$ line rockets upward.

linspace(0,10,num=5) spacing? ::: $\Delta x=2.5$ linspace(0,10,num=5,endpoint=False) spacing? ::: $\Delta x=2.0$ re.split(r'(\d+)','a1b2c') output? ::: ['a','1','b','2','c'] Fixed calculate_average_score on [80, 90]? ::: 85.0 Binary-search checks for $N=128$? ::: $7$ Groups from 5 Delhi + 4 Mumbai + 3 NaN, dropna=False? ::: $3$ rows summing to $12$ Binary-search checks for $N=10000$? ::: $14$