Grade 11 AI & Computer Science Practice Questions — Set 10

ExplanationThe loss L(w) = 2w² − 8w + 3 is a quadratic in the single weight w, so by the power rule L'(w) = 4w − 8 — the coefficient 2 on w² doubles under differentiation, and the derivative of the constant 3 is zero, since a vertical shift of the parabola never affects its slope. Starting at w₀ = 5, gradient descent first computes L'(5) = 4(5) − 8 = 12, giving w₁ = w₀ − η·L'(w₀) = 5 − 0.1(12) = 5 − 1.2 = 3.8. Repeating the update from w₁ = 3.8: L'(3.8) = 4(3.8) − 8 = 15.2 − 8 = 7.2, so w₂ = 3.8 − 0.1(7.2) = 3.8 − 0.72 = 3.08. Each step pulls w toward the minimum of the parabola, located where L'(w) = 0, i.e. w* = 2 — the sequence 5 → 3.8 → 3.08 is steadily closing in on 2, exactly as expected on a convex quadratic. This steady convergence is not automatic: since L''(w) = 4 measures the curvature, gradient descent on this loss only converges for η < 2/L'' = 0.5. Because η = 0.1 satisfies that bound, each step shrinks the distance to w* = 2 rather than overshooting or diverging, which is why the weight lands at 3.08 rather than oscillating away from the minimum.

ExplanationThe Kullback-Leibler divergence D_KL(P‖Q) = Σ p_i log₂(p_i/q_i) measures the expected number of extra bits needed when outcomes generated by the true distribution P are encoded using a code optimized for Q instead. It is not a distance metric — it is asymmetric in general (D_KL(P‖Q) ≠ D_KL(Q‖P)) and requires Q to assign nonzero probability everywhere P does. Here P = (1/2, 1/4, 1/4) for (Success, Pending, Failed) and Q = (1/4, 1/4, 1/2). Computing term by term: - Success: (1/2)·log₂(0.5/0.25) = (1/2)·log₂2 = (1/2)(1) = 0.5 - Pending: (1/4)·log₂(0.25/0.25) = (1/4)·log₂1 = (1/4)(0) = 0 - Failed: (1/4)·log₂(0.25/0.5) = (1/4)·log₂0.5 = (1/4)(−1) = −0.25 Summing gives D_KL(P‖Q) = 0.5 + 0 − 0.25 = 0.25 bits. This positive value holds even though P and Q share the same entropy: H(P) = H(Q) = 1.5 bits, since Q is just P's probability values relabelled across categories (a permutation). Equal entropy only means the two distributions carry the same average uncertainty about their own outcomes — it says nothing about how well one distribution predicts data actually drawn from the other, which is exactly what KL divergence quantifies. A monitoring model can look "correct" by entropy alone while still assigning probability mass to the wrong categories, and that mismatch is what costs real bits (and real risk) once the model is used to encode or forecast actual transaction outcomes. The 1.75-bit figure comes from computing cross-entropy H(P,Q) = −Σ p_i log₂q_i instead of the log-ratio KL term; cross-entropy equals H(P) + D_KL(P‖Q) = 1.5 + 0.25 = 1.75, so it is a related but distinct quantity, not the divergence itself. The −0.25-bit figure comes from inverting the ratio inside the logarithm (using q_i/p_i instead of p_i/q_i), which flips the sign of every term. By Gibbs' inequality — a direct consequence of Jensen's inequality applied to the concave log function — KL divergence is always ≥ 0, so a negative result is a reliable signal that the ratio was inverted.

ExplanationThe ELBO that a VAE maximizes is E_q[log p(x|z)] − KL(q(z|x) ‖ p(z)), so computing this KL term correctly is central to understanding what the loss actually penalizes. For two univariate Gaussians q = N(μ₁, σ₁²) and p = N(μ₂, σ₂²), the KL divergence has the closed form ``` KL(q‖p) = ln(σ₂/σ₁) + (σ₁² + (μ₁ − μ₂)²) / (2σ₂²) − 1/2 ``` Specializing to the VAE prior p(z) = N(0, 1), so μ₂ = 0 and σ₂² = 1, this collapses to ``` KL(q‖p) = 0.5 · (σ₁² + μ₁² − 1 − log σ₁²) ``` which is exactly the per-dimension KL term used in the standard VAE loss (Kingma & Welling, 2013), since ln(σ₁) = 0.5·log(σ₁²). Here the encoder outputs μ = 3 and log(σ²) = 0, so σ² = e⁰ = 1. Substituting: ``` KL = 0.5 · (σ² + μ² − 1 − log σ²) = 0.5 · (1 + 9 − 1 − 0) = 0.5 · 9 = 4.5 nats ``` So the correct value is 4.5 nats. The distractors correspond to genuine derivation slips students make with this formula. 9.0 nats comes from computing (σ² + μ² − 1 − log σ²) = 9 correctly but forgetting the leading factor of 0.5 that comes from the −1/2 constant in the general two-Gaussian KL formula. 5.0 nats comes from dropping the "−1" term inside the parentheses — a natural mistake since it's easy to forget the KL divergence isn't just a sum of second moments but includes a constant correction that makes KL(q‖p) = 0 exactly when q equals the prior N(0,1). 1.5 nats results from using μ instead of μ² in the formula — substituting the mean directly rather than squaring it, giving 0.5·(1 + 3 − 1 − 0) = 1.5, which forgets that KL divergence penalizes squared distance from the prior mean, not linear distance (this matters because it changes how strongly the loss penalizes an encoder that pushes posteriors far from the origin).

ExplanationDifferentiating the cell-state recurrence c_t = f_t ⊙ c_{t-1} + i_t ⊙ g_t with respect to c_{t-1} — restricting attention to the direct path, since the gates' dependence on h_{t-1} was explicitly set aside — gives ∂c_t/∂c_{t-1} = f_t. The forget gate literally is the local derivative, with no squashing nonlinearity sitting between c_{t-1} and c_t. Chaining this identity across 20 identical steps multiplies twenty copies of 0.9: 0.9^20 ≈ 0.122, so about 12% of the original gradient survives after 20 timesteps. Compare this to a vanilla RNN's recurrence h_t = tanh(Wh_{t-1} + Ux_t), whose local derivative is diag(tanh′(z_t))·W. Once a unit is even mildly saturated, tanh′(z_t) drops well below 1; compounding a typical combined per-step factor of 0.3 over the same 20 steps gives 0.3^20 ≈ 3.5×10⁻¹¹ — effectively zero in floating point, let alone over the hundreds of steps real sequences require. The LSTM's advantage is not that its gradient never shrinks (0.9^20 is still meaningful decay, not identity), but that the decay rate is a learned quantity bounded only by how close training drives f_t toward 1, rather than being clamped below 1 by a fixed saturating nonlinearity applied at every single step. A GRU has the same algebraic structure in its update-gate recurrence h_t = z_t ⊙ h_{t-1} + (1 − z_t) ⊙ h̃_t, which is why it inherits the same resistance to vanishing gradients. Passing c_t through an extra tanh at every step, treating the additive update as a summed (rather than multiplied) gradient across time, and assuming a perfect constant error carousel regardless of the forget gate's actual value are all specific, common misreadings of this mechanism.

