Introduction

Debugging is essential in programming for identifying and resolving errors effectively. Good debugging skills enhance productivity and ensure code reliability.

Topics Covered:

• browser()
• debugonce()
• traceback()
• recover()
• Debugging Shiny applications

The browser() Function

Purpose: Pauses execution, allowing interactive inspection.

Example:

my_function <- function(x) {
    y <- x + 10
    browser()
    z <- y / 2
    return(z)
}

my_function(5)

How to use:

• Inspect variables directly.
• Step through code (n for next, c to continue).

The debugonce() Function

Purpose: Debugs a function exactly once.

Example:

add_numbers <- function(a, b) {
    sum <- a + b
    return(sum)
}

debugonce(add_numbers)

add_numbers(3, "two")

How to use:

• Automatically enters debug mode at next call.
• Useful for inspecting unexpected errors inside functions.

The traceback() Function

Purpose: Identifies the call sequence leading to an error.

Example:

func_a <- function() { func_b() }
func_b <- function() { stop("An error occurred!") }

func_a()
traceback()

How to use:

• Quickly identifies problematic calls.
• Ideal for debugging nested functions.

The recover() Function

Purpose: Interactive debugging at the moment an error occurs.

Set this first:

options(error = recover)

f1 <- function(x) { f2(x) }
f2 <- function(x) { f3(x) }
f3 <- function(x) { stop("Unexpected error!") }

f1(10)

How to use:

• Provides menu to enter error environments.
• Inspect variables interactively.

Debugging Shiny Applications

Debugging Shiny can be challenging. Key approaches include:

• Use browser() in reactive contexts:

library(shiny)

ui <- fluidPage(
    numericInput("num", "Number:", 10),
    textOutput("result")
)

server <- function(input, output) {
    output$result <- renderText({
        browser()
        paste("Double:", input$num * 2)
    })
}

shinyApp(ui, server)

• Monitor logs and console outputs.

Summary: Key Takeaways

• browser() - Interactive inspection.
• debugonce() - Single-use debugging.
• traceback() - Error call sequence.
• recover() - Interactive error handling.
• Shiny apps - Combine browser(), logging, and output checks.

Effective debugging greatly enhances coding efficiency and reliability.

References

• R Debugging manual – CRAN
• Advanced R: Debugging R code
• RStudio: Debugging tools
• Shiny – Debugging guide

Example 1: Floating-Point Comparison Fails

.1 == .3 / 3

[1] FALSE

0.1 + 0.2 == 0.3

[1] FALSE

Why does this return FALSE?

• Due to how floating-point arithmetic works in computers, numbers like 0.1, 0.3, and 0.3 / 3 are stored in binary.

• Some decimal fractions cannot be represented exactly in binary, leading to tiny rounding errors. E.g.:

sprintf("%a", 0.1)

[1] "0x1.999999999999ap-4"

Explanation: - 0x indicates a hexadecimal number. - 1.999999999999a represents the normalised significand (mantissa) in base-16 (hexadecimal).

• p-4 is the exponent: p represents the power of 2 (exponent in base-2); 4 means the value is multiplied by 2⁻⁴.

• Even though mathematically .1 and .3 / 3 should be the same, their internal representations are not exactly equal.

Example 2: Inspecting the Actual Value Stored in Memory

.3 / 3

[1] 0.1

print(.3 / 3, digits=16)

[1] 0.09999999999999999

Explanation:

• The first output shows what R normally prints, which is rounded for display.

• The second output uses digits=16 to show more of the actual stored precision.

• This reveals that 0.3 / 3 is actually stored as 0.09999999999999999, not exactly 0.1.

Example 3: Using all.equal() Instead of ==

all.equal(.1, .3 / 3)

[1] TRUE

Why does this return TRUE?

• all.equal() does not check for exact equality but allows a small tolerance to account for floating-point errors.

• It is the preferred way to compare floating-point numbers in R.

• Do not use all.equal directly in if expressions—either use isTRUE(all.equal(...)) or identical if appropriate. If x and y are not equal, it returns a character string like: “Mean relative difference: 5.551115e-17”. The if statement expects TRUE or FALSE, but it receives a string, causing an error.

Example 4: Machine Epsilon & Adjusting Tolerance

.Machine$double.eps

[1] 2.220446e-16

all.equal(.1, .3 / 3, tolerance = 2.2e-17)

[1] "Mean relative difference: 1.387779e-16"

Explanation:

• .Machine$double.eps is the smallest possible difference that R can distinguish between two floating-point numbers.

• The default tolerance of all.equal() is sqrt(.Machine$double.eps), but we can adjust it manually if needed.

Example 5: Using round()

.1 == round(.3 / 3, digits = 16)

[1] TRUE

Explanation:

• round(..., digits = 16) forces R to round the computed value to 16 decimal places, reducing precision issues.
• The comparison 0.1 == round(0.3 / 3, digits = 16) now returns TRUE

