- Which assumption best justifies this transformation?
Answer: NaN and infinite results do not represent valid physical measurements, both may be treated as missing for this analysis, and finite values retain their units.
When you see a question about data-cleaning transformations in R, ask yourself: what are the mathematical properties of the values being replaced, and why does the domain justify treating them as missing?
is.finite(x) returns FALSE for NA, NaN, Inf, and -Inf — so writing x[!is.finite(x)] <- NA_real_ replaces all four of those non-finite cases with a proper missing value. In a physical sensor context, measurements must have bounded, real magnitudes. Neither Inf (produced by division by zero) nor NaN (produced by undefined operations like 0/0) corresponds to any real-world reading. Treating them as missing is scientifically sound, and replacing them with NA_real_ ensures downstream functions like mean() or lm() handle them consistently. That's exactly what C describes — and it correctly notes that finite values are untouched, preserving their units and numeric meaning.
A is wrong because Inf and -Inf are not physically meaningful sensor extremes; they are arithmetic artifacts, not the largest or smallest legitimate readings. Keeping them would corrupt any statistical summary.
B is wrong because is.na() and is.finite() are not equivalent. is.na() catches NA and NaN, but is.finite() additionally excludes Inf and -Inf. The transformation does real work beyond mere type standardization.
D is wrong because non-finite values carry no numeric magnitude to preserve — replacing Inf with NA_real_ discards the infinity, it doesn't encode a measured zero.
As a study tip, memorize R's four "not-real" values — NA, NaN, Inf, -Inf — and which detection functions catch which. Exam questions often hinge on those distinctions.
- Which assumption should be stated and implemented before producing the numeric encoding?
Answer: The only valid labels are the three documented categories, blanks mean unknown risk, and the intended order is set explicitly as low, medium, high.
When encoding categorical text as ordered numbers for a model, you must make three explicit decisions before writing any code: what the valid categories are, what missing values mean, and what order the categories follow. This question tests whether you can identify the complete and correct set of those decisions for an ordinal encoding task.
The only fully sound approach is B. It recognizes that the domain defines exactly three valid labels, treats blanks as genuinely unknown (not as a category with implied rank), and — most importantly — sets the factor levels explicitly with factor(risk, levels = c("low", "medium", "high"), ordered = TRUE). That single line encodes the business logic into the data structure, so the numeric codes 1, 2, 3 carry the intended meaning rather than an accidental alphabetical one.
Choice A fails because alphabetical order gives high=1, low=2, medium=3, which reverses the real severity ranking and misrepresents blanks as having the lowest risk — a substantive error in an ordinal model. Choice C incorrectly declares the categories nominal, which would make integer codes meaningless for an ordinal model, and again misinterprets blanks as "no risk" rather than unknown. Choice D is doubly wrong: character strings carry no numeric magnitude in R (they are just text), and claiming blanks mean medium risk introduces an arbitrary imputation with no justification.
A reliable study tip: whenever you see ordinal data in R, immediately ask yourself three questions — what levels exist, what do missing values mean, and what is the intended order? If any one of those is assumed rather than stated and coded explicitly, the analysis can silently produce incorrect results.
- Which assumption most accurately describes the data before statistical analysis?
Answer: Numeric entries are quantified in milligrams per liter, <0.01 is a left-censored observation rather than ordinary missingness, and explicit NA means unavailable.
When working with environmental or laboratory data in R, you need to distinguish between three fundamentally different data situations: a quantified measurement, a censored observation, and true missingness. Getting this wrong leads to biased statistical conclusions before you write a single line of analysis code.
The value <0.01 is not a typo, a formatting error, or an absent measurement — it is a left-censored observation. The analyte was detected, but below the instrument's quantification limit. You know a real concentration exists somewhere in the interval (0, 0.01); you just cannot pin down the exact value. When R's as.numeric() coerces <0.01 to NA, it silently erases that information, which is why recognizing it as censored — not missing — is critical before any analysis. Explicit NA values, by contrast, mean the measurement simply was not recorded or is unavailable. Answer C captures all three layers correctly: quantified numerics in mg/L, left-censored <0.01, and explicit NA as truly unavailable.
A is wrong because it mislabels censored data as "malformed text" and treats the coercion-generated NA as an unobserved specimen — both errors obscure the real data structure. B inverts the logic entirely: it calls <0.01 an exact zero (it isn't — zero would mean no detection at all) and misidentifies explicit NA as the below-limit value. D introduces a unit error (grams per liter vs. mg/L) and wrongly classifies censoring as ordinary missingness, then compounds the mistake by suggesting imputation with the detection limit without any censored-data methods.
As a study strategy, whenever you see threshold notation like <value in a dataset, immediately think censoring, not missing data — these require specialized methods like Kaplan-Meier estimation or maximum likelihood, not simple na.omit(). - Which assumption should be stated before using
postal_code to group deliveries? Answer: postal_code is a character identifier, leading zeros are meaningful, and NA represents an unknown region rather than region zero.
Whenever you work with identifiers in R — things like postal codes, phone numbers, or ID numbers — the critical question is whether the values represent quantities or labels. This distinction drives every downstream decision about storage, transformation, and grouping.
Postal codes are labels, not measurements. A code like 00123 has a meaningful leading zero: strip it and you get a completely different region. When R imports the column as integer, it silently drops that zero, turning 00123 into 123 — a data loss that corrupts your grouping. Before using the column, you must state that it should be stored as a character type, that leading zeros carry meaning, and that NA reflects a genuinely unknown region (not a stand-in for any real code). That's exactly what A captures, making it the correct answer.
B is wrong on every clause: postal codes are not measurements, leading zeros are not "formatting only," and replacing NA with the median code is statistically nonsensical — you can't average region labels. C introduces the idea of an "ordered numeric category," but postal codes have no meaningful numeric order; a higher number doesn't mean a "greater" region. Treating NA as the lowest region fabricates data. D sounds cautious by suggesting zeros "can be restored later," but this is a false comfort — once R reads 00123 as integer 123, the original value is gone unless you re-import. Grouping NA with 00000 also invents a category without justification.
Your study tip: whenever a column contains codes, IDs, or zip codes, always ask "is this a quantity or a label?" If it's a label, import it as character immediately — never plan to fix it after the fact.
- Which assumption statement best supports computing speed in meters per second?
Answer: Distance is in meters, elapsed time is in milliseconds and must be divided by 1000, NA means unavailable, and zero elapsed time is invalid.
When computing a derived quantity like speed, every assumption about your raw data must be grounded in the actual documentation — not guesses or convenient simplifications. Ask yourself: are the units correct, are missing values handled properly, and are edge cases (like division by zero) addressed?
To compute speed in meters per second, you need distance in meters and elapsed time in seconds. Since the documentation states elapsed time is in milliseconds, you must convert: elapsed_s=1000elapsed. You also need to exclude NA values (which signal unavailable timer readings) and reject zero elapsed times (which cause division by zero and represent device malfunctions, not real measurements). Answer A captures all of this precisely — correct units, proper conversion, appropriate NA semantics, and explicit zero-validation.
Answer B fails because it claims elapsed time is already in seconds (contradicting the documentation) and misinterprets NA as "stationary vehicle" — an unsupported assumption that would silently corrupt your analysis. Answer C wrongly states distance is in kilometers and treats NA as zero duration, both of which contradict the documentation; it also suggests retaining infinite speed values, which is analytically dangerous. Answer D is the most subtly wrong: it assumes shared numeric type guarantees unit compatibility (it doesn't — type and unit are independent concepts), dismisses NA handling, and ignores zero-elapsed validation entirely.
A useful study habit: whenever a question involves computing a derived variable in R, mentally check three things — unit conversion, NA handling, and boundary conditions. Missing any one of them can silently produce nonsensical results. - Which assumption should guide the conversion?
Answer: Y means TRUE, N means FALSE, blanks and imported NA both mean unknown consent status, and no other codes are treated as valid without further review.
When working with character fields that encode consent or survey responses, your job isn't to invent meaning — it's to preserve what's actually known and flag what isn't. This question tests whether you understand the difference between absence of a value and a known negative response.
Y and N are explicit signals: the respondent actively indicated yes or no. Converting Y to TRUE and N to FALSE is the only defensible mapping because both represent deliberate answers. Blank strings and imported NA values, however, are ambiguous — a blank might mean the question was skipped, the data was lost, or the field simply wasn't applicable. Treating either as a definitive answer (TRUE or FALSE) imposes meaning that isn't there. The safe, analytically sound approach is to treat both as NA in the output logical column, flagging them for review. That's exactly what D describes.
Choice A commits the classic coercion trap: nonempty strings in R do coerce to TRUE, but that makes N logically true, which is semantically wrong for consent data. Choice B invents a meaning for N (treating it as missing rather than refusal) and fabricates a default for NA (consent granted) — both are unsupported assumptions that could create serious errors in analysis. Choice C assigns "refusal" to blanks, which is a specific interpretation not warranted by the data; a blank is simply unknown, not equivalent to N.
As a study strategy, whenever you see data-type conversion questions involving survey or consent fields, ask yourself: does this mapping add assumptions beyond what the data actually says? If yes, it's probably wrong.
- Which assumption would make the elapsed-time calculation defensible without additional offset data?
Answer: The strings use one specified regional time zone, and the source guarantees that no event falls in a skipped or repeated local-time interval.
Whenever you work with local timestamps in R, the core danger is ambiguity at DST boundaries: one local clock string can map to two real-world instants (during a "fall back" repeat), or zero instants (during a "spring forward" skip). Your elapsed-time calculation is only defensible if you can guarantee a clean one-to-one mapping between every string and a unique UTC instant.
That's exactly what D provides. If the source specifies a single regional time zone and guarantees no event falls in a skipped or repeated interval, then as.POSIXct(x, tz = "America/Chicago") (or whichever zone applies) unambiguously converts every string to a UTC instant, and subtracting two instants gives correct elapsed time. Both conditions together close the loophole.
A is wrong because it contradicts the premise — the passage explicitly calls these local times, not UTC. Claiming they're UTC doesn't make it so, and as.POSIXct() absolutely uses the computer's time zone when none is specified, so that second clause is also false.
B is wrong because row order cannot resolve the ambiguity alone. During a "fall back," two consecutive rows could both show 01:30 representing instants one hour apart — or the reverse order. Sorting tells you sequence, not which UTC instant each string represents.
C is wrong because DST transitions break the one-to-one mapping; that's the whole problem. Claiming transitions "always preserve" it is factually incorrect and the exact misconception this question is testing.
Study tip: In R, always supply an explicit tz argument to as.POSIXct() for local timestamps, and never assume DST regions are safe without confirming no events land in transition windows.
- Which assumption is needed to interpret the result as an estimate of population average income rather than merely the average among respondents?
Answer: Within the groups addressed by the weighting adjustment, income nonresponse is not systematically related to unobserved income, and NA does not mean zero income.
Whenever you see a question about weighted estimation with missing data, your first instinct should be to think about missing data mechanisms — specifically, whether the missingness is random within the groups the weights already account for.
The function weighted.mean(income, survey_weight, na.rm = TRUE) removes NA values and reweights the remaining observations. For this to recover the true population mean, you need the nonrespondents' income distribution to be similar to respondents' within each weighting cell (region × household size). This is the Missing At Random (MAR) assumption, conditional on the variables used in weighting. You also need NA to genuinely mean "not observed," not "zero" — otherwise exclusion introduces a different bias. That's exactly what A states, making it the correct answer.
B is wrong because it treats na.rm = TRUE as a mathematical guarantee of unbiasedness. Removing NAs is simply a computational step — it says nothing about whether the missing values were random. Systematic nonresponse can absolutely distort a weighted estimate.
C is wrong on two counts: it falsely assumes NA means zero income, and it incorrectly claims survey weights can compensate for omitted income values the weights weren't designed to address.
D is wrong because having positive weights for all respondents doesn't rescue the estimate if nonresponse is driven by unobserved income. A high-earner who refuses to answer is simply absent from the data — no weight fixes that.
A useful rule of thumb: **weights adjust for who is sampled, not for why some people don't answer**. Always ask what the weights actually control for before interpreting the estimate as population-level.
- Which assumption should accompany a calculation of mean package mass in kilograms?
Answer: System labels reliably identify units, System B values are converted from pounds to kilograms before averaging, and NA means unknown mass.
When combining data from multiple measurement systems, you must ask three questions before any calculation: Are the units consistent? How were missing values handled? What does "missing" actually mean? This question tests all three at once.
The only statistically valid approach is B. It correctly identifies that the source column is trustworthy for distinguishing units, converts System B's pound values to kilograms using \text{kg} = \text{lbs} \div 2.205} before averaging, and treats NA as genuinely unknown — meaning you should use na.rm = TRUE carefully and acknowledge that those packages are excluded, not assumed to be zero.
A is dangerously wrong because R stores both kilograms and pounds as the same numeric type. A single double column tells you nothing about real-world units — you'd be averaging apples and oranges (or kilograms and pounds), producing a meaningless result. Ignoring NA without acknowledgment compounds the error.
C gets the conversion order backwards. Averaging mixed-unit values first and converting afterward is mathematically invalid. The mean of 10 kg and 22 lbs is not a real quantity — you cannot convert a mean of incompatible units into anything meaningful.
D inverts the entire logic. Converting kilograms to pounds while leaving pounds unchanged would give you an all-pounds result, then mislabeling it as kilograms — a dangerous unit error that could go undetected downstream.
Study tip: Whenever you see merged datasets in R, always verify unit consistency before any aggregation. Unit errors are invisible to R — the language won't warn you, so the analyst must.
- Which documented assumption most adequately supports this treatment of missing values?
Answer: Both encodings mean unavailable temperature, the station cannot legitimately report 999 degrees Celsius, and neither encoding means zero.
When working with na.strings in R, you're making a deliberate data documentation decision: you're asserting that certain values carry no meaningful measurement and should be treated as NA. The critical question is always what assumption justifies that assertion, and that assumption must be both domain-specific and complete.
Both "" and "999" are mapped to NA by the import call, so the supporting assumption must explain why both encodings represent true unavailability — not a number, not zero, not a placeholder pending conversion. B does exactly this: it grounds the decision in the station's own specification (999°C is physically impossible as a real temperature report), confirms blank fields aren't zeroes, and treats both as genuinely missing. That's a fully documented, scientifically defensible assumption — making B correct.
A fails because it argues 999 should stay numeric for range checking, which directly contradicts mapping it to NA. If you're passing 999 into na.strings, you've already discarded it — you can't have it both ways.
C inverts the blank-field logic dangerously. Treating a blank as a zero-degree reading would silently inject false data into your analysis. Blanks indicate no transmission, not a measured zero.
D introduces a red herring: unit conversion is completely irrelevant to whether a value is missing. The na.strings argument acts during import, before any transformation, and NA propagates through unit conversion regardless.
A useful study habit: when you see na.strings, ask yourself "what documented, domain-specific fact justifies each value being declared missing?" The best answer is always the one that covers all encoded values with a coherent, real-world rationale.
