<infection> accepts R as a distribution or samples

[pratikunterwegs]

This issue is to request that <infection> class objects should accept $R_0$ estimates as a distribution or as samples. Further, this could be from exisiting packages such as {EpiNow2}.

[rozeggo]

The goal of this is to allow uncertainty in some of the key epidemiological parameters into the model and outputs.

It is likely better to start with samples from a distribution, as EpiNow2 is a more complex package to run.

[adamkucharski]

Agree simple distribution input good starting point (e.g. vector of samples? Then could downsample to a give number of replications for the model, e.g. vector of length X to 100 in model). Could also be nice opportunity to integrate with epidist objects in epiparameter (which can then output functions that can be used exactly like pdfs - dnorm, dgamma etc. - or random draws, rnorm etc.)

[adamkucharski]

Have been exploring some options for implementation. Seems to me the key challenge is that we will need a wrapper to simulate multiple model outputs sampling from the distributional vector, and where is best place to put this wrapper.

I see (at least) a couple of possibilities:

1. Put wrapper inside epidemic functions. I.e. allow infection() to take vector arguments, then add a check inside new_infection to standardise any input vector (e.g. downsample to 100 draws by default). Then also edit epidemic_default_cpp() etc. to check whether the infection object has an vector entries, and if so put a loop around the simulation code to output an array (or another object with higher dimension) rather than df at the end.

Advantage: the complexity will be hidden from user, who just needs to decide whether to input numeric or vector into the infection object, and package will handle the rest

Disadvantage: will need to edit every epidemic model function to include these checks and wrapper, although would be scope to modularise in next way (e.g. function around model_arguments to output_to_df section of code)

2. Put wrapper outside epidemic functions. If users want to input a vector, maybe have an additional function they have to use to simulate multiple draws, e.g. epidemic_distribution(population,infection,intervention,...,model=epidemic_default_cpp). Then add a quick check inside new_infections to just take first entry if user inputs vector, so it doesn't break existing code.

Advantage: existing models untouched so can be used directly, with epidemic_distribution doing the hard work

Disadvantage: bit clunkier for user, as they'll need to decide whether or not to use epidemic_distribution. Although perhaps this isn't massive obstacle, and would prevent additional complexity inside the model code, which would in turn might it harder for people to customise in future.

My initial preference would be (2), but keen to hear if have missed any obvious considerations.

[pratikunterwegs]

So this wrapper could be a good candidate for functionality that should be in {scenarios}?

[adamkucharski]

Yep, likely to be overlap, although I guess main use cases in scenarios for low dimensional possibilities (e.g. 5 different intervention parameter scenarios that can be compared, rather than 100 realisations of the sample parameter set with uncertainty). I'll have a dig around in scenarios to see if theres any functionality that could be used as a starting point – maybe run_scenario.scenario?

In any case, would be handy for user to be able to stick a vector in the infection object, then pick and choose what they do next. Also, thinking about it, could set up new_infection to just take the mean of vector as default, which would be more elegant for sensible default outputs.

[pratikunterwegs]

Yep, I think {scenarios} could handle parameter uncertainty as well as interventions options, but yes, could also stick this into the <infection>.

[rozeggo]

Great. I think we did decide that the parameter uncertainty should be handled by scenarios (or at least not in epidemics) so good to see convergent thinking on this

[adamkucharski]

Sketched out a vignette with EpiEstim, epiparameter and epidemics (with the final function very rough, and perhaps sitting better as a modified scenarios function): https://github.com/epiverse-trace/epidemics/blob/parameter-distributions/vignettes/parameter_uncertainty.Rmd

Also made me realise that having some nicely integrated plotting functions would be helpful, as thinking through how to plot arrays (e.g. showing different trajectories while summing over different groups etc.) will become more cumbersome for users.

[pratikunterwegs]

Thanks a lot @adamkucharski - will take a look now and keep in mind that this could fit well in {scenarios} too.

Regarding plotting, @joshwlambert is looking into the related issue #98, so a similar approach might work - will look into the possibilities.

[pratikunterwegs]

Superseded by #140 which removes the <infection> class - good to keep this discussion in mind/going, perhaps in the repo Discussions tab.