R book review walkthrough

[robchallen]

Version control section

I don;t tend to follow the branch commit merge workflow when working with Git because I am too lazy, and there are very few benefits of branches (and some quite notable complexities) when you are solo developing.

I wonder whether the simplest commit to main and push changes centrally should be the first step offering well defined restore points and online backup, then the branch and merge for real collaboration introduced as a second step.

Also you could for R Studio simplify they Git clone instructions by using the File > New Project > Version Control > Git functions in R Studio which prevents you from having to find the terminal and could make that easier.

[robchallen]

Environments:

Maybe to consider the use of pak and in particular e.g. pak::pkg_sysreqs("igraph")

consider document the options(repos=...) format for switching to repository sources including the date based posit repos
possibly in the .RProfile file.

[robchallen]

Code Organisation

consider downplaying role of R6. Maybe overkill for users?

[robchallen]

Input Data Management

• Probably worth talking about the location of sensitive data outside of Git. Its a bugger to undo a commit if you accidentally push a load of sensitive data to github. Speaking on behalf of a friend.

[amyheather]

R6 Classes

From discussion with Rob, I'm thinking potential approach may be:

• Remove mention from R6 classes from book
• Where I have used them, wrap in functions

For reference, the only place I have used R6 classes is in code for choosing the number of replications.

https://pythonhealthdatascience.github.io/des_rap_book/pages/guide/output_analysis/n_reps.html#automated

There are three R6 classes: WelfordStats, ReplicationTabuliser and ReplicationsAlgorithm.

Why are they classes? Because I was converting from Python package sim-tools which uses classes, so I just followed the same logic.

In terms of readers of the book and what they need to understand - they don't really need to understand R6 - we suggest they use functions as that's typical to R - and here, they just use them like below, but could just have a wrapper.

# Set up algorithm
alg <- ReplicationsAlgorithm$new(
  param = create_params(warm_up_period = 10000L,
                        data_collection_period = 10000L),
  metrics = metrics
)

# Run algorithm
alg$select()

# View recommended number of replications
alg$nreps

UPDATE: Do also talk about quite alot on the parameter validation page.

[robchallen]

Parameters from script

I would in my own analysis always keep parameters in a dataframe which I would load from a CSV file.

I would do this because:

• I am certainly going to want to have multiple parameter sets.
• I am likely to want to change them, or generate them using another process.

I would write a function that uses the column names as parameter names.

• I do this so I can document each parameter in roxygen.

You can then either use purrr::pmap to run the functions or extract one row and use do.call to put data into the function as a named list.

params = readr::read_csv("params_file")
# or
params = dplyr::tribble(
~ param1 ,    ~ param2,
1,                    2,
3,                    4
)

#' Documentation ...
sim = function(param1, param2) { return(param1 + param2) }
results = params %>% purrr::pmap(sim)

# alternatives you can do this manually but less R like
for (i in seq_len(nrow(params)) {
    result = do.call(sim, params[i,])
}

# or:
results = lapply( seq_len(nrow(params)),  function(i) {do.call(sim, params[i,]) )
}

This purrr approach has a lot of benefits in terms of potential for parallelisation
You can also wrap the results into the same dataframe so that the results can be presented alongside the parameters using list columns.

Another example:

library(tidyverse)
library(future)

# future::plan(multisession, workers = 8)

params = iris %>% 
  select(param1 = Petal.Width, param2 = Petal.Length) 


sim = function(param1, param2) {
  Sys.sleep(time = 0.2)
  return(dplyr::tibble(
    samples1 = rnorm(100, param1, param2),
    samples2 = rnorm(100, param2, param1),
  ))
}

# e.g. sim(1,2)

# run sim for each row and store results:
# params$results  = params %>% purrr::pmap(sim)
# or

# params2 = params %>% dplyr::mutate(results = furrr::future_pmap(., sim,.progress = TRUE))
params2 = params %>% dplyr::mutate(results = purrr::pmap(., sim,.progress = TRUE))

params2 %>% glimpse()

params3 = params2 %>% dplyr::mutate(
  summ_s1 = purrr::map(results, ~ mean(.x$samples1)),
  summ_s2 = purrr::map(results, ~ mean(.x$samples2))
  # could have done this as another function which maybe is cleaner
)

params3 %>% glimpse()

[amyheather]

Parameters separate from from model

From discussion with Rob, suggested just getting rid of parameter function altogether.

That eradicates the issue on the parameter validation page.

Instead, just directly have inputs fed into the model. Can use do.call() to feed it a list of those inputs.

As parameter function not serving purpose / introduces potential for error that can avoid by doing direct into model.

Also, would suggest always importing parameters from a dataframe, and not having them defined within the script.

And having inputs alongside outputs using purrr pmap

See code example above

Its the way Rob would suggest doing it to people

It's quite a tidyverse centric approach, not baseR