ExplanationTreat each fingerprint as a set of "on" bit positions: P = {1, 2, 3, 5, 7, 9} and Q = {2, 3, 5, 6, 7, 8}, each with |P| = |Q| = 6. Checking each element of P against Q: 1 ∉ Q, 2 ∈ Q, 3 ∈ Q, 5 ∈ Q, 7 ∈ Q, 9 ∉ Q. So the shared fragments are P ∩ Q = {2, 3, 5, 7}, giving |P ∩ Q| = 4. The union collects every fragment present in at least one molecule: P ∪ Q = {1, 2, 3, 5, 6, 7, 8, 9}, so |P ∪ Q| = 8. This matches the inclusion–exclusion identity |P ∪ Q| = |P| + |Q| − |P ∩ Q| = 6 + 6 − 4 = 8, since the four shared fragments would otherwise be double-counted. Therefore T(P, Q) = |P ∩ Q| / |P ∪ Q| = 4/8 = 0.50. This distinction matters in practice: Tanimoto similarity is the industry-standard metric in cheminformatics precisely because it normalizes by the union (fragments present in *either* molecule), making it robust to molecules of very different total fragment counts — unlike the Sørensen–Dice coefficient (2|P ∩ Q|/(|P|+|Q|) = 8/12 ≈ 0.67), which normalizes by the average size of the two sets instead and is a different, though related, similarity measure sometimes confused with it. Dividing by |P|+|Q| without ever forming the union (4/12 ≈ 0.33) undercounts similarity by penalizing overlap twice, and assuming full containment of one fingerprint in the other (6/8 = 0.75) overstates similarity by miscounting the intersection itself.

ExplanationSoftmax is shift-invariant: softmax(x)_j = exp(x_j − c) / Σ_k exp(x_k − c) for any constant c. This is exactly what lets attention be computed block-by-block instead of all at once — each block can pick its own convenient reference constant (its local max, for numerical stability) and the results can later be reconciled onto a common reference. That reconciliation is the log-sum-exp merge rule: given two blocks with local maxima m1, m2 and local unnormalized sums l1, l2, the true global max is m = max(m1, m2), and the merged sum must move every prior partial sum onto that new reference: l = l1·e^(m1−m) + l2·e^(m2−m). Ring Attention performs precisely this update every time a K/V block completes one hop around the ring, which is what lets a device hold only one block of K/V at a time (linear memory per device) while still producing output numerically identical to full, materialized attention. Plugging in the given values: m1 = 2, l1 = 3, m2 = 5, l2 = 4, so the merged max is m = max(2, 5) = 5. Block 1's sum must be rescaled to this new reference: 3·e^(2−5) = 3·e^(−3) ≈ 3 × 0.0498 ≈ 0.149. Block 2's local max already equals the new global max, so its term needs no rescaling: 4·e^(5−5) = 4·e^0 = 4. Adding these gives l ≈ 0.149 + 4 = 4.149 ≈ 4.15. The three wrong values each correspond to a genuine implementation bug in this merge step: adding l1 and l2 directly (7) ignores that the two blocks used different reference constants and are therefore not yet comparable; freezing the running max at the first block's value (83.34) fails to track the true row-wise maximum as larger scores arrive later in the ring rotation, which also risks numerical overflow in the un-rescaled term; and rescaling block 1's sum by e^(5−2) instead of e^(2−5) (64.26) flips the sign of the correction, inflating rather than shrinking the older block's contribution. Getting this recurrence exactly right — not approximately right — is what makes Ring Attention mathematically equivalent to standard full attention rather than an approximation.

ExplanationA bitmap index's size scales with two independent factors — the number of fact-table rows AND the number of distinct values in the indexed column — because a separate bit-vector is stored per distinct value, and each vector must be as long as the table itself. With cardinality 4 and 80,000,000 rows, total bits needed = 4 × 80,000,000 = 320,000,000 bits. Packing 8 bits per byte with no padding: 320,000,000 ÷ 8 = 40,000,000 bytes. Converting to binary MB (2^20 = 1,048,576 bytes per MB): 40,000,000 ÷ 1,048,576 ≈ 38.1469 MB, which rounds to 38.15 MB. This is exactly why bitmap indexes are the standard choice in star-schema data warehouses for low-cardinality dimension columns like payment mode, gender, or a boolean flag, but a poor choice for high-cardinality columns like customer_id: storage grows linearly with the number of distinct values, so a 4-valued column costs only about 4 times a single full-table bit-vector, and in return the warehouse gets extremely fast bitwise AND/OR/XOR operations for combining filters across multiple dimensions — something a B-tree index cannot match on columns with few repeating values.

