A classifier has K = 4 output classes, and label smoothing is applied with ε = 0.2, so each smoothed label is y_smooth = (1 − ε)·y_onehot + ε·u, where u is the uniform distribution over the K classes (u_i = 1/K for every i). This means the label-smoothed cross-entropy loss L = −Σ y_smooth,i·ln(p_i) can always be rewritten as L = (1 − ε)·CE_onehot + ε·CE_uniform, where CE_onehot is the ordinary cross-entropy against the one-hot label and CE_uniform is the cross-entropy against the uniform distribution, both evaluated on the same predicted distribution p. For a particular training example, CE_onehot = 0.40 nats and CE_uniform = 1.20 nats. What is the label-smoothed cross-entropy loss L for this example?
0.80 nats, since the label-smoothed loss is the plain unweighted average of the one-hot and uniform cross-entropy terms
1.60 nats, since the label-smoothed loss is the direct sum of the one-hot and uniform cross-entropy terms with no reweighting applied
0.56 nats, since (1 − ε) = 0.8 weights the one-hot cross-entropy term and ε = 0.2 weights the uniform cross-entropy term
1.04 nats, since ε = 0.2 weights the one-hot cross-entropy term and (1 − ε) = 0.8 weights the uniform cross-entropy term
Answer: C. 0.56 nats, since (1 − ε) = 0.8 weights the one-hot cross-entropy term and ε = 0.2 weights the uniform cross-entropy term
ExplanationLabel smoothing replaces the one-hot target with y_smooth = (1 − ε)·y_onehot + ε·u. Since u_i = 1/K for every class, this is exactly the familiar elementwise rule "correct class gets 1 − ε + ε/K, every other class gets ε/K" restated in vector form. Substituting y_smooth into the cross-entropy sum and splitting it linearly into two sums gives L = −Σ[(1 − ε)y_onehot,i + ε·u_i]·ln(p_i) = (1 − ε)·(−Σ y_onehot,i ln p_i) + ε·(−Σ u_i ln p_i) = (1 − ε)·CE_onehot + ε·CE_uniform. With ε = 0.2, so 1 − ε = 0.8, CE_onehot = 0.40, and CE_uniform = 1.20: L = 0.8 × 0.40 + 0.2 × 1.20 = 0.32 + 0.24 = 0.56 nats. The claim of 1.04 nats swaps the roles of the two weights, applying ε to the one-hot term and (1 − ε) to the uniform term — but the derivation shows (1 − ε) must multiply the one-hot term, since that term dominates when smoothing is weak. The claim of 0.80 nats treats the two cross-entropy terms as equally weighted, discarding the ε-dependence entirely; that would make the loss identical regardless of how strong the smoothing is, which contradicts the whole point of ε as a tunable smoothing strength. The claim of 1.60 nats sums the two terms with no reweighting at all, which fails the basic consistency check that setting ε = 0 must recover L = CE_onehot exactly — an unweighted sum never does that.
Question 82 · mixed precision training · hard
In a mixed-precision training step, a weight's true (full-precision) gradient is 4×10⁻⁸. FP16 can represent subnormal magnitudes only down to about 5.96×10⁻⁸ (2⁻²⁴), so this gradient would flush to zero if stored directly in FP16 during backpropagation. The training loop scales the loss by S = 2048 before running backward, then casts gradients to FP32 and divides by S before the optimizer step, which updates the FP32 master copy of the weights. What happens to this gradient value as it moves through the pipeline?
Scaling the loss by 2048 turns the gradient into 8.192×10⁻⁵ during backward, a value inside FP16's normal range, so it survives storage in FP16; after backward it is upcast to FP32, divided by 2048 to recover 4×10⁻⁸ exactly, and that unscaled value updates the FP32 master weights.
Because loss scaling multiplies the FP16 weights rather than the loss itself, the gradient is amplified to 8.192×10⁻⁵ automatically during the forward pass, removing any need to divide by 2048 again before the update.
The gradient of 4×10⁻⁸ already lies within FP16's representable subnormal range, so it would have been stored correctly even without loss scaling, meaning the scale factor of 2048 is applied only to speed up the matrix multiplications on tensor cores.
After the backward pass the scaled gradient of 8.192×10⁻⁵ is divided by 2048 while still in FP16 to recover 4×10⁻⁸, and this value then directly overwrites the FP16 copy of the weights used in the next forward pass.
Answer: A. Scaling the loss by 2048 turns the gradient into 8.192×10⁻⁵ during backward, a value inside FP16's normal range, so it survives storage in FP16; after backward it is upcast to FP32, divided by 2048 to recover 4×10⁻⁸ exactly, and that unscaled value updates the FP32 master weights.
ExplanationThe true gradient, 4×10⁻⁸, sits below FP16's smallest representable subnormal magnitude (2⁻²⁴ ≈ 5.96×10⁻⁸), so storing it directly in FP16 during backpropagation would flush it to zero — exactly the underflow loss scaling exists to prevent. Scaling the loss by S = 2048 before backward multiplies every gradient in the computation graph by the same factor via the chain rule, so this gradient becomes 4×10⁻⁸ × 2048 = 8.192×10⁻⁵, which is above FP16's smallest normal value (2⁻¹⁴ ≈ 6.10×10⁻⁵) and is stored without loss. Once backpropagation finishes, the gradients are cast up to FP32 and only then divided by 2048, recovering the true value of 4×10⁻⁸ in full precision; because this division happens in FP32, the tiny result is representable and is not flushed to zero the way it would be if the same division were performed in FP16, which is the flaw in dividing while still in half precision. That unscaled FP32 gradient is applied to the FP32 master copy of the weights — the authoritative weights that accumulate small updates precisely across many steps — and this master copy is then cast back down to FP16 for the next forward and backward pass. The claim that loss scaling multiplies the weights rather than the loss misstates the mechanism entirely, and the claim that 4×10⁻⁸ was already representable in FP16 without scaling ignores that it falls below the 5.96×10⁻⁸ subnormal floor.
Question 83 · ResNet skip connection · hard
A residual block computes output y = F(x) + x, where F is a small sub-network (conv-BN-ReLU-conv-BN). During backpropagation through one block, the chain rule gives dL/dx = dL/dy * (dF/dx + 1). Now stack 50 identical residual blocks sequentially, so the output of block i feeds directly into block i+1. At every block, the local derivative dF/dx equals 0.02, and the gradient entering the very last (50th) block from the loss is dL/dy = 1. Chaining this local gradient backward through all 50 blocks by repeated application of the chain rule, what is the resulting value of dL/dx at the input of the very first block?
The chained gradient equals (1.02)^50, which evaluates to approximately 2.69 -- a value greater than 1, confirming that the skip connections keep the gradient from vanishing even after 50 stacked layers.
Multiplying the local factor dF/dx (0.02) across all 50 blocks while dropping the identity term gives roughly 1.1 x 10^-85, the vanishing-gradient magnitude a plain feedforward stack without skip connections would produce instead.
Because the +1 term keeps the identity path intact at every block, dL/dx stays fixed at exactly 1.0 no matter how many blocks are chained, since the F branch's contribution cancels out identically at each layer.
The correct approach sums the fifty local factors of 1.02 rather than multiplying them, giving dL/dx = 50 x 1.02 = 51, since the chain rule is understood to accumulate gradients additively across stacked layers.
Answer: A. The chained gradient equals (1.02)^50, which evaluates to approximately 2.69 -- a value greater than 1, confirming that the skip connections keep the gradient from vanishing even after 50 stacked layers.
ExplanationEach residual block contributes a multiplicative factor of (dF/dx + 1) = (0.02 + 1) = 1.02 to the backward gradient, because the chain rule is applied once per block and the derivatives compose by multiplication, not addition. Chaining this factor through 50 identical blocks means the gradient at the first block's input is dL/dy times the product of all 50 local factors: 1 x (1.02)^50 ≈ 2.69. Since this value is greater than 1, it demonstrates precisely why the +1 identity term in a residual connection prevents vanishing gradients: even with a small F branch, the gradient signal is preserved and even amplified across depth, rather than shrinking toward zero. The claim that the gradient collapses to about 1.1 x 10^-85 describes what would happen in a plain network with no skip connections, where only the dF/dx = 0.02 factor propagates at each layer and the product of 50 tiny numbers underflows toward zero -- this is exactly the vanishing-gradient failure that residual connections are designed to avoid, so it does not describe this residual-block scenario. The claim that dL/dx stays fixed at exactly 1.0 misreads the role of the +1 term: it guarantees the gradient magnitude cannot fall below what the identity path alone would give, but the dF/dx contribution from every block still multiplies in and changes the value away from 1 as depth increases. The claim that the fifty factors should be summed rather than multiplied misapplies the chain rule, which composes derivatives across sequential layers by multiplication; summing would give 51, a number with no correspondence to how backpropagation actually accumulates gradient through stacked blocks.
Question 84 · LSTM gating mechanism · hard
A single-layer LSTM uses the standard formulation: for each of its four gates — forget, input, cell candidate, and output — the gate applies its own weight matrix to the concatenated vector [h_{t-1}, x_t] and adds its own bias vector before the sigma or tanh nonlinearity. For an LSTM layer with input_size = 64 and hidden_size = 128, how many trainable parameters does this single layer have?
The layer has 98,816 parameters: each of the four gates contributes hidden_size*(input_size+hidden_size) weights plus hidden_size bias values, giving 4*(128*192+128).
Omitting the bias vectors from the count gives 98,304, treating each gate's parameters as hidden_size*(input_size+hidden_size) weights only.
Counting only three trainable gates gives 74,112, since this view treats the cell candidate as parameter-free rather than as a fourth gate with its own weight matrix.
Restricting each gate's weight matrix to shape (hidden_size, hidden_size) gives 66,048, leaving out the input vector's contribution to the parameter count.
Answer: A. The layer has 98,816 parameters: each of the four gates contributes hidden_size*(input_size+hidden_size) weights plus hidden_size bias values, giving 4*(128*192+128).
ExplanationEach gate's weight matrix maps the concatenation [h_{t-1}, x_t], which has length input_size + hidden_size = 64 + 128 = 192, to a hidden_size = 128 output, so the matrix contributes 128*192 = 24,576 weights, and its bias vector adds another 128 values, for 24,704 parameters per gate. An LSTM cell has exactly four gates that each compute their own affine transformation of [h_{t-1}, x_t] in this way — forget, input, cell candidate, and output — so the total is 4*24,704 = 98,816. The claim that the total is 98,304 comes from dropping all four bias vectors (4*128 = 512) from the count, understating the true total by exactly that amount. The claim that the total is 74,112 treats the cell candidate's computation c_tilde = tanh(W_c*[h,x] + b_c) as needing no learned weights, but it has the identical matrix and bias shape as the other three gates, so leaving it out removes a full 24,704 parameters that genuinely exist. The claim that the total is 66,048 uses hidden_size*hidden_size = 128*128 = 16,384 per gate instead of hidden_size*(input_size+hidden_size) = 24,576, which would only hold if a gate ignored the input x_t entirely — but every LSTM gate is a function of both the previous hidden state and the current input, so the input_size term belongs in each weight matrix.
Question 85 · attention score computation · hard
Consider scaled dot-product attention Attention(Q,K,V) = softmax(QK^T / sqrt(d_k)) V computed for one attention head with batch size 2. Q has shape [2,3,4] (3 query positions, d_k=4), K has shape [2,5,4] (5 key positions, d_k=4), and V has shape [2,5,8] (5 key positions, d_v=8). Working through the computation: QK^T produces the raw score matrix, this is divided by sqrt(d_k), softmax is applied along the last axis, and the resulting attention weights are multiplied by V to produce the final output. What is the correct final output shape, and why is the sqrt(d_k) division applied at the scores stage rather than after softmax?
Scaled dot-product attention here yields output shape [2,3,8]; the sqrt(d_k) division is applied at the scores stage, before softmax, because unscaled dot-product variance grows with d_k, which would otherwise push softmax into a near one-hot distribution with vanishing gradients.
Because attention aggregates each output vector over the 5 key positions, the output shape is [2,5,8], inheriting K's sequence length rather than Q's.
The softmax-normalized attention-weight matrix has shape [2,3,5], and this weight matrix is itself the final output of scaled dot-product attention, since no further multiplication with V is needed once the weights sum to 1.
Although the final output shape is [2,3,8], the sqrt(d_k) division is applied after softmax, rescaling the normalized attention weights so their magnitude matches V before the weighted sum.
Answer: A. Scaled dot-product attention here yields output shape [2,3,8]; the sqrt(d_k) division is applied at the scores stage, before softmax, because unscaled dot-product variance grows with d_k, which would otherwise push softmax into a near one-hot distribution with vanishing gradients.
ExplanationMatrix multiplication in QK^T contracts over the shared d_k=4 dimension: Q's [2,3,4] against K transposed's [2,4,5] gives raw scores of shape [2,3,5] — 3 query positions each scored against 5 key positions. Dividing by sqrt(d_k) = sqrt(4) = 2 rescales these raw scores before softmax is applied along the last (key) axis, producing normalized attention weights of shape [2,3,5] that sum to 1 over the 5 key positions per query. Multiplying these weights [2,3,5] by V [2,5,8] contracts over the shared key-position dimension (5), leaving the final output shape [2,3,8] — one d_v=8-dimensional vector per query position, per batch element. The scaling by sqrt(d_k) must happen on the raw scores before softmax: if Q and K entries are independent with roughly unit variance, each dot product sums d_k such terms, so its variance grows proportionally to d_k (here, to 4). Without dividing by sqrt(d_k), larger d_k values push the pre-softmax logits to large magnitudes, and softmax then saturates into an almost one-hot output where most gradients are near zero, stalling learning. The claim that the output shape is [2,5,8] mistakes the output's sequence dimension for K's 5 key positions, when scaled dot-product attention actually produces exactly one output vector per query position (3), not per key position. The claim that the output shape is [2,3,5] confuses the intermediate softmax-normalized attention-weight matrix with the final output; those weights still need to be multiplied by V to aggregate value vectors, which changes the last dimension from 5 (key positions) to 8 (d_v). The claim that scaling happens after softmax reverses the actual order of operations: softmax is applied to already-scaled scores, not the other way around, and applying the division afterward would not address the variance problem that motivates scaling in the first place.
Question 86 · depthwise separable convolution · hard
A CNN layer maps 32 input channels to 64 output channels using a 3×3 kernel. A standard convolution here uses 64 × 3 × 3 × 32 = 18,432 parameters (bias omitted). An engineer replaces it with a depthwise separable convolution: a depthwise stage (one independent 3×3 filter per input channel) followed by a pointwise stage (a 1×1 convolution mapping the 32 channels to 64). What is the total parameter count of the depthwise separable convolution, and what is the resulting reduction factor relative to the standard convolution, rounded to the nearest whole number?
The depthwise stage contributes 32×3×3 = 288 parameters and the pointwise stage contributes 32×64 = 2048 parameters, for a total of 2336 parameters — roughly 7.9 times fewer than the standard convolution's 18,432 parameters, which rounds to an 8× reduction.
The pointwise stage should use a 3×3 kernel just like the depthwise stage, contributing 32×3×3×64 = 18,432 parameters on its own, so combined with the depthwise stage's 288 parameters the total of 18,720 exceeds the standard convolution's 18,432 parameters and defeats the purpose of using a separable convolution.
A single 3×3 spatial filter reused identically across all 32 channels would give the depthwise stage only 3×3 = 9 parameters, so the depthwise separable convolution's total would be 9 + 2048 = 2057 parameters instead of 2336.
The standard convolution requires only 64×3×3 = 576 parameters, since kernel size and output-channel count alone determine parameter count, which would make the depthwise separable convolution's 2336 parameters larger rather than smaller than the standard version.
Answer: A. The depthwise stage contributes 32×3×3 = 288 parameters and the pointwise stage contributes 32×64 = 2048 parameters, for a total of 2336 parameters — roughly 7.9 times fewer than the standard convolution's 18,432 parameters, which rounds to an 8× reduction.
ExplanationDepthwise separable convolution splits the work into two stages. The depthwise stage learns one independent 3×3 filter per input channel, so its parameter count is 32 × (3×3) = 288 — not a single filter shared across all channels, which is why treating it as one shared filter undercounts it as only 9 parameters (giving 2057 instead of the true 2336). The pointwise stage is a 1×1 convolution that mixes channels without any spatial extent, contributing 32 × 64 × (1×1) = 2048 parameters; if it were mistakenly given a 3×3 kernel instead, it alone would cost 32×3×3×64 = 18,432 parameters, pushing the combined total to 18,720 — more than the standard convolution, which defeats the entire point of factorizing the convolution. Adding the correct depthwise and pointwise counts gives 288 + 2048 = 2336 total parameters. The standard convolution being replaced needs 64 × 3 × 3 × 32 = 18,432 parameters — the input-channel count of 32 must be included, not just the kernel size and output-channel count, which is why treating it as only 576 parameters is wrong. Dividing 18,432 by 2336 gives approximately 7.89, which rounds to an 8× reduction in parameters.
Question 87 · label smoothing · hard
A 5-class classifier applies label smoothing with eps = 0.1 to a training example whose true class is index 2 (0-indexed): the smoothed target becomes y = [0.02, 0.02, 0.92, 0.02, 0.02], since the correct class gets 1 - eps + eps/K = 0.9 + 0.02 = 0.92 and each of the other 4 classes gets eps/K = 0.1/5 = 0.02. Cross-entropy loss is defined as L = -sum(y_i * ln(p_i)). If training converges so completely that the predicted distribution p becomes numerically identical to y, what does L equal, and does label smoothing ever let this loss reach exactly zero?
Evaluating y·ln(p) term by term gives a floor of approximately 0.390 nats — the Shannon entropy of the smoothed target itself — because cross-entropy only reaches zero when the target is a degenerate (one-hot) distribution
Switching to log base 2 instead of natural log for the same computation produces approximately 0.562, a unit-conversion slip rather than a true change in the loss
Omitting three of the four tied −0.02·ln(0.02) terms and keeping only one gives approximately 0.155, undercounting the smoothed distribution's off-diagonal probability mass
Perfect convergence drives the loss to exactly 0, since matching the predicted distribution to the target should, by definition, eliminate all cross-entropy error
Answer: A. Evaluating y·ln(p) term by term gives a floor of approximately 0.390 nats — the Shannon entropy of the smoothed target itself — because cross-entropy only reaches zero when the target is a degenerate (one-hot) distribution
ExplanationWhen p = y exactly, cross-entropy collapses to the Shannon entropy of y itself: L = -sum(y_i * ln(y_i)) = -[4*(0.02*ln(0.02)) + 0.92*ln(0.92)]. Since ln(0.02) is approximately -3.9120, each of the four tied incorrect-class terms contributes -0.02*(-3.9120) = 0.07824 nats, totaling 0.31296 nats. Since ln(0.92) is approximately -0.08338, the correct-class term contributes -0.92*(-0.08338) = 0.07671 nats. Summing gives L is approximately 0.31296 + 0.07671 = 0.38967, i.e., approximately 0.390 nats. This is exactly the entropy of the smoothed distribution, and by Gibbs' inequality cross-entropy H(y,p) >= H(y) with equality only at p = y, so the loss floor is H(y), not zero, precisely because label smoothing deliberately makes y a non-degenerate (not one-hot) distribution. Using log base 2 instead of natural log would rescale this same quantity to approximately 0.562, an arithmetic/unit slip rather than a genuinely different loss value. Dropping three of the four identical off-diagonal terms and keeping only one undercounts the sum and produces approximately 0.155. Assuming the loss reaches exactly 0 ignores that cross-entropy equals zero only when the target distribution is a one-hot vector, which label smoothing explicitly avoids by construction.
Question 88 · Wasserstein GAN loss · hard
A WGAN critic outputs unbounded real-valued scores (not sigmoid probabilities) and is regularized to be 1-Lipschitz via weight clipping. On one training batch, it scores four real images as D(x_real) = 5.2, 4.8, 5.0, 5.4, and four generated images as D(G(z)) = 1.0, 1.4, 0.8, 1.2. Using the critic loss L_critic = E[D(G(z))] - E[D(x_real)], which is minimized during training, what is the loss value for this batch, and what does it indicate about the critic's current ability to separate the two distributions?
Computing means gives E[D(G(z))] = 1.1 and E[D(x_real)] = 5.1, so L_critic = 1.1 - 5.1 = -4.0; since the critic minimizes this quantity, this strongly negative value shows it is successfully scoring real samples about 4.0 units above fake ones, an estimate of the Wasserstein distance.
Swapping the order to E[D(x_real)] - E[D(G(z))] gives 5.1 - 1.1 = 4.0, and because gradient descent always drives the loss toward more positive values, this indicates the critic is failing to separate the two distributions.
Summing rather than averaging the eight scores gives L_critic = 4.4 - 20.4 = -16.0, meaning the critic assigns real images a combined score sixteen units higher than the four fake images together.
Because the critic's outputs are unbounded real numbers rather than probabilities in [0, 1], the loss value -4.0 carries no meaningful interpretation about how well the critic distinguishes real from fake samples.
Answer: A. Computing means gives E[D(G(z))] = 1.1 and E[D(x_real)] = 5.1, so L_critic = 1.1 - 5.1 = -4.0; since the critic minimizes this quantity, this strongly negative value shows it is successfully scoring real samples about 4.0 units above fake ones, an estimate of the Wasserstein distance.
ExplanationThe critic loss is L_critic = E[D(G(z))] - E[D(x_real)]. Averaging the fake scores (1.0, 1.4, 0.8, 1.2) gives E[D(G(z))] = 4.4/4 = 1.1, and averaging the real scores (5.2, 4.8, 5.0, 5.4) gives E[D(x_real)] = 20.4/4 = 5.1. So L_critic = 1.1 - 5.1 = -4.0. Because the critic is trained to minimize this loss, more negative values are better for the critic — they mean D is assigning noticeably higher scores to real samples than to fake ones. Under the 1-Lipschitz constraint enforced by weight clipping, the magnitude of L_critic provides an estimate of the Wasserstein (Earth-Mover) distance between the real and generated distributions, so -4.0 indicates the critic currently estimates that distance to be about 4.0. The order-swapped version confuses which term the formula subtracts and misreads how gradient descent affects the sign. Summing instead of averaging conflates batch totals with per-sample expectations, producing a number that does not correspond to the defined loss. And dismissing the loss as uninterpretable ignores that unbounded critic outputs are exactly what let differences like this approximate a real distance metric, unlike the bounded probabilities used in a standard GAN's discriminator.
Question 89 · Conv2d output shape · hard
Consider the following PyTorch layer applied to a batch of images:
```python
import torch.nn as nn
layer = nn.Conv2d(in_channels=16, out_channels=32, kernel_size=5, stride=2, padding=2)
x = torch.randn(8, 16, 64, 64)
y = layer(x)
```
What are the resulting output tensor shape and the total number of learnable parameters in `layer`?
The layer produces an output of shape [8, 32, 32, 32], since H_out = W_out = floor((64 + 2·2 − 5)/2) + 1 = 32, and it has 32 × (16 × 5 × 5 + 1) = 12,832 learnable parameters, including one bias term per output filter.
Rounding the spatial formula up rather than down gives an output of shape [8, 32, 33, 33], while the parameter count remains 32 × (16 × 5 × 5 + 1) = 12,832, since only the ceiling of the stride division changes the spatial size.
Because PyTorch's Conv2d only allocates weight parameters when the kernel is applied without padding, this layer has 32 × 16 × 5 × 5 = 12,800 parameters despite the output shape still being [8, 32, 32, 32].
Ignoring the stride-2 subsampling and treating this as if stride were 1, the padding of 2 on each side exactly offsets the 5×5 kernel, so the output keeps the input's spatial size at [8, 32, 64, 64] with 12,832 parameters.
Answer: A. The layer produces an output of shape [8, 32, 32, 32], since H_out = W_out = floor((64 + 2·2 − 5)/2) + 1 = 32, and it has 32 × (16 × 5 × 5 + 1) = 12,832 learnable parameters, including one bias term per output filter.
ExplanationFor a Conv2d layer, each spatial dimension follows H_out = floor((H_in + 2P − K)/S) + 1. Here H_in = W_in = 64, P = 2, K = 5, S = 2, so H_out = floor((64 + 4 − 5)/2) + 1 = floor(63/2) + 1 = 31 + 1 = 32, giving output shape [8, 32, 32, 32] — the batch size and out_channels of 32 carry straight through. The floor operation matters here because 63/2 = 31.5 is not an integer; rounding up instead of down would incorrectly stretch the spatial size to 33 rather than 32. Parameter count is independent of the input's spatial resolution: each of the 32 output filters owns its own 16×5×5 = 400 weights plus one bias term, giving 32 × 401 = 12,832 total parameters. Dropping the bias term per filter undercounts by exactly 32 parameters (12,800 instead of 12,832) — bias is enabled by default in Conv2d and has nothing to do with whether padding is used. Assuming padding cancels the effect of a stride greater than 1 is also mistaken: padding only compensates for the kernel's spatial shrinkage at stride 1. With stride 2 the output is still subsampled to roughly half the input's spatial size regardless of padding, which is exactly why the resolution drops from 64 to 32 instead of staying at 64.
Question 90 · MaxPool2d downsampling · hard
A CNN feature-extraction block applies `nn.MaxPool2d(kernel_size=2, stride=2)` to an activation tensor of shape [32, 128, 28, 28] (batch, channels, height, width), where the output height/width follow floor((H - kernel_size) / stride) + 1, and channels are untouched by pooling — which option correctly gives the resulting output shape and the number of learnable parameters this layer adds?
The pooling layer outputs a tensor of shape [32, 128, 14, 14] and adds zero learnable parameters, because computing the max within each 2×2 window requires no weights — only spatial dimensions shrink via kernel size and stride while the channel count is preserved.
Channel count gets halved to 64 while height and width stay at 28, producing shape [32, 64, 28, 28] with zero learnable parameters, since pooling is often mistaken for reducing channels rather than spatial resolution.
A shape of [32, 128, 14, 14] emerges alongside 512 trainable parameters, on the incorrect assumption that each channel learns its own 2×2 pooling kernel updated through backpropagation.
Applying the input-minus-kernel-plus-one formula while ignoring stride yields shape [32, 128, 27, 27] with zero learnable parameters, treating the pooling window as if it were a stride-1 convolution.
Answer: A. The pooling layer outputs a tensor of shape [32, 128, 14, 14] and adds zero learnable parameters, because computing the max within each 2×2 window requires no weights — only spatial dimensions shrink via kernel size and stride while the channel count is preserved.
ExplanationApplying the standard pooling output formula H_out = floor((H_in - kernel_size) / stride) + 1 to H_in = W_in = 28 with kernel_size = 2 and stride = 2 gives floor((28 - 2) / 2) + 1 = floor(13) + 1 = 14, so both height and width become 14. MaxPool2d operates independently within each channel and never mixes or reduces channels, so the channel dimension stays at 128, giving output shape [32, 128, 14, 14]. Because max-pooling simply selects the largest activation in each 2x2 window — it does not compute a weighted sum — there is no weight matrix or bias to learn, so the layer contributes exactly 0 trainable parameters regardless of kernel size or channel count; only the argmax index per window is cached (for routing gradients during backpropagation), and that cache is not a learnable parameter. The claim that channels get halved confuses pooling with a channel-reduction operation such as a 1x1 convolution or grouped conv, which pooling never performs. The claim of 512 trainable parameters wrongly imports the idea of a learnable kernel from convolutional layers, where a kxk filter per channel would indeed introduce weights — pooling has no analogous filter to learn. The claim of a 27x27 output comes from using the valid-convolution formula (H_in - kernel_size + 1) meant for stride-1 layers, which skips dividing by the stride and therefore overcounts how many non-overlapping windows fit across the 28-pixel dimension.
Question 91 · BatchNorm statistics · hard
You create `bn = nn.BatchNorm2d(64)` and, during training, feed it a batch of shape [32, 64, 56, 56] (batch, channels, height, width). After training finishes, you call `bn.eval()` and pass it a single image reshaped to [1, 64, 56, 56]. Which statement about how bn computes and uses its statistics is correct?
During training, each channel's mean and variance are computed by averaging over all 32 × 56 × 56 = 100,352 values that belong to that channel across the batch and spatial dimensions, and after bn.eval() is called the layer uses its stored running_mean and running_var instead of computing new statistics, so it processes a batch of size 1 without error.
BatchNorm2d effectively behaves like InstanceNorm2d during training, since each of the 32 samples has its own channel statistics computed from only its 56 × 56 = 3,136 spatial values, independent of the other samples in the batch.
Only 64 learnable parameters exist in this layer because a single shared gamma and beta pair is broadcast across all 64 channels, rather than each channel owning its own gamma and beta.
Calling bn.eval() on the single-image batch of shape [1, 64, 56, 56] would raise an error or produce zero variance, because BatchNorm always recomputes batch statistics on the fly regardless of training or evaluation mode.
Answer: A. During training, each channel's mean and variance are computed by averaging over all 32 × 56 × 56 = 100,352 values that belong to that channel across the batch and spatial dimensions, and after bn.eval() is called the layer uses its stored running_mean and running_var instead of computing new statistics, so it processes a batch of size 1 without error.
Explanationnn.BatchNorm2d(64) maintains one gamma and one beta per channel, giving 64 + 64 = 128 learnable parameters, so each channel owns its own independent scale and shift rather than sharing a single pair across all channels. During training, statistics for a given channel are pooled across the batch and spatial axes together: for input [32, 64, 56, 56], every value at that channel across all 32 samples and all 56 × 56 = 3,136 spatial locations contributes to one shared mean and variance, i.e., 32 × 3,136 = 100,352 values are reduced to a single mean/variance pair per channel, which is then used to normalize the activations before applying that channel's gamma and beta. This is fundamentally different from InstanceNorm2d, which computes statistics separately for each sample using only that sample's spatial values. While training, PyTorch also updates running_mean and running_var through an exponential moving average controlled by the layer's momentum. Once bn.eval() is called, the layer stops computing batch statistics entirely and instead normalizes using the frozen running_mean and running_var, which is exactly why BatchNorm works correctly on inference batches as small as a single image — variance is never computed from that lone sample, so no error or degenerate zero-variance case arises.
Question 92 · attention score computation · hard
In scaled dot-product attention, Attention(Q, K, V) = softmax(QK^T / sqrt(d_k)) V. A model computes attention using Q with shape [1, 6, 8] (batch=1, 6 query positions, d_k=8), K with shape [1, 10, 8] (10 key positions, d_k=8), and V with shape [1, 10, 32] (10 value positions, d_v=32). The scores QK^T are scaled by sqrt(8) and passed through softmax along the last dimension before the result is multiplied by V. What is the shape of the final attention output, and why?
Output shape is [1, 6, 32]: the 6 comes from Q's query count, and the 32 comes from V's feature dimension, since d_k need not equal d_v.
Since attention output must retain Q's original feature dimension, the output shape is [1, 6, 8].
Output rows are set by the number of key-value pairs rather than queries, giving an output shape of [1, 10, 32].
Because the softmax weights are never multiplied against V in this computation, the output shape stays at [1, 6, 10], matching the score matrix.
Answer: A. Output shape is [1, 6, 32]: the 6 comes from Q's query count, and the 32 comes from V's feature dimension, since d_k need not equal d_v.
ExplanationScores = Q @ K^T multiplies [1,6,8] by K transposed to [1,8,10], giving shape [1,6,10] — one row per query, one column per key. Dividing by sqrt(8) and applying softmax along the last axis leaves the shape unchanged at [1,6,10]; these are now attention weights, one row per query summing to 1 across the 10 keys. Multiplying these weights [1,6,10] by V [1,10,32] contracts over the shared dimension of 10 key-value pairs, producing a final output of shape [1,6,32]: 6 rows because there are 6 queries, and 32 columns because that is V's feature dimension, d_v. This shows d_k (used only by Q and K to compute similarity scores) does not need to equal d_v (used only by V) — the output's feature width always inherits from V, never from Q or K. The claim that output preserves Q's own feature dimension confuses the query embedding size with the value embedding size, which are independent in general. The claim that output has 10 rows mistakes the key/value count for the query count, effectively swapping which tensor drives the output's row dimension. The claim that output stops at shape [1,6,10] ignores the final multiplication against V entirely, halting one step early at the intermediate attention-weight matrix instead of completing the weighted sum over the value vectors.
Question 93 · transfer learning freezing · hard
A pre-trained CNN backbone with 15,000,000 parameters is frozen for transfer learning. Its final feature map (256 channels x 4x4 spatial) is flattened to a length-4096 vector and fed into a new trainable head: Dense(4096 to 512) followed by Dense(512 to 10) for a 10-class classification task. The head is trained with the Adam optimizer, which maintains two per-parameter state buffers (first and second moment estimates). Which of the following correctly analyzes how the forward pass, backward pass, and optimizer memory usage behave in this frozen-backbone setup?
The forward pass must still compute activations through the entire frozen backbone to produce the 4096-dimensional feature vector, but backpropagation needs no weight gradients for the backbone's 15,000,000 parameters, so Adam's optimizer state is limited to two buffers for each of the head's 2,102,794 trainable parameters, roughly 4,205,588 stored values
Freezing the backbone stops the forward pass at the last unfrozen layer too, so the model feeds raw flattened pixels directly into the first Dense layer, making the 15,000,000 backbone parameters irrelevant to every training step
Since the optimizer still tracks all 17,102,794 parameters to preserve the model's architecture, Adam allocates momentum and variance buffers for the full parameter count, giving no memory savings over fine-tuning the entire network
Backpropagation must compute gradients for the frozen backbone's weights so they can be verified as unchanged after the optimizer step, adding 15,000,000 gradient values to memory even though no update is applied
Answer: A. The forward pass must still compute activations through the entire frozen backbone to produce the 4096-dimensional feature vector, but backpropagation needs no weight gradients for the backbone's 15,000,000 parameters, so Adam's optimizer state is limited to two buffers for each of the head's 2,102,794 trainable parameters, roughly 4,205,588 stored values
ExplanationWhen a layer is frozen, autograd still needs that layer's output during the forward pass because the trainable head depends on it, so the model computes activations through the entire 15,000,000-parameter backbone to produce the 4096-length feature vector. But because the backbone's weights are never included in the parameter list handed to the optimizer, no gradient is computed with respect to them, and Adam never allocates its two per-parameter state buffers for them. That state is created only for the head's trainable parameters: Dense(4096 to 512) contributes 4096*512+512 = 2,097,664 parameters, and Dense(512 to 10) contributes 512*10+10 = 5,130 parameters, for a total of 2,102,794 trainable parameters, so Adam stores 2 * 2,102,794 = 4,205,588 buffer values — far less than the full model's 15,000,000+2,102,794 = 17,102,794 parameters would require if everything were trainable. The claim that freezing also halts the forward pass at the backbone misdescribes autograd: intermediate activations are still required to feed the head, they are simply not tracked for gradient computation with respect to backbone weights. The claim that Adam's state matches the full 17,102,794-parameter count misunderstands that an optimizer only receives the parameter groups explicitly passed to it, not every parameter in the model object. The claim that gradients are computed for the frozen weights merely to confirm they stay unchanged is also incorrect: with those weights excluded from gradient tracking, PyTorch-style autograd never builds a gradient tensor for them at all, so no such 15,000,000-value gradient buffer is ever allocated.
Question 94 · DQN experience replay · hard
In DQN, the loss for a sampled transition (s, a, r, s', done) is L = (Q(s, a; θ) − y)², where y = r + γ · max_{a'} Q(s', a'; θ⁻) · (1 − done). Here θ are the online network's weights, updated every step by gradient descent, and θ⁻ are the target network's weights, hard-copied from θ every 10,000 steps. Separately, the replay buffer stores up to 1,000,000 past transitions, and each training step samples a uniformly random mini-batch of 32 from across this entire buffer rather than training on the most recent transition alone. Which statement correctly identifies the specific instability that the frozen target network θ⁻ addresses versus the specific instability that random sampling from the replay buffer addresses?
Freezing θ⁻ for 10,000 steps is actually what decorrelates consecutive states in a trajectory, while the replay buffer is what stops the bootstrapped target from shifting, by averaging the reward r across all one million stored transitions.
The target network prevents the bootstrapped target y from shifting on every gradient update, since y depends on the frozen θ⁻ rather than the currently-changing θ, whereas the replay buffer prevents consecutive updates from being computed on highly correlated, non-i.i.d. transitions drawn from a single trajectory.
Both mechanisms exist purely to reduce the variance of the sampled reward r, because averaging a mini-batch of 32 transitions is mathematically equivalent to freezing θ⁻ for 10,000 steps.
Sampling uniformly at random from the buffer guarantees each transition is used exactly once before the capacity of 1,000,000 is reached, and separately, fixing θ⁻ removes the need for the discount factor γ inside y.
Answer: B. The target network prevents the bootstrapped target y from shifting on every gradient update, since y depends on the frozen θ⁻ rather than the currently-changing θ, whereas the replay buffer prevents consecutive updates from being computed on highly correlated, non-i.i.d. transitions drawn from a single trajectory.
ExplanationVanilla Q-learning has two distinct sources of instability, and DQN uses two distinct mechanisms to fix them. The moving-target problem arises because the bootstrapped target y = r + γ·max_{a'} Q(s', a'; θ) would ordinarily be computed with the same weights θ that gradient descent is updating every step, so the target keeps shifting under the network as it trains, which can cause oscillation or divergence. DQN solves this by computing y from a separate, periodically-copied target network θ⁻ — here hard-copied every 10,000 steps — so the target stays fixed between copies even while θ keeps training toward it. The correlation problem is unrelated to this: consecutive transitions (s, a, r, s', done) collected along one trajectory are highly similar to each other, which violates the independent, identically distributed samples that stochastic gradient descent assumes. The replay buffer fixes this by storing up to 1,000,000 past transitions and drawing a uniformly random mini-batch of 32 from across the whole buffer, so each mini-batch mixes transitions from many different points in the agent's history instead of one short, correlated stretch. The claim that freezing θ⁻ is what decorrelates trajectory states, while the buffer is what stabilizes the target by averaging reward over every stored transition, swaps which mechanism solves which problem — the buffer never averages rewards, and freezing θ⁻ has no effect on which states get sampled into a batch. The claim that both mechanisms only reduce the variance of the sampled reward, treating a 32-transition mini-batch average as mathematically equivalent to a 10,000-step weight freeze, conflates two unrelated operations: one averages a loss over sampled transitions, the other freezes a set of parameters in time. The claim that uniform random sampling guarantees each transition is used exactly once before the buffer reaches capacity is false, since sampling with replacement means a given transition can be drawn several times, or never, before it is eventually evicted; it is equally false that freezing θ⁻ removes the need for γ, which still appears explicitly inside y regardless of whether θ⁻ is frozen or not.
Question 95 · label smoothing · hard
Label smoothing is applied to a 4-class classification problem (K = 4) with smoothing parameter eps = 0.2 and true class index 2. The one-hot label y = [0, 1, 0, 0] becomes the smoothed label y_smooth = [0.05, 0.85, 0.05, 0.05], since the correct class receives 1 − eps + eps/K = 0.8 + 0.05 = 0.85 and each incorrect class receives eps/K = 0.2/4 = 0.05. Cross-entropy loss is computed as L = −Σ y_smooth_i · ln(p_i) over the model's predicted probabilities p, using the natural logarithm. Compared to training with the original one-hot label, what happens to the minimum achievable value of this loss once label smoothing is applied?
Once label smoothing replaces the one-hot target, the minimum achievable loss is no longer zero: it is reached only when the predicted distribution p exactly matches y_smooth, giving a minimum loss equal to the entropy of y_smooth, approximately 0.588 nats.
Cross-entropy's global minimum is unaffected by which label vector is used as the target, so training still drives the loss down to exactly zero regardless of the smoothed values.
Because ln(0.05) is undefined whenever a target probability falls below 0.1, the loss becomes unbounded and never converges to a finite minimum under label smoothing.
Predicting p = [0.05, 0.85, 0.05, 0.05] still yields a loss of exactly zero, since cross-entropy between two identical probability distributions is always zero by definition.
Answer: A. Once label smoothing replaces the one-hot target, the minimum achievable loss is no longer zero: it is reached only when the predicted distribution p exactly matches y_smooth, giving a minimum loss equal to the entropy of y_smooth, approximately 0.588 nats.
ExplanationCross-entropy H(y, p) = −Σ yᵢ ln(pᵢ) decomposes as H(y, p) = H(y) + KL(y ‖ p), where the KL term is always ≥ 0 and hits 0 only when p equals y exactly. That means the smallest possible loss for a fixed target y is H(y) itself — the entropy of the target — attained precisely when the model's output distribution matches y. For the original one-hot label [0, 1, 0, 0], H(y) = 0 (one outcome has probability 1, the rest 0), so a sufficiently confident network can push the loss all the way to zero. For the smoothed label y_smooth = [0.05, 0.85, 0.05, 0.05], though, H(y_smooth) = −(0.85·ln0.85 + 3×0.05·ln0.05) = −(−0.138 + −0.449) ≈ 0.588 nats, which is strictly positive. So even a prediction that lines up perfectly with y_smooth cannot bring the loss below roughly 0.588 nats — label smoothing raises the floor on achievable loss on purpose, which is exactly how it keeps the network from becoming arbitrarily overconfident. The claim that the loss still reaches zero ignores this: the achievable minimum is H(y), not a fixed 0, and smoothing changes y itself. The claim that ln(0.05) is undefined is simply false — natural log is defined for every positive probability, and under smoothing the target never actually asks for a probability of exactly 0, which is one of the numerical-stability benefits smoothing provides over one-hot targets. The claim that predicting p = y_smooth gives zero loss confuses cross-entropy with KL divergence: KL(y ‖ y) = 0, but the cross-entropy H(y, y) equals H(y), the entropy of y, which is positive whenever a distribution spreads probability mass over more than one class — exactly the situation label smoothing creates.
Question 96 · Conv2D Parameters · hard
A Conv2D layer has in_channels=2, out_channels=14, and a kernel size of 3×3. Using the formula O×(I×K²+1), how many learnable parameters does this layer have?
252, calculated as 14×(2×3×3) by omitting the required bias term from each output filter
266, because each of the 14 output filters has 2×3×3=18 weights plus 1 bias, giving 14×19=266
254, calculated as 2×(14×3×3+1) by swapping the input and output channel counts in the formula
18, the weight count for a single output filter, without multiplying by the 14 output channels
Answer: B. 266, because each of the 14 output filters has 2×3×3=18 weights plus 1 bias, giving 14×19=266
ExplanationConv2D learnable parameters equal the weights plus the bias in each output filter, summed over all output filters. Here each of the 14 output filters convolves over 2 input channels with a 3×3 kernel, so each filter has 2×3×3 = 18 weights plus 1 bias term, for 19 parameters per filter. Multiplying across all 14 filters: 14×(2×3×3+1) = 14×19 = 266 total learnable parameters.
Question 97 · Conv2D Parameters · hard
A Conv2D layer has in_channels=1, out_channels=15, and kernel_size=3×3. Using the formula Parameters = O×(I×K²+1), what is the total number of learnable parameters?
Parameters = 9, counting only the weights in a single output filter's kernel
Parameters = 135, computed as 15 output filters multiplied by 9 weights each, excluding bias terms
Parameters = 15, one bias value per output channel
Parameters = 150, because each of 15 output filters has I×K²=9 weights plus 1 bias: 15×(1×3×3+1) = 150
Answer: D. Parameters = 150, because each of 15 output filters has I×K²=9 weights plus 1 bias: 15×(1×3×3+1) = 150
ExplanationConv2D learnable parameters include weights and biases. Each of the 15 output filters has a kernel of size 1×3×3, giving I×K²=9 weights, plus 1 bias term. Total: 15×(1×3×3+1) = 15×10 = 150 parameters.
Question 98 · Conv2D Parameters · hard
A Conv2D layer is configured with in_channels=4, out_channels=16, and a kernel_size of 5×5, with a bias term included for every output filter. What is the total number of learnable parameters in this layer?
1616 parameters, since each of the 16 output filters carries 4×5×5=100 weights plus one bias, giving 16×101=1616
1600 parameters, if bias terms are omitted, since each of the 16 filters would then carry only 4×5×5=100 weights
101 parameters, if you count only one filter's weights and bias without scaling by the 16 output channels
1664 parameters, if each output filter is assumed to need a separate bias per input channel, giving 16×4×26=1664
Answer: A. 1616 parameters, since each of the 16 output filters carries 4×5×5=100 weights plus one bias, giving 16×101=1616
ExplanationFor a Conv2D layer, each output filter needs one weight for every input channel at every kernel position, so a single filter's weight count is in_channels × kernel_height × kernel_width = 4×5×5 = 100. Adding one bias term per filter gives 101 parameters per filter. Since there are 16 output filters — one independent filter per output channel, each spanning all 4 input channels — the total learnable parameter count is 16×101 = 1616. A filter does not need a separate bias for each input channel, because the bias is added once after the contributions from all input channels have already been summed inside the convolution; and the per-filter count of 101 must still be scaled by the number of output filters rather than reported on its own.
Question 99 · GRU Parameters · hard
Analyze a GRU (Gated Recurrent Unit) with hidden_size=68 and input_size=98: calculate its total parameter count, compare it with an equivalent LSTM (which uses 4 gates), and evaluate why the two architectures differ in parameter efficiency?
GRU has more parameters than LSTM because it uses 4 gates instead of 3, making it the heavier of the two architectures
Parameters = 6664, counting only the input-to-hidden weights and ignoring the hidden-to-hidden weights and biases
Parameters = 4×(68×(68+98)+68) = 45424, applying LSTM's 4-gate count instead of GRU's actual 3 gates
Parameters = 3×(68×(68+98)+68) = 34068 (3 gates: reset, update, candidate); LSTM has 4×params because it has 4 gates; GRU is more parameter-efficient
Answer: D. Parameters = 3×(68×(68+98)+68) = 34068 (3 gates: reset, update, candidate); LSTM has 4×params because it has 4 gates; GRU is more parameter-efficient
ExplanationGRU has 3 gates (reset r, update z, candidate h'), each contributing h×(h+x)+h parameters. Total: 3×(68×(68+98)+68) = 3×(68×166+68) = 3×(11288+68) = 3×11356 = 34068. LSTM has 4 gates (input, forget, output, candidate), so it needs 4×(68×(68+98)+68) = 45424 parameters — more than GRU because of the extra gate. GRU is therefore more parameter-efficient and computationally faster while often matching LSTM performance. Both architectures address the vanishing gradient problem through gating mechanisms; GRUs are preferred when computational resources are limited, while LSTMs are preferred for capturing more complex long-range dependencies.
Question 100 · Conv2D Parameters · hard
A Conv2D layer has in_channels=1, out_channels=16, and kernel_size=5×5. Using the formula O×(I×K²+1) for learnable parameters, how many total learnable parameters does this layer have?
Parameters = 400, since multiplying 16 output filters by 25 weights each omits the 16 bias terms
Parameters = 416, because each of 16 output filters has I×K²=25 weights plus 1 bias: 16×(1×5×5+1) = 416
Parameters = 16, counting only the output channels while ignoring both the kernel weights and the bias terms
Parameters = 25, treating the kernel size squared as the total while ignoring the number of output filters
Answer: B. Parameters = 416, because each of 16 output filters has I×K²=25 weights plus 1 bias: 16×(1×5×5+1) = 416
ExplanationConv2D learnable parameters include both weights and biases. Each of the 16 output filters has a kernel of size 1×5×5, giving 1×5×5 = 25 weights per filter, plus 1 bias term per filter. Applying the formula O×(I×K²+1): 16×(1×25+1) = 16×26 = 416 parameters. For comparison, a Conv2D(3, 64, 3) layer in a ResNet-style network has 64×(3×3×3+1) = 1,792 parameters — the same formula, just with more input channels and a smaller kernel. The 400-parameter figure comes from multiplying 16×25 and forgetting to add the 16 bias terms; counting only 16 or only 25 leaves out the kernel size or the number of filters entirely, so neither matches the correct formula.