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

Possibility to generalise probability distribution interface? #555

Open
joshwlambert opened this issue Feb 16, 2024 · 1 comment
Open

Possibility to generalise probability distribution interface? #555

joshwlambert opened this issue Feb 16, 2024 · 1 comment

Comments

@joshwlambert
Copy link

I've been taking a look through #504 and I really like the way distributions are specified and enable nesting for parameter uncertainty. I think this could be a nice interface to use in other packages (e.g. {epiparameter}), however, the main limitation of utilising the new features in #504 is the return type <dist_spec>. This seems quite specific to {EpiNow2} and would require reimplementing methods for the PDF, CDF, random number generation, etc.

What are the possibilities for inheriting an established distribution package (e.g. {distributional} or {distributions3}) and outputting these classes? These could be converted into <dist_spec> objects (using an EpiNow2::as_dist_spec() function).

@sbfnk
Copy link
Contributor

sbfnk commented Feb 20, 2024

Thanks for the suggestion - in principle I think it would be a really good idea to tap into some of these existing packages and with more distributions available rather than re-coding.

That said, within the EpiNow2 models, the main features we need are:

  • truncation (to be specified at the time of creating a distribution variable)
  • nesting (so that parameters can have uncertainty)

I'm not hugely familiar with {distributional} and {distributions3} but they both seem to require numeric parameters at the time of declaration so I'm not clear on how we could inherit from them and support nested parameters (where we don't know what value parameters might take at the time of declaration). We could output the classes for fixed parameters (and/or return them when using fix_dist) but that would be a fairly limited use case. Do you see any other way the interface could work?

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

2 participants