ExplanationFor each class, TP is the diagonal entry, FN is (row total − TP), and FP is (column total − TP), since the row total holds every ground-truth pixel of that class and the column total holds every pixel the model predicted as that class. Background: TP=50, row total=55, column total=55, so FN=55−50=5 and FP=55−50=5. IoU = 50/(50+5+5) = 50/60 = 0.833. Building: TP=20, row total=25, column total=25, so FN=5 and FP=5. IoU = 20/(20+5+5) = 20/30 = 0.667. Road: TP=17, row total=20, column total=20, so FN=3 and FP=3. IoU = 17/(17+3+3) = 17/23 = 0.739. mIoU is the macro-average of these three ratios: (0.833 + 0.667 + 0.739)/3 = 2.239/3 ≈ 0.746. Pixel accuracy — (50+20+17)/100 = 87/100 = 0.870 — counts every correct pixel equally, so it is dominated by whichever class has the most pixels (here, Background). A model can score high on pixel accuracy while performing poorly on smaller classes like Road, which is exactly why mIoU is preferred: it forces every class, however rare, to contribute equally to the score. Dropping Background from the average (giving 0.703) is a common error when students assume "background doesn't count," but the standard mIoU definition includes every class present in the label set unless a task explicitly states otherwise. Pooling TP, FP, and FN globally before dividing (87/113 ≈ 0.770) computes a pixel-weighted "micro" IoU instead of the class-balanced "macro" average that mIoU is defined to be — it silently lets the largest class dominate again, defeating the entire purpose of using IoU over pixel accuracy in the first place.

ExplanationThe expected count follows directly from the model's training-frequency approximation: 5,000 × (900⁄500,000) = 5,000 × 0.0018 = 9 expected outputs in an Indian traditional style. Comparing this training-set frequency (0.18%) to India's share of world population (17.8%) gives a ratio of 17.8⁄0.18 ≈ 99, meaning the model would portray these traditions at a rate roughly 99 times lower than population-proportional representation would suggest — a measurable, quantifiable bias baked into the training corpus itself rather than into any individual prompt. On ownership: copyright law protects a specific original expression — a particular painting, photograph, or drawing — created by an identifiable author, not a style, technique, or genre; this is the same principle that means no one holds copyright over "Impressionism" or "oil painting" as such. Madhubani, Warli, and Pattachitra are centuries-old community traditions passed across generations of artists, so the traditions themselves carry no single copyright holder that a model could be said to have infringed simply by learning the style. The underrepresentation the class measured is therefore correctly diagnosed as a bias/erasure problem — a skewed training corpus causing entire cultural traditions to nearly vanish from unprompted outputs — and is a separate legal question from copyright infringement, which would instead depend on whether specific copyrighted images were used without a license, not on how frequently a style appears in outputs.

ExplanationModel each coordinate q_i and k_i as independent, mean-zero, unit-variance random variables, with q and k also independent of each other. For one coordinate, Var(q_i k_i) = E[q_i²k_i²] − (E[q_i k_i])² = E[q_i²]·E[k_i²] − 0 = 1·1 = 1, using independence and the fact that E[x²] = Var(x) when the mean is zero. The 64 coordinate products q_i k_i are themselves independent, so the variance of the sum q·k = Σ_{i=1}^{64} q_i k_i equals the sum of the 64 individual variances: Var(q·k) = 64 × 1 = 64, giving standard deviation √64 = 8. Dividing a random variable by a constant c scales its variance by 1/c², so dividing q·k by c = 8 gives Var(q·k/8) = 64/8² = 1 — exactly unit variance. Since 8 = √64 = √d_k, this is exactly the paper's 1/√d_k scaling, and it depends only on the per-head dimension d_k, not on d_model = 512. Dividing by d_k = 64 instead (rather than √d_k) would shrink the variance to 64/64² = 1/64, over-correcting and flattening the softmax rather than stabilizing it. This is precisely why the √d_k divisor matters in practice: without it, as d_k grows, dot-product scores grow in magnitude, pushing the softmax into saturated regions with near-zero gradients and making the network much harder to train.

