Data Manipulation and Preparation

A team has a sparse document-term matrix from a text corpus with 80,000 term columns, most of which are zero for any given document. They want to reduce it to 200 dense latent features for a downstream classifier while keeping the operation efficient on the sparse input and avoiding the dense mean-centring step that standard PCA requires. Which dimensionality reduction technique is the most appropriate choice?

• AStandard PCA after subtracting the column means, because mean-centring the matrix is required for any variance-based projection to be valid.
• BTruncated singular value decomposition retaining 200 components, because it operates directly on the sparse matrix without centring and yields dense latent features.check_circle Correct
• CUMAP reduction to 200 dimensions, because it scales to high-dimensional sparse input and preserves global variance better than matrix factorisation.
• DA variance threshold filter that drops every term column whose variance falls below a cut-off, leaving roughly 200 surviving term columns.

Why A is wrong: Standard PCA is tempting because it is the canonical reduction method, but mean-centring destroys sparsity by filling in the zeros, forcing a dense computation that is exactly what the scenario wants to avoid on an 80,000-column matrix.

Why B is correct: Truncated SVD factorises the matrix without requiring mean-centring, so it preserves sparsity during computation, runs efficiently on the sparse term matrix, and outputs the 200 dense latent features the classifier needs.

Why C is wrong: UMAP can handle high-dimensional input, which makes it tempting, but it is designed to preserve local neighbourhood structure for low-dimensional embeddings rather than global variance, and it is not the efficient sparse linear factorisation the scenario calls for.

Why D is wrong: Variance thresholding is a cheap reduction step and is tempting for sparse data, but it only removes near-constant original columns and produces no dense latent features, so it cannot deliver the 200 combined features the workflow requires.

A cuDF column 'property_price' is strongly right-skewed: most homes sit in a narrow lower band while a long tail of luxury properties stretches into the millions. The engineer plans to use this column as a predictor in a cuML linear regression and wants to reduce the leverage of the extreme tail without discarding any rows. Which transformation is most appropriate?

• AApply min-max scaling to compress the column into the range 0 to 1 so that the extreme values no longer dominate the fitted coefficient.
• BApply a logarithmic transformation so that the long upper tail is compressed and the distribution becomes more symmetric.check_circle Correct
• CApply one-hot encoding after splitting the prices into deciles so that each price band becomes an independent binary feature.
• DApply standardisation to centre the column at zero mean and unit variance so that the skewed values become normally distributed.

Why A is wrong: Min-max scaling rescales the range but preserves the relative spacing of values, so the long right tail remains and the skew and high-leverage outliers are unchanged.

Why B is correct: A log transform compresses large values far more than small ones, pulling in the long right tail, reducing skew, and lowering the leverage of extreme prices while preserving the continuous monotonic relationship a linear model can exploit.

Why C is wrong: Binning into deciles then one-hot encoding can handle skew, but it discards the continuous magnitude information the regression can use and adds many columns, making it a heavier choice than a simple monotonic transform that keeps the column continuous.

Why D is wrong: This is a common misconception: standardisation shifts and rescales the values but does not change the shape of the distribution, so a right-skewed column stays right-skewed after standardising.

A team saves a cuDF DataFrame that contains integer, float, and categorical columns to a Parquet file, then reloads it in a later session. Which statement best describes what happens to the column data types during this round-trip?

• AAll columns are reloaded as object dtype because Parquet stores everything as strings internally
• BInteger and float columns are preserved, but categorical columns are silently converted to plain strings on reload
• CColumn names are preserved but all numeric types are widened to 64-bit on reload regardless of the original precision
• DColumn names, numeric precisions, and categorical encodings are all faithfully restored because the schema is embedded in the Parquet footercheck_circle Correct

Why A is wrong: Parquet does not store values as strings internally; it uses typed encodings such as INT32, DOUBLE, and BYTE_ARRAY with logical type annotations. Object dtype is a common result of reading CSV files, not Parquet files.

Why B is wrong: Parquet supports a categorical logical type via dictionary encoding, and cuDF's read_parquet is able to reconstruct categorical columns. Stating that categoricals are silently lost overstates a limitation that applies to some older tools, not to the current cuDF Parquet reader.

Why C is wrong: Parquet stores the exact bit-width of each numeric column in its schema metadata. A column written as INT32 is read back as INT32, not automatically widened to INT64. Widening can happen in some CSV parsing paths due to type inference, but not in Parquet round-trips.

Why D is correct: Parquet embeds a typed schema in the file footer, recording each column's logical and physical type, including dictionary-encoded categoricals. When cuDF reads the file it consults this footer to reconstruct the exact dtype for every column, eliminating the type-inference guesswork required when parsing CSV.

A fraud-detection model trained on a dataset where 98% of transactions are legitimate achieves 98.1% accuracy. Why is accuracy a misleading metric in this scenario, and which metric should be prioritised instead?

• AAccuracy is misleading because it rewards predicting the majority class; the precision-recall AUC (PR-AUC) is more informative for evaluating performance on the minority class.check_circle Correct
• BAccuracy is misleading because it depends on the learning rate schedule; ROC-AUC corrects this by evaluating loss curves independently of hyperparameter choices.
• CAccuracy is misleading only when the dataset is smaller than a few thousand rows; for large transaction datasets accuracy remains the recommended evaluation metric.
• DAccuracy is misleading because GPU-accelerated cuML metrics compute it on sampled batches; switching to the F1 score removes the sampling artefact entirely.

Why A is correct: On severely imbalanced data a classifier that predicts every transaction as legitimate still achieves near-perfect accuracy, so accuracy conflates majority-class dominance with genuine predictive power. PR-AUC focuses the evaluation on the minority class by measuring the trade-off between precision and recall across all decision thresholds, making it the right choice here.

Why B is wrong: The learning rate schedule is a training hyperparameter, not the reason accuracy misleads on imbalanced data. ROC-AUC does handle imbalance better than accuracy, but attributing the flaw to hyperparameters reflects a misunderstanding of why class imbalance distorts the accuracy metric.

Why C is wrong: Dataset size has no bearing on why accuracy misleads for imbalanced classes. Even millions of fraud transactions can be 98% legitimate, and a majority-class predictor would still score ~98% accuracy regardless of scale. The distortion is caused by class ratio, not volume.

Why D is wrong: cuML computes metrics on the full dataset rather than sampled batches, so the claimed sampling artefact is not accurate. F1 score is indeed a better metric for imbalanced problems, but the reason accuracy misleads is the class ratio, not an implementation detail of GPU-accelerated metric computation.