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

S3 structure refactor #70

Merged
merged 30 commits into from
Jun 6, 2024
Merged

S3 structure refactor #70

merged 30 commits into from
Jun 6, 2024

Conversation

athowes
Copy link
Collaborator

@athowes athowes commented Jun 3, 2024

Description

This is my branch for playing with the S3 refactor. So far:

  • Decomposed existing latent_truncation_censoring_adjusted_delay() into generics:
    • Data preparation generic epidist_prepare
    • Getting supplementary Stan code generic epidist_stancode
    • Priors (currently empty) generic epidist_priors
    • The formula object generic epidist_formula
    • The family object generic epidist_family
    • A fitting function generic epidist
  • Created methods for the epidist_ltcad class (an abbreviation of latent truncation censoring adjusted delay)
    • Calling obs_prep <- epidist_prepare(obs, model = "ltcad") then epidist(obs_prep) replicates the functionality of latent_truncation_censoring_adjusted_delay(obs)

Remaining questions

  • Is there a way to get set up with priors for epidist? This would be a feature extension i.e. making is easier for the user to provide their own priors. What about just letting them pass in brms priors?
  • How do the custom_stancode and family / formula generics interact?
    • Different families will need different custom_stancode
    • Will different formulas need different Stan code? I don't know. Perhaps not?
  • How difficult would it be to do this where the prepare generic is called as a part of the epidist fitting generic? i.e. in one step. If it's quite hard and limits what we can do, I'm fine to have the two-step process
  • I might like to move some of the functions "inside" epidist::epidist rather than have everything passed in as arguments. I guess this removes possible functionality from the user but simplifies things? Perhaps it's also going to be in some ways required if the custom_stancode is a function of some family object...
  • Light take: I think we should be approximately getting rid of the epidist_stancode method and putting the relevant Stan code and options to modify it in the other relevant methods. If a user really really wants to change the underlying Stan code a lot then they can generate it and modify it themselves rather than interfacing with it via passing long strings.

Closes #21.

Checklist

  • My PR is based on a package issue and I have explicitly linked it.
  • I have included the target issue or issues in the PR title in the for Issue(s) issue-numbers: PR title
  • I have read the contribution guidelines.
  • I have tested my changes locally.
  • I have added or updated unit tests where necessary.
  • I have updated the documentation if required.
  • My code follows the established coding standards.
  • I have added a news item linked to this PR.
  • I have reviewed CI checks for this PR and addressed them as far as I am able.

@athowes
Copy link
Collaborator Author

athowes commented Jun 4, 2024

Call with @seabbs:

  • Look at T[] notation in Stan (inbuilt truncation)
  • There is also cens notation, but it only works for single censoring but not double censoring
    • There might be a way around this using "cohort-based" model (this is how they are doing it in EpiAware)
  • as.class, is.class, validate.class, .. rather than prepare: I think this should be an issue after first PR getting the S3 functionality in
  • Models with overlapping plotting functionality
  • Adding in the Stan details for reproducibility is a good idea (and not hard). Done (just at the top) though arguably might want to indicate which chunks are from epidist:
> stancode
// generated with brms 2.21.0
functions {
  // code chunks used from epidist 0.0.0.9000
  • Getting rid of dry option if we document well and just provide fn: done, will document nicely later once I'm going over everything
  • The main thing the user would want to change is the likelihood -- to discuss later if we can think of any other viable changes
    • Specify the growth rate for all of the primary event priors. Prior influenced by underlying growth rate
  • Whether or not we can provide priors for custom parameters -- this might be quite hard and not worth it
  • Add issue for naming of models
    • Extra models: exact one, "solving an integral" one, ...

Next steps:

  • Getting rid of the Stan bit
  • Adding in the likelihood as string

Path to doing this:

  • First put the strings into the Stan code as is now
  • Move the family relevant Stan code into family method (can I get the string from something like lognormal(...) or will it be a string?)
  • Move the other Stan code into epidist.ltcad method

@athowes athowes self-assigned this Jun 4, 2024
@seabbs
Copy link
Contributor

seabbs commented Jun 4, 2024

My end of the call: This is looking really good.

Copy link
Contributor

@seabbs seabbs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall this looks good.

I would like some justification for the stan code inside epidist and I think we need a bunch of issues to address already discussed things (or discuss them more).

R/ltcad.R Show resolved Hide resolved
R/ltcad.R Show resolved Hide resolved
R/ltcad.R Show resolved Hide resolved
R/ltcad.R Show resolved Hide resolved
R/ltcad.R Show resolved Hide resolved
R/ltcad.R Show resolved Hide resolved
R/utils.R Show resolved Hide resolved
R/utils.R Outdated Show resolved Hide resolved
inst/stan/functions.stan Show resolved Hide resolved
@athowes athowes mentioned this pull request Jun 6, 2024
R/ltcad.R Show resolved Hide resolved
This was referenced Jun 6, 2024
@athowes
Copy link
Collaborator Author

athowes commented Jun 6, 2024

Thanks @seabbs!

Have:

@seabbs seabbs marked this pull request as ready for review June 6, 2024 12:19
Copy link
Contributor

@seabbs seabbs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice looks good. This seems like a really solid basis to be getting started with. Happy all comments are now issues.

@seabbs seabbs enabled auto-merge June 6, 2024 12:21
@seabbs seabbs added this pull request to the merge queue Jun 6, 2024
Merged via the queue into main with commit 9ef1961 Jun 6, 2024
1 of 8 checks passed
@seabbs seabbs deleted the s3-refactor branch June 6, 2024 12:21
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

Successfully merging this pull request may close these issues.

Propose architecture for gamma delays
2 participants