ExplanationBecause all embeddings are unit vectors, cosine similarity is just the dot product. sim(z_a, z_p) = (1)(0.5) + (0)(√3/2) = 0.5. sim(z_a, z_n1) = (1)(0) + (0)(1) = 0. sim(z_a, z_n2) = (1)(−1) + (0)(0) = −1. The InfoNCE logits are these similarities scaled by 1/τ, with τ = 0.5, i.e. multiplied by 2: the positive logit is 0.5/0.5 = 1.0, the first negative logit is 0/0.5 = 0.0, and the second negative logit is −1/0.5 = −2.0. Temperature scaling sharpens the softmax — dividing by a small τ spreads the logits further apart before the exponential, which is exactly what makes contrastive training push hard negatives away more forcefully. Exponentiating: e^1.0 = 2.71828, e^0.0 = 1.00000, e^−2.0 = 0.13534. These sum to 3.85362, and the positive key's share of that sum is 2.71828 / 3.85362 = 0.70539. The loss is the negative natural log of this softmax probability: L_i = −ln(0.70539) ≈ 0.349 nats. A value this close to zero signals the encoder already ranks the true augmented pair well above the negatives, since −ln(1) = 0 would be the loss for a perfect match. The distractors reproduce specific, common implementation slips. Skipping the division by τ entirely (using the raw similarities 0.5, 0, −1 as logits) understates how peaked the distribution should be and gives ≈0.604 nats. Multiplying by τ instead of dividing by it does the opposite — it flattens the logits to 0.25, 0, −0.5 — and gives ≈0.812 nats, a much larger loss than the model actually has. Dividing by τ correctly but then evaluating the loss with log base 2 instead of natural log (a mix-up with information-theoretic bits) rescales the correct softmax probability's loss by 1/ln(2), giving ≈0.504 nats — numerically plausible but inconsistent with how the InfoNCE loss (and its cross-entropy form) is defined using natural log.

ExplanationAdaIN is computed per channel, per instance: given a channel's spatial activations, compute the instance mean μ and instance standard deviation σ (population statistics, dividing by N), normalize each activation as (x − μ)/σ, then apply the style-specific scale and bias: AdaIN(x) = y_s · (x − μ)/σ + y_b. For the channel values 1, 1, 5, 5, the mean is μ = 3 and the variance is (4+4+4+4)/4 = 4, so σ = 2. For the activation x = 1, the normalized value is (1 − 3)/2 = −1, and applying the given style parameters gives 1.5 × (−1) + (−0.5) = −2.0. This matters for style transfer because normalization discards the channel's original mean and variance — the "content" statistics inherited from the previous layer — before the style parameters derived from w reintroduce a fresh mean and variance. Because every synthesis block re-injects w this way, swapping in different w vectors at different resolution levels (style mixing) genuinely replaces coarse features like pose and face shape at low-resolution blocks and fine features like color and texture at high-resolution blocks, rather than producing a blend of two contents.

