Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor simulation functions #42

Closed
joshwlambert opened this issue Jan 4, 2024 · 1 comment
Closed

Refactor simulation functions #42

joshwlambert opened this issue Jan 4, 2024 · 1 comment
Milestone

Comments

@joshwlambert
Copy link
Member

Upon reading more of the code, I think I understand the rationale behind this separation: .sim_bp_linelist() create columns relevant for contacts and linelist while .sim_clinical_linelist() focuses on columns only relevant for the linelist.
I suspect these wrappers were created to reduce duplication across the sim_*() functions.

However, I don't think the goal is fully achieved as there is still a lot of duplication.

I would like to consider a different refactoring approach:

All sim_*() functions call a sim_internal() function:

sim_internal <- function(out = c("linelist", "contacts")) {

  out <- match.arg(out, several.ok = TRUE)

  # arg checking

  # simulate branching process
  # ...

  if ("linelist" %in% out) {
    # simulate linelist specific columns
  }
  if ("contacts" %in% out) {
    # simulate contact specific columns
  }

 # return df or list depending on out value
}

This doesn't result in more nesting since we can then remove the sim_utils and sim_contact_tbl() functions and call directly the add_col function.

I find it clearer because you don't have to guess where a specific column will be computed ("is it .sim_bp_linelist() or .sim_clinical_linelist()?"). Everything happens clearly in the sim_internal() function and the exported sim_*() functions are just very thin wrappers around it.

If performance is not an issue, this sim_internal() could also be sim_outbreaks(). sim_linelist() and sim_contacts() would then just keep only the relevant df and drop the other.

Originally posted by @Bisaloo in #33 (comment)

@joshwlambert
Copy link
Member Author

The upcoming v0.2.0 release is primarily changing to the simulation model, with most changes internal and not user facing. Therefore it seems sensible to include these requested changes as part of the v0.2.0 release given the similarity in scope and tackling straight away.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant