Grade 9 AI & Computer Science Practice Questions — Set 7

ExplanationEach of the 6 filters slides over the single-channel image, so every filter has 5 × 5 = 25 weights plus its own bias, for 26 parameters per filter. Because a convolutional layer reuses that same set of 26 numbers at every position the filter slides to — this is weight sharing — the total for the whole layer is just 6 × 26 = 156 parameters, completely independent of the 28×28 image size. Compare that to a fully-connected layer producing 6 outputs from all 784 pixels: it would need 6 × 784 = 4,704 weights (plus biases) because every output connects separately to every pixel. That huge gap — 156 versus 4,704 — is exactly why CNNs can run face-unlock in real time on a phone's limited processor instead of needing a cloud server for every scan.

ExplanationA bigram model scores a sentence by chaining together local, word-to-word transition probabilities rather than by matching the whole sentence against something it memorized, so it can still assign a nonzero score to "cancel my seat" even though that exact three-word sequence never appeared in training — all that matters is whether each consecutive pair of words was individually seen. Walking through the corpus: `<s>` is followed by "cancel" in exactly 1 of the 3 training sentences, so P(cancel|<s>) = 1/3. The word "cancel" appears only once in the whole corpus and is always followed by "my", so P(my|cancel) = 1/1 = 1. The word "my" appears 3 times (once per sentence), and only 1 of those 3 occurrences is followed by "seat" (in "book my seat"), so P(seat|my) = 1/3. Finally, "seat" appears once and is always followed by the end marker, so P(</s>|seat) = 1/1 = 1. Chaining these together gives (1/3) x 1 x (1/3) x 1 = 1/9. Landing on 1/3 comes from dropping the P(cancel|<s>) factor and starting the chain at "my" instead of at the sentence boundary. Landing on 1/6 comes from undercounting Count(my) as 2, by forgetting that "my" also occurs in the ticket-cancellation sentence and not just the two sentences that mention a specific booking action. Landing on 0 confuses an n-gram model with a full-sentence lookup table — the entire point of factoring a sentence into bigrams is that the model can generalize to new word combinations by recombining transitions it has already seen, rather than requiring an exact match to a training sentence.

ExplanationThe key idea a lot of students miss is that a camera-based perception system has two separate sources of delay that stack, not one. First, the camera only samples the world at discrete moments — at 20 frames per second, a new frame is captured every 1/20 s = 50 ms. If a pedestrian steps into view right after a frame was just taken, the system has no idea anything happened until the next frame arrives, which in the worst case takes nearly the full 50 ms frame period. Only once that frame is captured does the 150 ms compute-vision pipeline (detection plus decision) start running. So the total worst-case perception-to-action delay is 50 ms + 150 ms = 200 ms = 0.2 s, not just the 150 ms processing time alone. Converting speed: 72 km/h = 72000 m / 3600 s = 20 m/s. Distance covered during the 0.2 s delay is 20 m/s x 0.2 s = 4 m. This 4 m gap is added on top of the car's normal mechanical braking distance, which is why real autonomous-driving stacks are engineered to minimize both frame rate lag and inference latency — every millisecond of delay directly becomes extra stopping distance at highway speed, similar to how a driver's reaction time before applying the brake adds distance in ordinary drivers' education physics problems.

ExplanationThis is Diffie–Hellman key exchange, and the whole scheme rests on one asymmetry: modular exponentiation is cheap to compute in the forward direction but expensive to reverse (the discrete logarithm problem). Alice knows her private exponent a = 6, so she computes B^a mod p = 19^6 mod 23 by repeated multiplication and reduction: 19^2 mod 23 = 361 mod 23 = 16; 19^3 mod 23 = 16 × 19 mod 23 = 304 mod 23 = 5; 19^4 mod 23 = 5 × 19 mod 23 = 95 mod 23 = 3; 19^5 mod 23 = 3 × 19 mod 23 = 57 mod 23 = 11; 19^6 mod 23 = 11 × 19 mod 23 = 209 mod 23 = 2. So Alice's shared secret is 2. Bob independently lands on the same number by computing A^b mod p = 8^15 mod 23, which also equals 2 — that both sides land on the identical value without ever exchanging it directly is the entire point of the protocol. An eavesdropper watching the wire sees only p, g, A, and B, never a or b, so reproducing B^a or A^b would mean first recovering a hidden exponent from a public value — computationally infeasible once p is realistically large. Multiplying or adding the intercepted public values (getting 14 or 4) looks like a shortcut but is a trap: both operations use nothing except information the eavesdropper already has, so if either were the real shared secret, the key exchange would offer zero protection. Raising B to Bob's own exponent b instead of Alice's a (getting 20) is a different kind of mistake — it isn't something Alice could ever produce herself, since b is Bob's private value and is never sent across the network for her to use.

ExplanationMin-max scaling is a feature-engineering step where the minimum and maximum are learned from the training data alone and then frozen — they are stored constants, not something recomputed on every new input. With min = 200 and max = 1000 from training, the formula for the test point is (1200 - 200) / (1000 - 200) = 1000 / 800 = 1.25. This is the whole point of "fit on train, transform on test": the scaler has no awareness of the 1200 mm value's existence beyond plugging it into the frozen formula, so nothing stops the output from leaving the [0, 1] range when real-world data exceeds what training ever showed it — a genuine and consequential edge case, since a downstream model trained only on inputs in [0, 1] may behave unpredictably on 1.25. Clipping to [0, 1] is not automatic behavior of standard min-max scaling; a scaler does not silently update its stored min/max on every transform call, since that would make outputs inconsistent across time (the same rainfall value would normalize differently depending on what else had been transformed before it) and defeat the purpose of a fixed, reproducible feature; and flipping the numerator to (max - rainfall) computes a different, unrelated quantity (a "distance from the top" measure) rather than the standard min-max normalization, and gives -0.25, not the correct 1.25.

ExplanationStart with the base model. The mean of all four targets is (80 + 100 + 180 + 200) / 4 = 560 / 4 = 140, so F₀ = 140 for every day. Next, compute residuals (actual − F₀): normal days give 80 − 140 = −60 and 100 − 140 = −40; festival days give 180 − 140 = 40 and 200 − 140 = 60. The first tree splits on the festival-day feature, and each leaf outputs the average residual of its group: the normal-day leaf outputs (−60 + −40) / 2 = −50, and the festival-day leaf outputs (40 + 60) / 2 = 50. The key idea in gradient boosting is that this tree does not replace the base prediction — it corrects it, and only by a fraction of its full output. XGBoost scales every new tree's contribution by the learning rate η before adding it in: F₁ = F₀ + η × (leaf value). For a festival day, that's F₁ = 140 + 0.1 × 50 = 140 + 5 = 145. Skipping the learning rate and adding the full residual (140 + 50 = 190) is the most common error — it ignores why shrinkage exists: it deliberately caps each tree's influence so the model needs many small, cautious steps rather than one large, overfitting-prone jump. Treating the tree's leaf value (50) as the whole prediction confuses gradient boosting with a single decision tree — boosted models are additive ensembles, and F₀ is never discarded. Averaging the base prediction with the leaf value (95) invents an operation gradient boosting doesn't use; the tree's output is always a scaled, additive correction, never blended in by averaging.

ExplanationThe raw attention score between the query and each key is the dot product: q·k(trunk) = 4(2) + 1(3) = 8 + 3 = 11, q·k(almirah) = 4(1) + 1(5) = 4 + 5 = 9, and q·k(large) = 4(0) + 1(2) = 0 + 2 = 2. In self-attention, a larger dot product means the query and key vectors point in more similar directions — stronger relatedness — which is the opposite of a distance metric, where a smaller value means two things are closer. Softmax then turns these three scores into probabilities, but softmax is a strictly increasing (monotonic) function: it never changes the relative ranking of its inputs, so whichever score goes in largest comes out as the largest weight. Since 11 is the largest of the three raw scores, "trunk" receives the highest attention weight — which also matches the sentence itself, since something described as "too large" to fit is the trunk, not the almirah (the container) or the word "large" (an adjective, not a real antecedent). Key-vector magnitude on its own does not determine attention weight: "almirah"'s key vector has the largest magnitude (√26 ≈ 5.10) of the three, yet it still scores lower than "trunk" once direction is combined with the query through the dot product. And softmax does not force equal outputs — it only guarantees the outputs are positive and sum to 1, while still preserving the order of the scores that were fed into it.

ExplanationThe 9 baseline values (42, 45, 40, 48, 44, 43, 46, 41, 47) sum to 396, giving a mean of 396/9 = 44. Squaring each deviation from 44 gives 4, 1, 16, 16, 0, 1, 4, 9, 9, which sum to 60. Dividing by 9 (population variance) gives 6.67, and taking its square root gives the population standard deviation, about 2.58. Two standard deviations above the mean is 44 + 2(2.58) ≈ 49.2 attempts — that is the flagging threshold. The 10th hour recorded 50 attempts, which is greater than 49.2, so it crosses the threshold and gets flagged as anomalous. Squaring the deviations but never taking the square root (using variance instead of standard deviation) inflates the apparent spread to 6.67 and the threshold to about 57, which is why that path wrongly clears the 50-attempt hour. Folding the new 50-attempt reading into the baseline itself is a classic anomaly-detection pitfall: it shifts the mean to 44.6 and the standard deviation to about 3.04, nudging the threshold up to about 50.7 — the outlier contaminates its own baseline and just barely escapes detection. And using only 1 standard deviation above the mean (about 46.6) ignores the problem's explicit 2-standard-deviation rule, even though it happens to still flag the hour for the wrong reason.

ExplanationThe 100-second job splits into a 20-second sequential portion (updating the shared counter) that no amount of parallel hardware can shrink, and an 80-second portion whose runtime scales with the number of cores used. Spreading that 80-second portion across 4 cores brings it down to 80 ÷ 4 = 20 seconds, so the new total runtime is 20 (serial) + 20 (parallel) = 40 seconds. Comparing the original 100 seconds to the new 40 seconds gives a speedup of 100 ÷ 40 = 2.5x. This is exactly what Amdahl's Law predicts: the unavoidable serial fraction (20% of the original job) caps how much benefit adding cores can deliver, so 4 cores never produce a full 4x improvement. The 4x answer assumes the entire job speeds up in proportion to the core count, ignoring that the 20-second serial section still runs on a single core no matter how many cores are available. The 3.2x answer comes from multiplying the core count by the parallelizable fraction (4 x 0.8) — a shortcut that never actually computes a real execution time, so it doesn't correspond to how the job actually runs. The 5x answer results from a bookkeeping slip: it divides only the parallel portion (80 ÷ 4 = 20 seconds) and forgets to add the fixed 20-second serial portion back in, treating the new total runtime as just 20 seconds instead of the true 40 seconds.

ExplanationCross-validation only gives a fair estimate of real-world accuracy when every piece of information the model uses—including preprocessing statistics like a scaler's mean and standard deviation—is learned exclusively from the training portion of each fold, with the held-out portion staying completely untouched until scoring time. In the code shown, StandardScaler().fit_transform(X) runs once on the entire 200-email dataset before cross_val_score ever splits it, so the mean and standard deviation baked into every scaled feature already reflect information from all 200 emails. When cross_val_score then forms its 5 folds of 160 training and 40 validation emails each, the 40 validation emails in every single fold have already left a statistical fingerprint on the very features the SVC is trained on. cross_val_score cannot undo this: it only controls what happens to the estimator object you hand it (here, plain SVC()), not any transformation you applied beforehand. Wrapping StandardScaler and SVC together in a Pipeline fixes this precisely because cross_val_score then refits the whole Pipeline on each fold, so the scaler's mean and standard deviation get recomputed from only that fold's 160 training emails, leaving its 40 validation emails genuinely unseen until scoring. The practical consequence of the leaked version is that the reported cross-validated accuracy tends to look better than the model will actually achieve on brand-new, never-before-seen tickets, since the scaler has effectively already been shown a numerical summary of the test data.