ExplanationEnrichment factor compares how concentrated true binders are in the model's top-ranked subset versus what plain random screening would give. First compute the two hit rates separately. The library-wide (random) hit rate is total hits divided by total molecules: 200/10,000 = 0.02, i.e. 2%. The top-decile hit rate is hits found in that subset divided by the subset's size: 100/1,000 = 0.10, i.e. 10%. The enrichment factor is the ratio of the selected hit rate to the baseline hit rate: EF(10%) = 0.10 / 0.02 = 5. This says the AI model's top 10% of predictions is five times richer in true EGFR binders than picking 1,000 molecules at random — exactly the kind of prioritization gain that lets a pharma lab test far fewer compounds experimentally while still finding most of the actives, which is the whole economic case for AI-driven virtual screening. The 10 value mistakes the raw top-decile hit-rate percentage (10%) for the enrichment factor itself, forgetting that enrichment is measured relative to the random baseline, not in isolation — a 10% hit rate is only impressive if random screening does much worse than 10%, which is exactly what dividing by the baseline captures. The 0.2 value inverts the ratio, computing baseline-over-selected instead of selected-over-baseline; that inverted quantity would only fall below 1 when the model performs worse than random, which contradicts the model clearly concentrating actives near the top. The 0.5 value is a real, useful number — it is the recall (fraction of all 200 true binders captured in the top decile, 100/200) — but recall answers "how much of the total treasure did we find," while enrichment factor answers "how much better than chance is our search," and the question specifically asks for the latter.

ExplanationThe one-step actor-critic algorithm combines TD(0) value learning (the critic) with policy-gradient updates (the actor) using the critic's TD error as a low-variance estimate of the advantage function A(s_t,a_t) = Q(s_t,a_t) − V(s_t). Step 1 — compute the TD error: δ_t = r_t + γV(s_{t+1}) − V(s_t) = 4 + 0.9 × 13 − 10 = 4 + 11.7 − 10 = 5.7. Step 2 — interpret the sign: δ_t is a sample estimate of how much better (or worse) the return actually received was compared to the critic's expectation V(s_t) at the moment action a_t was chosen. δ_t = 5.7 > 0 means the fare-raising action led to more reward-to-go than the critic predicted, so a_t was better than average for that state. Step 3 — apply the update rules: the critic moves its estimate toward the bootstrapped target, V(s_t) ← V(s_t) + α_w δ_t, while the actor performs gradient ascent on expected return using δ_t in place of the true (unknown) advantage: θ ← θ + α_θ δ_t ∇_θ ln π(a_t|s_t;θ). Because δ_t is positive, this pushes θ in the direction that raises the log-probability of a_t in state s_t — the actor becomes more likely to raise fares again in similar high-demand states. The critic's role as a subtracted baseline matters here: because E[δ_t | s_t] equals the true advantage under the current policy, using δ_t rather than the raw bootstrapped return r_t + γV(s_{t+1}) keeps the policy-gradient estimate unbiased while sharply reducing its variance compared to plain REINFORCE. The three incorrect statements each embed a specific, common actor-critic error. One drops the discount factor before bootstrapping off V(s_{t+1}), turning 5.7 into an incorrect 7 and inventing a nonexistent 'actor-only, undiscounted' rule — γ discounts every bootstrapped estimate the critic produces, and the actor consumes that same δ_t unchanged. Another computes δ_t correctly as 5.7 but then reasons that a positive TD error should shrink the action's probability, inverting the entire gradient-ascent direction: a positive δ_t always means 'do more of this,' not 'let the critic quietly absorb the credit.' The last one flips the sign of the TD-error formula itself, computing V(s_t) − r_t − γV(s_{t+1}) instead of r_t + γV(s_{t+1}) − V(s_t), which lands on −5.7 and decreases the action's probability — the right-looking direction reached through the wrong formula and the wrong numeric error.