📖 More details: The R Inferno

Memory Allocation in R

Memory management in R determines how objects are stored and how much space they occupy. Understanding how R allocates memory can help optimize performance, especially with large datasets.

library(lobstr)

x <- 5    # Stored as double
obj_size(x)  

56 B

y <- 5L   # Stored as integer
obj_size(y) 

56 B

x_vec <- rep(5, 1000000)   # Double vector
y_vec <- rep(5L, 1000000)  # Integer vector

obj_size(x_vec) 

8.00 MB

obj_size(y_vec)

4.00 MB

y_vec[2] = 5.0
obj_size(y_vec)  

8.00 MB

new_vec = lapply(y_vec, as.integer)
obj_size(new_vec) 

64.00 MB

new_vec[2] = 5.5
new_vec[1:3]

[[1]]
[1] 5

[[2]]
[1] 5.5

[[3]]
[1] 5

obj_size(new_vec) 

64.00 MB

Partial Matching in R

R allows partial matching of list elements, which can lead to unintended behaviour and difficult-to-debug errors.

test_function <- function(alpha = NULL, power = NULL, p = NULL, p0 = NULL) {
  user_defined <- list(alpha=alpha, power=power, p=p, p0=p0)
  user_defined <- Filter(Negate(is.null), user_defined)
  return(user_defined)
}

results = test_function(alpha=0.05, power=0.8)
print(results$p)  # Partial matching

[1] 0.8

print(results)

$alpha
[1] 0.05

$power
[1] 0.8

x = list(data = 2, power = 10)
x$p  

[1] 10

# Avoiding partial matching
options(warnPartialMatchDollar = TRUE)
x$p

Warning in x$p: partial match of 'p' to 'power'

[1] 10

x[["p"]]

NULL

Extending Subsetting with [[ Operator

Now that we’ve seen how to extract specific elements from function outputs, we can extend this idea to other cases where structured outputs require efficient subsetting.

Extracting values from structured objects often requires a combination of sapply(), lapply(), and [[ to efficiently access named list elements.

Example 11: Running Multiple t.test() and Extracting P-values

When running multiple tests, we can store results in a list and apply subsetting with [[.

set.seed(123)

data_list <- list(
  test1 = t.test(rnorm(10), rnorm(10)),
  test2 = t.test(rnorm(15), rnorm(15)),
  test3 = t.test(rnorm(20), rnorm(20))
)

p_values <- sapply(data_list, `[[`, "p.value")
print(p_values)

    test1     test2     test3 
0.7672027 0.7040755 0.4752422 

• data_list stores multiple t.test() results in a list.
• sapply(data_list, "[[", "p.value") extracts p.value from each result.
• Similarly, [[ can extract “conf.int”, “statistic”, or “parameter”, making it a powerful way to subset structured outputs.

📖 More details: Advanced R - Subsetting

Addressing

Efficient execution of computational tasks ensures that R processes run without blocking user interaction, effectively utilising system resources. The pyramid below illustrates the layers of computational efficiency in R programming.

Source: Selina Baldauf

Running Background Jobs in R

library(dplyr)

# Simulate a large dataset
set.seed(123)
large_data <- data.frame(
  id = 1:1e6,
  value = rnorm(1e6)
)

# Perform some computationally intensive operations
for(i in 1:15) {
  result <- large_data %>%
    group_by(id %% 10) %>%
    summarize(mean_value = mean(value))
  Sys.sleep(2) # Simulate long-running process
  cat("Running", i, "iteration.\n")
}

cat("Background job completed.\n")

Responsible Use of Resources

It’s crucial to balance computational demand to prevent overloading shared servers.

Example: Most non-HPC servers allow to run small to medium-sized tasks, so large-scale simulations should be managed carefully.

Best Practice:

• Use resource monitoring tools (top, htop) to check CPU usage before launching intensive computations.

• Run long processes inside terminal multiplexers (tmux, screen) to keep jobs running even if the connection is lost.

🔗 Useful Resources

📖 GNU Screen Documentation
📖 tmux: Terminal Multiplexer
📖 Monitoring System Usage in Linux: top command, htop command

Code Optimisation in R

library(profvis)

function_1 <- function(size) {
  large_list <- lapply(1:size, function(x) rnorm(5000))
  return(large_list)
}

function_2 <- function(iterations) {
  result <- 0
  for (i in 1:iterations) {
    Sys.sleep(0.1) 
    result <- result + i
  }
  return(result)
}

profvis({
  function_1(10000)
  function_2(30)
})

foo <- function(x) {
  browser()
  return(x * 2)
}

foo(10)

result <- NULL

for (i in 1:1000) {
  result[i] <- rnorm(1)^2 
}

library(foreach)
library(doParallel)

cl <- makeCluster(parallel::detectCores() - 1)
registerDoParallel(cl)

result <- foreach(i = 1:1000, .combine = 'c') %dopar% {
  rnorm(1)^2 
}

stopCluster(cl)