ExplanationdetectMultiScale builds an image pyramid: it starts the detection window at minSize and multiplies its side length by scaleFactor at each step, stopping the instant a size would exceed maxSize. Starting from 20 px: 20 -> 20 x 1.5 = 30 -> 30 x 1.5 = 45 -> 45 x 1.5 = 67.5 -> 67.5 x 1.5 = 101.25 -> 101.25 x 1.5 = 151.875. That sixth value, 151.875 px, is larger than maxSize = 150 px, so that window is never tested. This leaves exactly five window sizes actually used: 20, 30, 45, 67.5, and 101.25 pixels. Two common slips explain the wrong answers. Rounding 151.875 down as "basically 150" and counting it anyway gives 6 — but detectMultiScale checks the exact size against maxSize, with no rounding tolerance. Forgetting that minSize itself is the first window tested (and only counting the sizes produced by multiplication) gives 4, an off-by-one error. Finally, OpenCV does not restrict window sizes to whole-number multiples of minSize — internally it scales the image by 1/scaleFactor at each pyramid level, so fractional-pixel sizes like 67.5 and 101.25 are completely normal, which is why the "3 whole-multiple sizes" answer is wrong too.

ExplanationTreat cricket, bat, and cat as arrows from the origin in a toy 2-D embedding space: cricket = (6, 8), bat = (3, 4), cat = (8, 6). Cosine similarity measures the angle between two vectors — cosθ = (A·B)/(|A||B|) — while Euclidean distance measures the straight-line gap between their tips; these are different questions and can point to different "winners." Magnitudes: |cricket| = √(36+64) = √100 = 10, |bat| = √(9+16) = √25 = 5, |cat| = √(64+36) = √100 = 10. cricket·bat = 6(3) + 8(4) = 18 + 32 = 50, so cos(cricket, bat) = 50/(10·5) = 1.00 — bat points in exactly the same direction as cricket, since cricket is literally 2×bat. cricket·cat = 6(8) + 8(6) = 48 + 48 = 96, so cos(cricket, cat) = 96/(10·10) = 0.96 — a noticeably different direction. Meanwhile Euclidean distance goes the other way: cricket to bat is √((6-3)² + (8-4)²) = √25 = 5, but cricket to cat is √((6-8)² + (8-6)²) = √8 ≈ 2.83 — cat's raw coordinates sit numerically closer to cricket's. This is exactly why NLP systems compare word embeddings using cosine similarity rather than raw distance or a bare dot product. Two words can end up far apart in coordinate space simply because one appears more often in the training corpus and so has a longer vector, yet still mean almost the same thing as long as they point the same way (this is why bat's vector is a shorter, scaled-down copy of cricket's — same direction, different magnitude). Trusting Euclidean distance, or trusting the un-normalized dot product (96 > 50 looks convincing until you notice cat's vector is also longer, which inflates the dot product), both wrongly crown cat as the better match for cricket, when direction — not raw coordinate closeness — is what captures meaning.

ExplanationPARTITION BY state splits the table into separate ranking groups, so Kabir competes only against the other three Karnataka rows, not the Maharashtra ones. Within Karnataka, ORDER BY amount DESC sorts the amounts as 4200, 3800, 3800, 3500 — Aisha gets rnk 1, and Rohan and Meera tie for rnk 2 since they have the same amount. RANK() does not compress the sequence after a tie the way DENSE_RANK() does: it counts how many rows sit ahead of Kabir in the ordering (Aisha, Rohan, and Meera — three rows), so Kabir's rank is 3 + 1 = 4, leaving rnk 3 permanently unused in this partition. If the query used DENSE_RANK() instead, Kabir would get 3, because DENSE_RANK() numbers only the distinct amount values (4200, 3800, 3500) with no gaps. Reading ORDER BY amount DESC as ranking the smallest amount first would wrongly place Kabir at rnk 1, and ignoring PARTITION BY state and ranking all seven rows together (5000, 5000, 4700, 4200, 3800, 3800, 3500) would wrongly give Kabir rnk 7.

ExplanationTotal variance equals the sum of all eigenvalues: 42 + 28 + 18 + 8 + 4 = 100 variance units. Tracking the cumulative share as components are added one at a time: the first component alone covers 42%, the first two cover 42 + 28 = 70%, the first three cover 70 + 18 = 88%, and the first four cover 88 + 8 = 96%. Three components still fall short of the 90% target at 88%, while four components clear it at 96%, so four is the smallest number of principal components that satisfies the requirement. This mirrors how a real PCA pipeline chooses component count in practice — by plotting cumulative explained variance and picking the smallest number of components above a target threshold (commonly 90-95%), rather than defaulting to 2 components just because that's convenient for plotting, or keeping all 5 components, which keeps 100% of the variance but defeats the purpose of dimensionality reduction entirely.

ExplanationMock() creates a generic mock object, and setting gateway.charge.side_effect to a list makes each call to gateway.charge return the next item from that list in order — 1001 on the first call, 1002 on the second, 1003 on the third — completely independent of what argument was actually passed in. So after the loop runs over fares [640, 1280, 1920], txn_ids ends up as [1001, 1002, 1003], not the fares themselves. Separately, Mock records every call it receives, but assert_called_with(...) checks only the arguments of the single most recent call — it is not the same as assert_has_calls(...), which would check the full sequence of calls. Since the last call made inside the loop was gateway.charge(1920), the assertion matches and passes silently, even though gateway.charge was also called earlier with 640 and 1280. No StopIteration occurs either, because side_effect only raises that error if the mock is called again after its list is exhausted — here gateway.charge is called exactly three times, once per fare, matching the three items in the list precisely.

ExplanationStyle loss compares Gram matrices, not raw activations, because the Gram matrix captures which filters fire together (feature correlations) — brushstroke patterns, color palettes, textures — independent of where in the image they occur. That correlation information is exactly what "style" means to a CNN. For the style image: G_AA = 3²+1²+2²+0² = 14, G_BB = 1²+2²+0²+1² = 6, G_AB = G_BA = (3×1)+(1×2)+(2×0)+(0×1) = 5. For the generated image: G_AA = 2²+2²+1²+1² = 10, G_BB = 0²+1²+1²+0² = 2, G_AB = G_BA = (2×0)+(2×1)+(1×1)+(1×0) = 3. The Gram matrix here is a full 2×2 matrix, so the style loss sums the squared difference over all four entries — AA, AB, BA, and BB — not just the diagonal or one triangle: (14−10)² + (5−3)² + (5−3)² + (6−2)² = 16 + 4 + 4 + 16 = 40. 36 comes from forgetting that AB and BA are both counted separately (summing the upper triangle only once), which understates the loss whenever cross-filter correlation shifts. 32 comes from using only the diagonal entries (AA and BB), which throws away exactly the cross-filter correlation that makes Gram matrices useful for capturing style — with only diagonals you're left comparing each filter's own activation energy, which misses how filters co-occur. 8 comes from skipping the Gram matrix entirely and computing the squared difference of the raw activations directly — that is literally the content loss formula, not the style loss, which is why style transfer must compute the two losses differently even though the images being compared look similar on the surface.

ExplanationBayesian Optimization doesn't just chase the candidate with the best predicted mean — it scores every candidate with an acquisition function that also rewards uncertainty, since testing a poorly-understood region can uncover an even better hyperparameter than anything seen so far. Computing UCB = μ + 2σ for each candidate: Candidate A gives 0.82 + 2(0.03) = 0.88, Candidate B gives 0.78 + 2(0.08) = 0.94, and Candidate C gives 0.85 + 2(0.01) = 0.87. Even though Candidate C has the best predicted accuracy on its own, the surrogate model is far less certain about Candidate B (σ = 0.08 versus 0.01 for C), and that large uncertainty earns it a bigger exploration bonus — enough to push its UCB score to 0.94, the highest of the three. So Bayesian Optimization selects Candidate B next: not because it currently looks best, but because evaluating it does the most to reduce uncertainty in a region that might be hiding a superior learning rate. This is exactly what separates Bayesian Optimization from a purely greedy search — it deliberately spends some trials exploring high-uncertainty regions rather than always exploiting the current best guess.

ExplanationWith 2,000 original admit-card digit images and 3 augmented copies made per original, Ridhima's pool grows to 2,000 + (2,000 × 3) = 8,000 images. Because augmentation happened before the split, when this pool is randomly divided 80/20 into 6,400 training and 1,600 test images, near-identical siblings of the same source photo — one lightly rotated, one zoomed, one brightness-shifted — can land on opposite sides of the split. The test set then contains images the model has effectively already seen in a slightly transformed form, which inflates the reported 99.2% accuracy without measuring true generalization to unseen admit cards. A ±15° rotation is far too small to turn a 6 into a 9 (that needs a rotation close to 180°), so no labels were actually corrupted, and 8,000 images being "too small" doesn't explain why the test score itself came out so high — the split, not the dataset size or ratio, is the culprit. The best-practice fix is to split the original 2,000 images into train and test first, and only then augment the training portion, leaving the test set entirely free of near-duplicates so it reflects real-world performance.

ExplanationFederated learning's core idea is that raw data never leaves each device or organization — only model updates travel to the server — and FedAvg (Federated Averaging) combines those updates in proportion to how much data produced them, not by treating every contributor equally. Here Bank A contributed 4,000 transactions, Bank B contributed 1,000, and Bank C contributed 5,000, for a total of 10,000 transactions across the federation. Each bank's local weight is multiplied by its own transaction count: Bank A contributes 4,000 x 0.60 = 2,400, Bank B contributes 1,000 x 0.90 = 900, and Bank C contributes 5,000 x 0.50 = 2,500. Adding these gives 2,400 + 900 + 2,500 = 5,800, and dividing by the total of 10,000 transactions gives the global weight: 5,800 / 10,000 = 0.58. Treating all three banks equally — a plain average of 0.60, 0.90, and 0.50 — would give 0.67 and would let Bank B's tiny 1,000-transaction sample distort the global model just as much as Bank C's far larger 5,000-transaction sample, which is the opposite of what data-proportional aggregation is supposed to prevent. Letting the largest bank's update stand in for the whole federation (0.50) throws away the genuine signal Banks A and B contributed, defeating the purpose of collaborating at all. Picking the middle value (0.60) simply ignores how large each dataset actually was. FedAvg's data-proportional weighting is precisely what lets many small, privacy-protected contributors combine into one accurate model without any of them ever pooling their raw transaction records.

ExplanationMLflow's search_runs(order_by=...) treats a column name with no direction as ascending — passing ["metrics.accuracy"] behaves exactly like ["metrics.accuracy ASC"]. To get results ranked from best to worst, the direction must be spelled out explicitly, as in order_by=["metrics.accuracy DESC"]. The three logged accuracies are 0.82, 0.91, and 0.88; sorted ascending that becomes 0.82, 0.88, 0.91, so .iloc[0] grabs the first row in that order — the run with lr=0.1 and accuracy 0.82, which is actually the WORST of the three models, not the best. Because an explicit order_by list was supplied, MLflow honors it rather than falling back to its default start_time-descending sort, so the "most recent run" explanation doesn't apply either. The for loop also opens a fresh mlflow.start_run() context on every iteration, so logging the parameter key "lr" three times causes no conflict — parameters are scoped to their own run, not shared across the whole experiment — so the code runs cleanly and prints 0.82. This ascending-by-default behavior is one of the most common real-world MLflow mistakes: developers assume "sorting by a metric" naturally means best-first, when DESC always has to be stated to get that.