R Control Flow Exercises: 18 if/else, Loop and switch Problems

Explanation: In R, if is an expression that returns the value of its matched branch, so you can assign its result directly without an intermediate print(). This is unusual compared with Python or Java where if is a statement. The expression form keeps grading logic tight; for vectorised pass/fail across many scores you'd reach for ifelse() instead, since scalar if errors when fed a length>1 logical.

Explanation: The branches are tested top to bottom, so ordering from highest cutoff to lowest is required: a 95 would otherwise match the first satisfied test, not the strictest one. The trailing else is the catch-all for anything under 60, including negatives or zero. For three or more buckets this stays readable, but past five branches you should prefer dplyr::case_when() or cut() with labelled breaks, which both express the buckets declaratively.

Explanation: || short-circuits: the moment the first operand is TRUE R never evaluates the second. That matters when the second is expensive (a database call, say) or when the second could itself error. Use || for scalar guards like this and reserve | for element-wise OR on vectors. A common bug is feeding || a length>1 vector, which raises an error in R 4.3+ and silently used only the first element in older versions.

Explanation: ifelse() is the vectorised twin of if/else: it accepts a logical vector and returns a vector of the same length, picking from the yes or no argument element-wise. It does not short-circuit, so both branches are fully evaluated; for that reason avoid it when one branch could error on certain inputs (use dplyr::if_else() which checks types more strictly, or case_when() for multiple buckets).

Explanation: case_when() walks its formulas top to bottom and the first match wins, so the second clause covers 1000 to 4999 without an explicit lower bound. The trailing TRUE ~ ... is the catch-all default: without it, rows above 5000 would become NA and you'd ship a bug. For two-way splits dplyr::if_else() is cleaner; reach for case_when() once you have three or more buckets or non-overlapping conditions on multiple columns.

Explanation: Putting is.na(Ozone) as the first clause and returning NA_character_ is the idiomatic way to keep missingness out of your buckets. Without it, case_when() would silently push NA rows into whichever branch the comparison evaluates to (and NA < 50 evaluates to NA, which means none of the clauses match and you get NA in the output anyway, but with no clear signal of intent). Being explicit documents the policy and stops a future maintainer from wondering whether the gap was deliberate.

Explanation: Preallocating with numeric(n) and writing into known positions is the right way to write a for loop in R because each c()/append() reallocates the entire vector, giving you O(n^2) behaviour. Of course (1:5)^2 is shorter, faster, and the idiomatic R way: reach for explicit for only when the next iteration genuinely depends on the previous one or when the body does side effects you cannot vectorise away.

Explanation: seq_along(mtcars) is safer than 1:ncol(mtcars) because it returns an empty integer for a zero-column data frame instead of 1:0 (which is c(1, 0) and would error). Using mtcars[[j]] extracts the column as a vector; mtcars[j] would give you a one-column data frame and mean() would warn. In production code prefer sapply(), vapply(), or colMeans() for numeric matrices: the loop here is a teaching tool, not the idiomatic choice.

Explanation: The trick is using which() to capture the row positions per subject and writing back to those exact indices, which preserves the original event order without sorting. The same result in tidy idiom is one line: dosing |> group_by(subject_id) |> mutate(cum_dose = cumsum(dose_mg)). Knowing both versions matters because longitudinal clinical pipelines often interleave loops (when the next-event logic depends on prior state) with group_by (when it does not).

Explanation: The condition is tested at the top of each pass, so the loop exits as soon as x crosses 1000 with the count already incremented. ceiling(log2(1000)) is 10, which matches: a while is the right tool whenever the number of iterations is implicit in a stopping condition rather than a known range. If the condition can never become false (a typo, perhaps) you have an infinite loop, so when in doubt add a hard iteration cap as a safety net.

Explanation: break exits the loop immediately, leaving everything after it in the current iteration unexecuted, which is exactly what you want for a first-crossing test: there is no point continuing once the answer is known. The equivalent vectorised form which(cumsum(rets) < -0.10)[1] is shorter but evaluates the whole series even when day 1 already breaches. For backtests over millions of paths the loop with break is often faster than the vectorised one, since the average breach happens long before the path ends.

Explanation: next jumps to the start of the next iteration without running the rest of the loop body, which is cleaner than wrapping the rest of the body in an if (!divisible) { ... } block. break and next always apply to the innermost loop, so in nested loops you must structure with sentinel flags or refactor into a function with an early return() when you need to bail out of the outer loop. The pair shows up constantly in batch jobs that must filter and stop, such as web scrapers honouring rate limits.

Explanation: switch() on a string matches the argument against the unnamed-or-named branches; the trailing unnamed expression (NA_integer_ here) is the default returned when nothing matches, which is how you defend against typos like "WANR". Unlike chained if/else it is constant-time and reads as a lookup table. The downside is that switch() with numeric input is positional, not value-based, so always coerce to character first if your codes happen to be numeric.

Explanation: Using stop() as the default branch turns an unknown name into a loud failure instead of silently returning NULL, which is what switch() does when there is no default. A more dynamic alternative is do.call(fn_name, list(x)) or match.fun(fn_name)(x), but switch() keeps the supported menu explicit at the call site, which is easier to read and to audit in a regulated reporting workflow.

Explanation: switch() shines when the dispatch keys are a closed enumeration like a unit catalogue: adding a new conversion is one line and the structure documents what is supported. For a fully extensible converter you'd register conversion functions in a named list and look them up with conversions[[code]](value), which is the idiomatic R version of the Strategy pattern. The cutoff between switch() and a function table is roughly five or six entries.

Explanation: Each && only evaluates its right operand if the left is TRUE. That ordering is intentional: testing length(x) == 1 before x > 0 prevents the value comparison from accidentally returning a length-2 logical that would crash an if later. & would not short-circuit and would also return a vector for vector inputs, which is wrong for a scalar guard. In R 4.3+ feeding && a non-length-1 vector raises an error, which is why ordering the length check first matters.

Explanation: Parentheses change everything: without them && binds tighter than || and R would still parse it correctly, but explicit grouping makes the policy auditable for a compliance reviewer. The short-circuit means that for the 99% of transactions under 10000 the %in% lookup never runs, which matters at high volume. In production you'd vectorise this for batch scoring with & and |, but for a per-row guard inside an apply loop or a service handler the scalar version is the right choice.

Explanation: The first operand of || is evaluated and if is.null(x) is TRUE the second operand is never touched, so all(is.na(NULL)) (which would be TRUE anyway, vacuously) is never reached. If you wrote is.na(x) || is.null(x) the order would matter for length>1 inputs since is.na() returns a vector; using all(is.na(x)) collapses it to a scalar so || is well-defined. This pattern, ordering cheap and safe checks first, is the foundation of robust R input validation.