Bird
Raised Fist0
R Programmingprogramming~5 mins

R6 classes in R Programming - Time & Space Complexity

Choose your learning style10 modes available
Time Complexity: R6 classes
O(n)
Understanding Time Complexity

When using R6 classes in R, it's important to understand how the time to run methods grows as the data or operations increase.

We want to see how the cost changes when calling methods on R6 objects with different input sizes.

Scenario Under Consideration

Analyze the time complexity of the following R6 class method.


library(R6)

MyClass <- R6Class("MyClass",
  public = list(
    data = NULL,
    initialize = function(vec) {
      self$data <- vec
    },
    sumData = function() {
      sum(self$data)
    }
  )
)

obj <- MyClass$new(1:1000)
obj$sumData()

This code defines an R6 class that stores a vector and sums its elements when asked.

Identify Repeating Operations

Identify the loops, recursion, array traversals that repeat.

  • Primary operation: Summing all elements in the stored vector.
  • How many times: The sum function internally goes through each element once.
How Execution Grows With Input

As the vector size grows, the time to sum all elements grows roughly in direct proportion.

Input Size (n)Approx. Operations
1010 additions
100100 additions
10001000 additions

Pattern observation: Doubling the input roughly doubles the work done.

Final Time Complexity

Time Complexity: O(n)

This means the time to sum the data grows linearly with the number of elements stored in the object.

Common Mistake

[X] Wrong: "Calling a method on an R6 object always takes the same time no matter the data size."

[OK] Correct: The method's work depends on the data inside the object. If it processes all elements, time grows with data size.

Interview Connect

Understanding how methods inside R6 classes scale with data size helps you write efficient code and explain your design choices clearly.

Self-Check

"What if the sumData method only summed the first 10 elements? How would the time complexity change?"

Practice

(1/5)
1. What is the main purpose of using R6Class() in R?
easy
A. To create plots and visualizations
B. To perform statistical tests on data
C. To import data from external files
D. To create a class that groups data and functions together

Solution

  1. Step 1: Understand the role of R6Class()

    R6Class() is used to define a class that can hold both data (fields) and functions (methods) together.
  2. Step 2: Compare with other options

    Creating plots and visualizations, performing statistical tests on data, and importing data from external files are unrelated tasks, not the purpose of R6Class().
  3. Final Answer:

    To create a class that groups data and functions together -> Option D
  4. Quick Check:

    R6Class() = class with data and methods [OK]
Hint: R6Class groups data and actions in one place [OK]
Common Mistakes:
  • Thinking R6Class is for data analysis only
  • Confusing R6Class with plotting functions
  • Assuming R6Class imports data
2. Which of the following is the correct way to define a method inside an R6 class?
easy
A. methods = { my_method <- function() { print(self$field) } }
B. methods = list(my_method = function() { print(self$field) })
C. method <- function() { print(self$field) }
D. methods = function(my_method) { print(self$field) }

Solution

  1. Step 1: Recall R6 method syntax

    Methods are defined inside a list with names as method names and values as functions, e.g., methods = list(name = function() {...}).
  2. Step 2: Check each option

    methods = list(my_method = function() { print(self$field) }) correctly uses a list with a named function. The other options do not follow the required list structure.
  3. Final Answer:

    methods = list(my_method = function() { print(self$field) }) -> Option B
  4. Quick Check:

    Methods = list of named functions [OK]
Hint: Methods must be in a named list inside R6Class [OK]
Common Mistakes:
  • Defining methods as a single function instead of list
  • Using assignment inside methods block incorrectly
  • Omitting the list() wrapper
3. What will be the output of this R code?
Person <- R6Class("Person",
  public = list(
    name = NULL,
    initialize = function(name) {
      self$name <- name
    },
    greet = function() {
      paste0("Hello, ", self$name, "!")
    }
  )
)
p <- Person$new("Anna")
p$greet()
medium
A. NULL
B. Error: object 'self' not found
C. "Hello, Anna!"
D. "Hello, name!"

Solution

  1. Step 1: Understand object creation and initialization

    The class Person has a field 'name' set during initialization with self$name <- name. The object p is created with name "Anna".
  2. Step 2: Evaluate the greet method

    The greet method returns paste0("Hello, ", self$name, "!"), which becomes "Hello, Anna!" for p.
  3. Final Answer:

    "Hello, Anna!" -> Option C
  4. Quick Check:

    p$greet() = "Hello, Anna!" [OK]
Hint: self$name holds the name; greet returns greeting string [OK]
Common Mistakes:
  • Expecting NULL because name is NULL initially
  • Confusing self with private or global variables
  • Thinking greet prints instead of returns
4. Identify the error in this R6 class definition:
Car <- R6Class("Car",
  public = list(
    speed = 0,
    accelerate = function() {
      speed <- speed + 10
    }
  )
)
c <- Car$new()
c$accelerate()
c$speed
medium
A. The method should use self$speed, not speed alone
B. The class name must be lowercase
C. The accelerate method must return speed explicitly
D. The speed field cannot be initialized to 0

Solution

  1. Step 1: Check variable usage inside method

    Inside accelerate(), speed <- speed + 10 updates a local variable speed, not the field. It should be self$speed to update the object's field.
  2. Step 2: Verify other options

    Class names can be uppercase, methods don't need explicit return, and initializing speed to 0 is valid.
  3. Final Answer:

    The method should use self$speed, not speed alone -> Option A
  4. Quick Check:

    Use self$ to access fields inside methods [OK]
Hint: Use self$ to access or change fields inside methods [OK]
Common Mistakes:
  • Forgetting self$ prefix for fields
  • Assuming local variable changes affect fields
  • Thinking class names must be lowercase
5. You want to create an R6 class BankAccount with a field balance starting at 0 and methods deposit(amount) and withdraw(amount). The withdraw method should not allow the balance to go below zero. Which code snippet correctly implements this?
hard
A. BankAccount <- R6Class("BankAccount", public = list( balance = 0, deposit = function(amount) { self$balance <- self$balance + amount }, withdraw = function(amount) { if (self$balance >= amount) { self$balance <- self$balance - amount } } ) )
B. BankAccount <- R6Class("BankAccount", public = list( balance = 0, deposit = function(amount) { balance <- balance + amount }, withdraw = function(amount) { balance <- balance - amount } ) )
C. BankAccount <- R6Class("BankAccount", public = list( balance = 0, deposit = function(amount) { self$balance <- amount }, withdraw = function(amount) { self$balance <- self$balance - amount } ) )
D. BankAccount <- R6Class("BankAccount", public = list( balance = 0, deposit = function(amount) { self$balance <- self$balance + amount }, withdraw = function(amount) { self$balance <- self$balance - amount } ) )

Solution

  1. Step 1: Check deposit method correctness

    Deposit should add amount to self$balance. Some options do this correctly; others do not use self$ or overwrite balance incorrectly.
  2. Step 2: Check withdraw method logic

    Withdraw must check if balance >= amount before subtracting to avoid negative balance. Only BankAccount <- R6Class("BankAccount", public = list( balance = 0, deposit = function(amount) { self$balance <- self$balance + amount }, withdraw = function(amount) { if (self$balance >= amount) { self$balance <- self$balance - amount } } ) ) has this check.
  3. Final Answer:

    The code snippet with self$balance updates and balance check before withdrawal -> Option A
  4. Quick Check:

    Use self$ and check balance before withdrawal [OK]
Hint: Withdraw must check balance before subtracting [OK]
Common Mistakes:
  • Not using self$ to update balance
  • Overwriting balance instead of adding
  • Allowing negative balance without check
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard