Grade 8 AI & Computer Science Practice Questions — Set 7

ExplanationTrace it step by step. Insert 12: [12]. Insert 6: placed at index 1, parent is index 0 (12); since 6 < 12, swap -> [6,12]. Insert 20: placed at index 2, parent is index 0 (6); 20 > 6, no swap -> [6,12,20]. Insert 15: placed at index 3, parent is index 1 (12); 15 > 12, no swap -> [6,12,20,15]. Insert 3: placed at index 4, parent is index 1 (12); 3 < 12, swap -> [6,3,20,15,12]; now 3 sits at index 1, whose parent is index 0 (6); 3 < 6, swap again -> [3,6,20,15,12]. Insert 9: placed at index 5, parent is index 2 (20); 9 < 20, swap -> [3,6,9,15,12,20]; now 9 sits at index 2, whose parent is index 0 (3); 9 > 3, so sifting stops. Final heap array: [3,6,9,15,12,20]. Option [3,6,20,15,12,9] is the array just before the last sift-up swap — it correctly places 9 as a leaf but forgets to compare it against its parent 20 and swap. Option [3,6,9,12,15,20] happens to also satisfy the min-heap property, but it is not what this insertion sequence actually produces: 3's sift-up only ever touches indices 4, 1, and 0, so 15 and 12 (indices 3 and 4) never swap places. Option [6,3,9,15,12,20] comes from a common bug — stopping sift-up after only one comparison: when inserting 3, the algorithm correctly swaps it with parent 12 to get [6,3,20,15,12], but then must check again against the new parent 6 at the root; skipping that second check leaves 6 sitting above 3, violating the min-heap property that every parent must be less than or equal to its children.

Explanation@log square means square is now bound to wrapper, so calling square(4) actually calls wrapper(4). Trace it line by line: wrapper(4) first executes print("start"), so "start" appears first. Next it runs result = fn(4) — this calls the original (undecorated) square function, which executes print("squaring") — so "squaring" appears second — and then returns 4*4 = 16, which is stored in result. Control returns to wrapper, which executes print("end") — third — and then `return result`, sending 16 back out. Finally, the outer print(square(4)) receives that 16 and displays it last. So the full sequence is: start, squaring, end, 16. The claim that square(4) prints "squaring" before wrapper prints "start" gets it backwards — decoration replaces the name square with wrapper entirely, so wrapper's code is what executes first, not the original function. The claim that the return value gets lost and None is printed instead is also wrong — wrapper explicitly captures fn(x) in result and explicitly returns it, so 16 is preserved and passed along correctly. And the claim that wrapper finishes all its own code before ever calling fn(x) is wrong too, since result = fn(x) is the second line inside wrapper, so the original function runs in the middle of wrapper's execution, not after it.

Explanation__enter__() runs first, printing "open" and returning the Resource instance (bound to r). Inside the with block, print("using") runs, then raise ValueError("problem") raises an exception. Python's with statement guarantees that __exit__(exc_type, exc_val, tb) is called with the exception's details before that exception is allowed to propagate further — so __exit__ runs and prints "close". The critical rule of the context manager protocol: __exit__'s return value decides what happens to the exception. Here __exit__ returns True, a truthy value, which tells Python the exception has been "handled" — it is suppressed and discarded right there, never propagating past the with statement. Because the exception never leaves the with block, the surrounding except ValueError clause is never triggered, so "caught" is never printed. The program simply resumes after the with statement with nothing left to run. Final output, in order: open, using, close.

Explanationcombinations("WXYZ", 3) selects groups of 3 letters where order does NOT matter and no letter repeats within a group. The count is given by the combination formula C(n, r) = n! / (r!(n-r)!). Here n=4, r=3, so C(4,3) = 4!/(3!×1!) = 24/6 = 4. Tracing the actual call confirms exactly 4 tuples, produced in lexicographic order based on the input string: ('W','X','Y'), ('W','X','Z'), ('W','Y','Z'), ('X','Y','Z') — notice ('X','W','Y') never appears, because (W,X,Y) and (X,W,Y) are the SAME combination, just listed once. The answer claiming 24 tuples confuses combinations with permutations(): permutations() DOES care about order, so P(4,3) = 4!/1! = 24 counts (W,X,Y) and (X,W,Y) separately — that formula answers a different question. The answer claiming 12 tuples comes from a flawed shortcut (multiplying "choices" as 4×3 without accounting for how groups of 3 overlap and get overcounted); it doesn't correspond to any valid combination or permutation formula for this problem. The answer claiming 64 tuples describes sampling 3 letters WITH replacement and with order mattering (a Cartesian product WXYZ×WXYZ×WXYZ) — completely different from combinations(), which never repeats an element within a single tuple.

ExplanationThe nested list comprehension [x for row in matrix for x in row] flattens the 3x3 matrix. The outer for-clause iterates over each row of matrix, and for each row, the inner for-clause iterates over the elements x within that row, producing [1, 2, 3, 4, 5, 6, 7, 8, 9]. The sum of these nine elements is 1+2+3+4+5+6+7+8+9 = 45. This double-for ordering corresponds exactly to a nested loop written as "for row in matrix: for x in row: process(x)" — the comprehension's for-clauses are evaluated left to right in the same order the equivalent nested loops would execute, which is why the outer loop over rows must appear before the inner loop over elements in the comprehension syntax.

ExplanationThe generator expression (x**4 for x in range(1,7) if x%2==0) creates an iterator. Filtering x%2==0 selects 3 values: x=2, x=4, x=6. Computing x**4 for each: 2**4=16, 4**4=256, 6**4=1296. Sum: 16+256+1296 = 1568. List comprehensions allocate memory for all 3 values upfront, using O(n) space. Generators compute one value per call and discard it after use, consuming O(1) space regardless of how many values are produced. For large datasets, this difference means generators avoid storing the entire sequence in memory at once.

ExplanationThe lambda key is x[0] + len(x[1]). For (3,"b"): key = 3 + len("b") = 3 + 1 = 4. For (6,"a"): key = 6 + len("a") = 6 + 1 = 7. Since 4 is less than 7, the sorted order remains [(3,"b"), (6,"a")]. Sorting is comparison-based, so overall time complexity is O(n log n); each lambda evaluation itself is O(1) since it only does constant-time tuple indexing, addition, and a length lookup.

ExplanationThe string "hello world python" has 18 characters: "hello" contributes 5, the space after it 1, "world" contributes 5, the space after it 1, and "python" contributes 6, for a total of 5+1+5+1+6 = 18. Python's len() counts every character in a string, including whitespace, so it never drops or ignores spaces the way the 16-character answer assumes. The write() call sends this same string to the file but does not consume or empty the string object itself, so len() still measures the original 18-character string rather than 0. Separately, the with statement is a context manager: it calls the file object's __enter__ method when the block begins and guarantees __exit__ runs when the block ends, even if an exception occurs partway through. For an open file, __exit__ closes the file, so f is already closed once the with block finishes, and no additional close() call is needed — the with statement's guarantee covers cleanup itself, not just exception handling.

Explanationlst = [1,2,3] creates a list object with 3 elements. In Python, function arguments are passed as references to objects (not copies), so modify(lst) makes l an alias for the same list that lst points to. Calling l.append(4) mutates that shared object in place, adding a fourth element, and since l and lst refer to the same object the change is visible outside the function too — after modify(lst) returns, lst is [1,2,3,4], giving a final length of 4. This differs from immutable types: if x were an int, x = 100 inside a function would only rebind the local name and leave the caller's variable untouched. To avoid this kind of unintended side effect, pass a copy instead, e.g. modify(lst.copy()) or modify(lst[:]).

ExplanationThe nested list comprehension [x for row in matrix for x in row] flattens the 3x3 matrix by iterating rows in the outer for-clause and, for each row, iterating elements x in the inner for-clause. This produces [2,4,6,8,10,12,14,16,18], matching the row-by-row order of nested loops because the for-clauses in a comprehension are read left to right in the same order they would be written as nested for-loops (outer loop over rows, inner loop over elements within each row). Summing these nine elements: 1+2+...+9 = 45, and since every value in the matrix is double the corresponding value from 1-9, the total is 45*2 = 90.

ExplanationFirst, the generator expression (x**3 for x in range(1,7) if x%3==0) creates an iterator. Filtering x%3==0 selects 2 values. Then, computing: x=3 → x**3=27, x=6 → x**3=216. Sum: 27+216 = 243. List comprehensions allocate memory for all 2 values upfront: O(n) space. Generators compute one value per call, consuming O(1) space. For large datasets, generators save memory dramatically because they produce values on-demand. Early termination is efficient: unrequested values are never generated, avoiding wasted computation. Finally, generators implement the iterator protocol and are ideal for infinite sequences and streaming data because of lazy evaluation.

ExplanationFirst, list mutation demonstrates that lists are mutable reference types because function parameters receive object references, not copies. lst = [1,2,3] creates list object with 3 elements. Then, modify(lst) passes reference to list, not a copy because Python uses call-by-object. Inside modify: l is alias for original lst because both refer to same object. l.append(6) mutates object because append() modifies in-place. After call, lst = [1,2,3,6] with length 4 because original was modified. This is different from immutables: def modify_int(x): x = 100 doesn't affect caller because integers are immutable. If function should not modify caller's list, use lst.copy() or lst[:] because this creates shallow copy. Understanding references is essential because it explains unexpected mutations in large programs. Finally, many bugs occur because functions modify arguments unintentionally.

ExplanationThe nested list comprehension [x for row in matrix for x in row] flattens the 3x3 matrix by reading the for-clauses left to right: the outer for iterates over each row in matrix, and for each row, the inner for iterates over each element x within that row, exactly matching the order of two nested for-loops. This produces [3,6,9,12,15,18,21,24,27], and summing these nine values gives 3+6+9+12+15+18+21+24+27 = 135. Equivalently, each row sums to 18, 45, and 72, which together also total 135. The distractor of 45 comes from summing only the middle row instead of all three rows; 270 comes from double-counting every element as if the outer and inner loops each contributed a full separate pass; and 15 comes from mistakenly dividing the correct sum by the element count of 9, confusing a sum with an average.

ExplanationFirst, the generator expression (x**2 for x in range(1,7) if x%2==0) creates an iterator. Filtering x%2==0 selects 3 values. Then, computing: x=2 → x**2=4, x=4 → x**2=16, x=6 → x**2=36. Sum: 4+16+36 = 56. List comprehensions allocate memory for all 3 values upfront: O(n) space. Generators compute one value per call, consuming O(1) space. For large datasets, generators save memory dramatically because they produce values on-demand. Early termination is efficient: unrequested values are never generated, avoiding wasted computation. Finally, generators implement the iterator protocol and are ideal for infinite sequences and streaming data because of lazy evaluation.

ExplanationList mutation demonstrates that lists are mutable reference types because function parameters receive object references, not copies. lst = [1,2,3] creates a list object with 3 elements. modify(lst) passes a reference to that same list, not a copy, since Python uses call-by-object-reference. Inside modify, l is an alias for lst, so l.append(5) mutates the original list in place. After the call, lst = [1,2,3,5], so its length is 4.

ExplanationThe nested list comprehension [x for row in matrix for x in row] flattens the 3x3 matrix by evaluating its for-clauses left-to-right, exactly matching nested loop structure: the outer clause (for row in matrix) acts like the outer loop, stepping through each row in order, and for each row the inner clause (for x in row) acts like the inner loop, stepping through that row's elements before the outer loop advances to the next row. This produces the flat list [4, 8, 12, 16, 20, 24, 28, 32, 36]. Adding these nine values gives 4+8+12+16+20+24+28+32+36 = 180, which also equals (1+2+3+4+5+6+7+8+9)*4 = 45*4 = 180.

ExplanationFirst, the generator expression (x**4 for x in range(1,7) if x%3==0) creates an iterator. Filtering x%3==0 selects 2 values. Then, computing: x=3 → x**4=81, x=6 → x**4=1296. Sum: 81+1296 = 1377. List comprehensions allocate memory for all 2 values upfront: O(n) space. Generators compute one value per call, consuming O(1) space. For large datasets, generators save memory dramatically because they produce values on-demand. Early termination is efficient: unrequested values are never generated, avoiding wasted computation. Finally, generators implement the iterator protocol and are ideal for infinite sequences and streaming data because of lazy evaluation.

ExplanationThe comprehension [x for row in matrix for x in row] reads left to right exactly like nested loops: the outer clause (for row in matrix) runs first, and for each row the inner clause (for x in row) runs second, collecting x. Walking through matrix row by row gives flat = [5,10,15,20,25,30,35,40,45]. Adding these nine values: 5+10+15+20+25+30+35+40+45 = 225. This shows the double-for order mirrors nested for-loops -- outer variable fixed while the inner variable cycles through it -- which is exactly the row-major flattening that produces the sum 225.

ExplanationFirst, the generator expression (x**3 for x in range(1,7) if x%2==0) creates an iterator. Filtering x%2==0 selects 3 values. Then, computing: x=2 → x**3=8, x=4 → x**3=64, x=6 → x**3=216. Sum: 8+64+216 = 288. List comprehensions allocate memory for all 3 values upfront: O(n) space. Generators compute one value per call, consuming O(1) space. For large datasets, generators save memory dramatically because they produce values on-demand. Early termination is efficient: unrequested values are never generated, avoiding wasted computation. Finally, generators implement the iterator protocol and are ideal for infinite sequences and streaming data because of lazy evaluation.

ExplanationFirst, the nested list comprehension [x for row in matrix for x in row] systematically flattens the 3x3 matrix. The outer for-clause iterates over each row. Then, for each row, the inner for-clause iterates over elements x in that row. This produces [6,12,18,24,30,36,42,48,54]. The sum equals (1+2+3+4+5+6+7+8+9)*6 = 45*6 = 270. This pattern is equivalent to nested loops because the multiple for-clauses are read left-to-right, matching nested loop order. Time complexity is O(m*n) where m=3 rows and n=3 columns. This left-to-right ordering is equivalent to writing `for row in matrix: for x in row: flat.append(x)`, which confirms the flattened sequence [6,12,18,24,30,36,42,48,54] sums to 270.