ExplanationTrace SRTF minute by minute, always comparing the *remaining* time of the running process against every newly arrived job's full burst. ``` t=0: only P1 present (rem 8) -> P1 runs t=1: P2 arrives (burst 4). Running P1 has rem 7. 4 < 7 -> preempt, run P2. P1's rem stays 7 (it only executed 1 ms). t=2: P3 arrives (burst 9). P2 has rem 3 (ran 1 ms of its 4). 9 > 3 -> P2 keeps running. t=3: P4 arrives (burst 5). P2 has rem 2. 5 > 2 -> P2 keeps running. t=4: P2 has rem 1, no new arrivals -> P2 keeps running. t=5: P2 completes (ran 1-5, all 4 ms). Candidates: P1 rem 7, P3 rem 9, P4 rem 5. Smallest is P4 -> run P4. t=5-10: P4 runs uninterrupted (no new arrivals; its remainder 5->0 stays below P1's 7 and P3's 9 throughout) -> P4 completes at t=10. t=10: Candidates: P1 rem 7, P3 rem 9. P1 smaller -> run P1. t=10-17: P1 runs its remaining 7 ms uninterrupted -> completes at t=17. t=17-26: only P3 left (rem 9) -> runs uninterrupted -> completes at t=26. ``` Completion times: P2=5, P4=10, P1=17, P3=26. Waiting time = (Completion − Arrival) − Burst for each process: - P1: (17−0)−8 = 9 ms - P2: (5−1)−4 = 0 ms - P3: (26−2)−9 = 15 ms - P4: (10−3)−5 = 2 ms Average waiting time = (9+0+15+2)/4 = 26/4 = **6.50 ms**. This trace is the classic illustration of SRTF's core trade-off: P2 and P4 (the short jobs) finish almost immediately after arriving, but P3 — unlucky enough to be the longest job and to arrive while shorter jobs keep cutting in line — waits 15 ms before it ever touches the CPU. SRTF minimizes average waiting time among all scheduling policies for a fixed arrival/burst sequence, but it does so by risking starvation of long jobs and by paying a preemption (context-switch) cost that this idealized trace ignores. The 7.75 ms option comes from dropping preemption (non-preemptive SJF only picks a new job when the CPU frees up, so P2 would have to wait until t=8 instead of jumping in at t=1); the 8.75 ms option comes from ignoring burst length altogether and running strict FCFS; and the 13.00 ms option is the average *turnaround* time for this same correct SRTF trace — a common bookkeeping slip since turnaround and waiting time differ by exactly the burst time of each process.

ExplanationFor a diagonal-covariance Gaussian posterior, the KL divergence to the standard normal prior decomposes into an independent term per latent dimension, so each dimension can be evaluated separately before summing. Dimension 1 has μ₁ = 0 and log σ₁² = 0, so σ₁² = e⁰ = 1. Substituting into the per-dimension term: σ₁² + μ₁² − 1 − log σ₁² = 1 + 0 − 1 − 0 = 0. This dimension's posterior is already N(0,1), identical to the prior, so it correctly contributes zero divergence — a well-behaved dimension carries no information cost. Dimension 2 has μ₂ = 1 and log σ₂² = 1, so σ₂² = e¹ = e ≈ 2.71828. Substituting: σ₂² + μ₂² − 1 − log σ₂² = e + 1 − 1 − 1 = e − 1 ≈ 1.71828. Summing the two per-dimension terms gives 0 + (e − 1) = e − 1, and halving per the formula gives KL = (e − 1)/2 ≈ 0.859 nats — the value this encoder output contributes to the loss. The ≈1.859 nats answer comes from dropping the '−1' inside each per-dimension term before halving, silently removing the penalty that keeps this divergence from exploding as latent dimensionality grows — an easy transcription slip when implementing the formula by hand. The ≈4.5 nats answer comes from decoding log σ² with base-10 exponentiation instead of the natural exponential that the Gaussian's own definition (and frameworks like PyTorch/TensorFlow) require, wildly overestimating each σᵢ². The ≈−0.5 nats answer comes from forgetting that the encoder head outputs log-variance rather than variance itself, and plugging the raw log σ² values in as σ² directly — a genuine and common implementation bug, whose telltale sign is that it yields a negative number, something a true divergence between two probability distributions can never actually produce.

ExplanationFlask-SQLAlchemy's db.relationship() defaults to lazy='select' unless told otherwise, and lazy=True is exactly that setting. Under lazy='select', a relationship attribute is populated by its own SELECT statement the first time it is touched on a given instance — it is not fetched alongside the parent object in the original query. So Post.query.all() issues exactly one SELECT that returns all 8 Post rows in a single round trip. The for loop then walks those 8 Post instances; the first time each instance's .comments attribute is read (inside len(...)), SQLAlchemy fires a fresh SELECT * FROM comment WHERE post_id = ? scoped to that instance. Because there are 8 distinct posts, that happens 8 separate times. Adding the initial post query gives 1 + 8 = 9 total queries — the textbook N+1 problem, where N is the number of parent rows returned by the first query. Collapsing this would require an eager-loading strategy: lazy='joined' (or Post.query.options(joinedload(Post.comments)).all()) folds everything into a single JOIN, while lazy='selectin' issues exactly one extra batched query covering every post's comments at once. len() itself does no database work beyond triggering the relationship's first access — it reads a Python list once the relationship has resolved into memory, so it never issues a separate counting query, and the default strategy performs no automatic JOIN rewriting on its own.

ExplanationThe message must fully arrive at the server before store-and-forward relaying can begin: this upload leg takes L/R_A + d_A = (4000 bits)/(2×10⁶ bps) + 20 ms = 2 ms + 20 ms = 22 ms. From that instant, the server pushes the 5 outgoing copies onto its single interface one after another (it cannot send them all at once, since they share one physical link). Each copy takes L/R_S = (4000 bits)/(1×10⁶ bps) = 4 ms of transmission time, so the fifth and final copy finishes leaving the server at 22 ms + 5×4 ms = 42 ms. That last copy then travels its own link for d_S = 10 ms, reaching the fifth student at 42 ms + 10 ms = 52 ms. The other four students actually receive their copies earlier — at 36 ms, 40 ms, 44 ms, and 48 ms respectively — because their transmission slots on the server's interface come before the fifth one; only the last recipient determines the overall delivery time. Note that 36 ms is exactly when the FIRST student receives the message (or the time all students would receive it under the mistaken assumption that the server can transmit all 5 copies at once), 92 ms comes from wrongly stacking a propagation delay for every relayed copy instead of only the last, and 30 ms comes from forgetting that the server must fully receive Aisha's message before it can relay anything at all.

ExplanationSince Solidity 0.8.0, the compiler automatically inserts overflow and underflow checks into every arithmetic operation, so subtracting 8 from a balance of 5 does not silently wrap around to a huge number the way it could in older compiler versions, and Solidity has no built-in behavior that clamps an underflowing result at zero either. Instead, the check immediately triggers a Panic error and halts execution at that exact line. Because blockchain transactions are atomic, an EVM revert undoes every state change attempted during that call, so the recipient's balance never actually increases even though its update comes after the failing subtraction in the code, meaning nothing is left permanently reduced. Both balances end up exactly as they were before the call was ever sent. What does not get reversed is the gas already spent computing up to the revert point, which is consumed permanently, a key reason sending more than you have still costs the sender something even though the transfer itself never happens.

ExplanationA composite B-tree index defined as (customer_id, order_date) stores its entries sorted primarily by customer_id, and only within each customer_id group are entries further sorted by order_date. Filtering on customer_id = 501 lets the database seek directly to that one contiguous block of index entries, and because those entries are already arranged by order_date inside the block, the ORDER BY is satisfied for free, with no separate sorting step required. Filtering on order_date alone cannot use the same kind of seek, because rows sharing a given date are scattered across many different customer_id groups instead of sitting together in the index. Filtering on amount gets no benefit at all, since that column was never part of the index definition. Ordering by order_date alone, without first narrowing to one customer_id, also fails to produce a globally sorted result, because order_date is sorted only locally within each customer_id group rather than across the whole index; for instance, a later order placed by a customer with a small customer_id sits earlier in the index than an earlier order placed by a customer with a large customer_id, since customer_id is the primary sort key. This is why the column order chosen when a composite index is created determines exactly which query patterns can actually take advantage of it.