S3 structure refactor

[athowes]

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]

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

[seabbs]

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

[seabbs]

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).

[athowes]

Thanks @seabbs!

Have:

• Added issues
• Moved to Stan code as function, function as argument to epidist. Open to changing this in future User interaction with Stan code #78

[seabbs]

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