Grade 8 AI & Computer Science Practice Questions — Set 6

ExplanationTracing the recursion: inorder(8) first fully explores the left subtree before touching the root, so it calls inorder(3). That call in turn explores its own left child first: inorder(1) has no children, so it immediately appends 1. Back in the call for node 3, the node's own value is appended next, giving 3, and then its right child 6 is explored and appended, giving 6. This finishes the entire left subtree of 8, so 8 is appended next, and finally the right subtree rooted at 10 is explored, appending 10. The full sequence built by result.append is [1, 3, 6, 8, 10]. This is exactly the sorted order of the five values, which is not a coincidence: in a binary search tree every left child holds a smaller value than its parent and every right child holds a larger one, and an in-order traversal (left, node, right) always visits nodes in that ascending order as a direct consequence of the BST ordering property.

ExplanationAn adjacency list represents a graph as a dictionary where each key is a node and its value is a list of that node's direct neighbors. Here, graph[1] performs one dictionary lookup and returns the list stored under key 1, which is [2, 3] — meaning node 1 connects to nodes 2 and 3. This differs from an adjacency matrix, where finding a node's neighbors would require scanning a full row of the matrix; the dictionary-based adjacency list gives O(1) access to any node's neighbor list and uses O(V + E) total space overall, which is why it is the standard choice for representing sparse graphs.

ExplanationDFS (Depth-First Search) starts at a node and recursively explores each unvisited neighbor, marking nodes as visited to avoid revisiting them and to safely handle cycles. Trace: visit 1, explore 2 (recurse: visit 2, explore 4 (recurse: visit 4, no unvisited neighbors)), back to 1, explore 3 (recurse: visit 3, no unvisited neighbors). Every node reachable from 1 gets added to visited. Result: {1, 2, 3, 4}. Time complexity: O(V+E), since each vertex is visited once and each edge is examined once.

ExplanationThe result is 120. The comprehension applies val*2 to each element of x in turn: 10 becomes 20, 20 becomes 40, and 30 becomes 60, producing y = [20, 40, 60]. sum(y) then adds these together: 20 + 40 + 60 = 120. This shows why list comprehensions are useful for compact transformations: a single expression [val*2 for val in x] both transforms each element and collects the results into a new list, doing in one line what would otherwise take a for-loop with an explicit accumulator list and repeated append() calls.

Explanation0 is returned. dict.get(key, default) works by checking whether the given key exists in the dictionary — it does not care whether the value stored at that key is truthy or falsy. Here, 'volume' is a key that exists in settings, mapped to the value 0, so get() returns that stored value directly and the default 50 is never used; the default only kicks in when the requested key is genuinely absent. The keys 'brightness' and 'sound' are irrelevant to this call — get() performs a direct hash-based lookup on the exact key name passed to it ('volume'), not a scan through the dictionary in order, so their values (None and False) never enter the picture. The deeper point is that Python's falsy values — 0, None, False, empty strings, and empty containers — are a separate concept from key presence; confusing "the value looks empty" with "the key is missing" is a common bug source when using get() for defensive programming.

ExplanationCounting characters from index 0: H=0, e=1, l=2, l=3, o=4, space=5, W=6 — so 'World' begins at index 6, making result equal to 6. find() scans the string internally and returns the starting index of the first match (or -1 if the substring isn't present), which is exactly why it saves you from writing a manual loop to search character by character.

ExplanationThe result is 24. Tracing the recursion: factorial(4) calls factorial(3), which calls factorial(2), which calls factorial(1); factorial(1) hits the base case (n <= 1) and returns 1 immediately, with no further recursive call. The stack then unwinds: factorial(2) returns 2 * 1 = 2, factorial(3) returns 3 * 2 = 6, and factorial(4) returns 4 * 6 = 24. This uses only 4 levels of recursion, far below Python's default recursion limit of 1000, so no RecursionError occurs. The base case is also checked and reached before any multiplication takes place, not after — each call must finish evaluating n <= 1 first, and only the calls where that is false proceed to compute n * factorial(n - 1).

ExplanationTracing the operations one at a time: after the three append() calls the deque holds ['A', 'B', 'C'] in arrival order. Calling popleft() removes and discards the front element, 'A', leaving ['B', 'C']. Appending 'D' then adds to the back, giving ['B', 'C', 'D'], which is exactly what list(queue) returns. This demonstrates FIFO (first-in-first-out): the earliest-arrived item is always the one removed next, unlike a stack's pop() which removes from the back and behaves as LIFO (last-in-first-out). A common mix-up is treating popleft() as a back-removal operation or as a non-destructive peek, but deque.popleft() always removes and returns the leftmost element in O(1) time — which is why deque, not a plain list, is the standard choice for efficient queue implementations.

Explanationjson.dumps() walks the dictionary and converts each value to its nearest JSON equivalent, not just the outer braces. A Python tuple has no matching JSON type, so (88, 92, 79) is written out as the JSON array [88, 92, 79] — tuples are perfectly serializable, json.dumps() only refuses types with no defined conversion, such as sets or custom class instances, so no TypeError occurs here. Python's True does have a JSON counterpart, the boolean literal true, but JSON keywords are lowercase, so True becomes true, not True and not the integer 1. Dictionary keys keep their insertion order during serialization, so the complete result is the string {"name": "Asha", "marks": [88, 92, 79], "passed": true}.

ExplanationTracing each insertion step by step: inserting 12 gives [12] (no parent, no swap). Inserting 5 appends it at index 1; its parent at index 0 is 12, and since 5 &lt; 12 they swap, giving [5, 12] after 1 swap. Inserting 18 appends it at index 2; its parent at index 0 is 5, and since 18 is not smaller than 5, no swap happens, leaving [5, 12, 18]. Inserting 3 appends it at index 3; its parent at index 1 is 12, and since 3 &lt; 12 they swap to [5, 3, 18, 12] — but the sift-up isn't finished, because 3 is now at index 1, whose parent at index 0 is 5, and since 3 &lt; 5 they swap again, giving [3, 5, 18, 12] after 2 swaps for this insertion. Inserting 9 appends it at index 4; its parent at index 1 is 5, and since 9 is not smaller than 5, no swap happens, leaving the final array [3, 5, 18, 12, 9]. Adding up the swaps (0 + 1 + 0 + 2 + 0) gives 3 total swaps, matching the array produced by walking the value up through its actual parent chain one level at a time. The claim that stopping after one swap for the insertion of 3 gives [5, 3, 18, 12, 9] misses that a sifted value must keep checking against each ancestor up to the root, not just its immediate parent at the level where it first stopped. The claim that the heap stays fully sorted as [3, 5, 9, 12, 18] confuses a min-heap, which only guarantees each parent is smaller than its own children, with a sorted array, where every element is smaller than everything to its right — a heap enforces no ordering between sibling subtrees. The claim that comparing 3 directly against the root produces [3, 12, 18, 5, 9] describes a different, incorrect algorithm — sift-up must move the value one level at a time, testing against its true parent at each step, never jumping straight to a comparison with the root.

ExplanationDecorating fact with @counter executes fact = counter(fact), which rebinds the global name fact to wrap. Inside fact's own body, the call fact(n-1) looks up the name fact at call time (not at definition time) — and that name now points to wrap, not the original undecorated function. So calling fact(4) actually invokes wrap(4): calls becomes 1, it prints "call #1", then it runs the original body, which computes 4 * fact(3). That fact(3) again resolves to wrap, printing "call #2"; then fact(2) -> "call #3"; then fact(1) -> "call #4", where n<=1 stops further recursion. So "call #" prints exactly 4 times — once for each call from fact(4) down through fact(1) — even though the decorator appears in the source only once. The final return value is unaffected: fact(4) still correctly evaluates to 24, since every wrap layer just forwards to fn(*a) and returns its result unchanged. What multiplies is the decorator's side effect (the print/count), not the arithmetic. This is the classic pitfall of decorating a recursive function in Python: because name resolution happens at call time, every recursive self-call is silently routed back through the decorator.

Explanationitertools.combinations(iterable, r) selects elements by their index positions in the original order, never rearranging or reordering them, and never repeating an index within one tuple. For [10, 20, 30, 40] with r=3, the index combinations in lexicographic order are (0,1,2), (0,1,3), (0,2,3), (1,2,3) — exactly C(4,3) = 4!/(3!·1!) = (4·3·2·1)/((3·2·1)·1) = 4 tuples. Mapping indices back to values gives (10,20,30), (10,20,40), (10,30,40), (20,30,40), so the very first tuple produced is (10, 20, 30). The choice claiming 24 tuples confuses combinations with permutations: permutations([10,20,30,40], 3) treats order as significant and does give P(4,3) = 4!/1! = 24 results, but combinations() ignores order entirely, so 24 is wrong here. The choice claiming 6 tuples applies the wrong r, computing C(4,2) = 6 instead of C(4,3) = 4 — the code clearly requests r=3, not r=2. The choice claiming the first tuple is (20, 30, 40) gets the correct count (4 tuples) but the wrong order: combinations() does not build groups by dropping the first element first: it advances the last index before backtracking, so the smallest elements (10,20,30) appear first, not (20,30,40).</explanation>

ExplanationTrace it step by step, appending each value and sifting it up to its correct position: insert 5 -> [5]; insert 3 -> append gives [5,3], index1's parent is index0 (5), and 3<5 so swap -> [3,5]; insert 8 -> append gives [3,5,8], index2's parent is index0 (3), and 8 is not less than 3 so no swap -> [3,5,8]; insert 1 -> append gives [3,5,8,1], index3's parent is index1 (5), 1<5 so swap -> [3,1,8,5], then index1's parent is index0 (3), 1<3 so swap again -> [1,3,8,5]; insert 9 -> append gives [1,3,8,5,9], index4's parent is index1 (3), 9 is not less than 3 so no swap -> [1,3,8,5,9]; insert 2 -> append gives [1,3,8,5,9,2], index5's parent is index2 (8), 2<8 so swap -> [1,3,2,5,9,8], then index2's parent is index0 (1), 2 is not less than 1 so the sift-up stops. The final array is [1, 3, 2, 5, 9, 8]. The claim that the array is fully sorted low to high confuses a min-heap (which only guarantees each parent is smaller than its children) with a fully sorted array — a heap only needs to be sorted along root-to-leaf paths, not level by level. The claim that every value simply stays where it was first appended forgets that sift-up must run after every insertion to restore the heap property, not just before a removal. The claim that 2 keeps swapping upward through every remaining ancestor regardless of the comparison misapplies sift-up by ignoring its stopping condition: the swap chain halts the moment the child is no longer smaller than its parent, so 2 never swaps with the root 1 once it lands correctly at index 2.

ExplanationWhen @shout decorates greet, the name greet is rebound to point at wrapper instead of the original function. So calling greet("aditi") actually calls wrapper("aditi"), where args becomes ("aditi",). Inside wrapper, the line result = fn(*args) calls the original (undecorated) greet("aditi"), which returns the string "hello aditi" and stores it in result. Wrapper then runs return result.upper(), turning "hello aditi" into "HELLO ADITI" — and this uppercase string is what flows back out of greet("aditi") to print(), so the output is HELLO ADITI. The claim that the output is None is wrong because it ignores that wrapper explicitly returns result.upper() rather than discarding it. The claim that the output stays "hello aditi" is wrong because it wrongly assumes a decorator can only add side-effect behaviour (like logging) around a call and can never touch the return value — in fact wrapper is free to transform result however it wants before handing it back. The claim that a TypeError occurs is wrong because *args collects positional arguments regardless of what the original function called its parameter (name); a decorator does not need to know the original parameter names to forward arguments correctly.

ExplanationA `with A(), B():` statement is equivalent to nesting them: `with A(): with B():`. So __enter__ calls happen in the order written — A enter, then B enter — and the body runs, printing "body". When the block ends, Python unwinds the context managers like nested function calls: the most recently entered one is exited first, so B's __exit__ runs before A's. That gives the sequence A enter, B enter, body, B exit, A exit. This LIFO (last-in, first-out) exit order is a defining property of how nested/multiple context managers work in Python, analogous to how nested try/finally blocks unwind from the inside out.

Explanationitertools.combinations('PQRST', 3) generates every 3-element subset of the 5 letters without regard to order and without repeating any element, so the count is C(5,3) = 5!/(3!*(5-3)!) = 120/(6*2) = 10. Written out, result is exactly: ('P','Q','R'), ('P','Q','S'), ('P','Q','T'), ('P','R','S'), ('P','R','T'), ('P','S','T'), ('Q','R','S'), ('Q','R','T'), ('Q','S','T'), ('R','S','T') — 10 tuples in total, each listed only once regardless of letter order. Option B applies the permutations formula instead: P(5,3) = 5!/2! = 60 counts ('P','Q','R') and ('P','R','Q') as different results, which is what itertools.permutations does, not combinations. Option C's 5^3 = 125 would be the count if repeats were allowed and order mattered (like itertools.product('PQRST', repeat=3)), which is a different operation entirely. Option D confuses combinations with a simpler one-group-per-letter scheme; it ignores that each starting letter actually pairs with multiple later letters (e.g., 'P' alone starts 6 different triples: PQR, PQS, PQT, PRS, PRT, PST).

ExplanationTrace the insertions with parent index (i-1)//2, swapping while the new value is smaller than its parent. Inserting 5 gives [5]. Inserting 3 appends to [5,3]; since 3 is smaller than parent 5, it swaps to [3,5]. Inserting 8 appends to [3,5,8]; 8 is not smaller than parent 3, so no swap. Inserting 1 appends to [3,5,8,1]; 1 is smaller than parent 5, swap to [3,1,8,5], then 1 is smaller than parent 3, swap again to [1,3,8,5]. Inserting 9 appends to [1,3,8,5,9]; 9 is not smaller than parent 3, so no swap. Inserting 2 appends to [1,3,8,5,9,2]; 2 is smaller than its parent 8 (at index 2), so they swap to [1,3,2,5,9,8]; 2 is then compared with the root 1 and is not smaller, so sifting stops. The final array [1, 3, 2, 5, 9, 8] satisfies the min-heap property at every level: root 1 is smaller than its children 3 and 2, node 3 is smaller than its children 5 and 9, and node 2 is smaller than its child 8. Using the wrong parent formula i//2 instead of (i-1)//2 would incorrectly swap 2 past 3 as well, giving [1, 2, 3, 5, 9, 8]. Stopping the algorithm before the last sift-up would leave [1, 3, 8, 5, 9, 2], which violates the heap property because 8 sits above the smaller value 2. Applying max-heap logic, where a child swaps up whenever it is larger than its parent, produces an entirely different array, [9, 8, 5, 1, 3, 2], with the largest value at the root.

Explanationcounter(square) runs exactly once, at the moment @counter is applied — this single call creates one calls = [0] list that lives in the closure shared by every future call to square; it is never recreated. square(3): wrapper increments calls[0] to 1, prints "Call #1", computes 3*3=9 and returns it (discarded, since it isn't wrapped in print()). square(5): same shared list, calls[0] becomes 2, prints "Call #2", returns 25 (discarded). print(square(2)): Python must fully evaluate square(2) before print() can run on its result — wrapper increments calls[0] to 3, prints "Call #3", computes 2*2=4, and returns 4; only then does the outer print() display that returned value, 4, on its own line. So the console shows, in order: Call #1, Call #2, Call #3, 4 — matching the choice that keeps one shared, ever-incrementing counter across all three calls. The claim that counter(fn) secretly re-runs on every call wrongly assumes the decorator re-initializes its state each time, which would defeat the entire purpose of using a closure for persistent state. The claim that square(3) and square(5) never execute their internal print confuses "the return value is printed" with "the function executed" — wrapper's own print("Call #...") runs on every call regardless of what the caller does with the return value. The claim that each printed count reflects the value before incrementing misorders the two statements inside wrapper: the increment (calls[0] += 1) executes before the print, so every printed count reflects the already-updated value, never the count from before that call.

ExplanationTrace it step by step. __enter__ runs first, printing "open", and returns self as r. Inside the with-block, print("before") runs, printing "before". Then raise ValueError("boom") executes — this immediately transfers control out of the block, so the line print("after") is skipped entirely; it never runs. Because an exception is propagating, Python calls __exit__(exc_type, exc_val, tb) with the ValueError's details filled in. __exit__ prints "close" and then returns True. In the context manager protocol, __exit__'s return value controls what happens to the exception: a truthy return value (like True) tells Python to suppress it — treat it as handled — while a falsy return value (False, None, or no explicit return) lets it propagate normally. Since True was returned here, the ValueError is swallowed, and execution resumes right after the with statement, printing "done". Final output: open, before, close, done. This is exactly why guaranteed-cleanup behavior (close() always running) is separate from exception-suppression behavior (controlled solely by __exit__'s return value) — mixing these two ideas up is the most common error when reasoning about context managers.

ExplanationC(5,3) = 5! / (3! × 2!) = 120 / (6 × 2) = 10, so len(result) = 10. Working it by hand, itertools.combinations(range(5), 3) enumerates every 3-element subset of {0,1,2,3,4} in lexicographic order, each written with indices strictly increasing left to right: (0,1,2), (0,1,3), (0,1,4), (0,2,3), (0,2,4), (0,3,4), (1,2,3), (1,2,4), (1,3,4), (2,3,4) — that's exactly 10 tuples, matching the formula. Two key properties follow directly from how combinations() is defined: (1) it never repeats an element within a tuple (it picks each index at most once, so something like (0,0,1) can never appear — that's what combinations_with_replacement would do instead), and (2) it never outputs the same set of elements twice in a different order (it only advances indices forward, so (1,0,2) is never generated separately from (0,1,2) — that behavior belongs to permutations, not combinations). The 60-tuple option is the permutations count P(5,3) = 5!/(5-3)! = 60, a common mix-up between the two functions. The 5-tuple option invents a "neighbours only" rule that doesn't match how combinations() actually works — it considers every subset of size r, not just adjacent elements.