-
Notifications
You must be signed in to change notification settings - Fork 33
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
Deprecate get_incubation_period
and get_generation_time
due to reimplementation elsewhere
#390
Comments
Rather it was implemented but not taken forward/supported here due to lack of resources. For more detail If wanting to depreciate these parts of the package to streamline than a sensible option is to instead provide the current built-ins as example datasets. This could be sensible as due to lack of resourcing and above similar initiatives starting it is unlikely the database in package idea will be taken forward here and so the current estimates will only get more out of date. At the same time as making the incubation period and generation time estimates built-in examples it would be sensible to make a similar example for the reporting delay. Note that this change will break a large number of package implementations and so needs to be carefully broadcast. We should more than likely use |
get_incubation_period
and get_generation_time
get_incubation_period
and get_generation_time
due to reimplementation elsewhere
get_incubation_period
and get_generation_time
due to reimplementation elsewhereget_incubation_period
and get_generation_time
due to reimplementation elsewhere
I think it does via credible intervals (which could be converted to an standard deviation assuming a normal as used here) |
Another option would be to demonstrate the workflow a bit better from |
This would introduce another suggest/import throughout the package as we need something use in examples and lock the users into a workflow I am not sure we have enough information about to make a judgement call on. I would rather keep the workflow simple and clearly be example based. Once the landscape has matured we could have a vignette bringing together resources we like in order to signpost to users - its not clear to me what those are at the moment. |
I don't think there's a need to introduce another suggest/import (and agree they should be considered very carefully). What I meant was that instead of providing examples (i.e. here's an example distribution) it might be more useful (or perhaps complementary) to explain the workflow a bit better, where one really important part is the question of where I get my parameter estimates from (and what I need). Options being: literature, with caveats on how they're estimated / discretisation issues etc.; estimate ourselves if raw data is available (using e.g. internal methodology or dynamicaltruncation), etc. |
I don't think your suggestion will work when it comes to function examples, unit tests etc. Unless we want to manually specify "examples" in each which seems error-prone on the developer side. I think we do need to explain the workflow better but I am not that happy we have the tools to do so at the moment which is where the recent work on delay distributions comes in or the resources to do it well enough to be useful. I think this should be moved to another issue IMO as a vignette with this one being focussed on dropping the current |
This is where I'm unsure. In deprecating the
or
The first is simpler but possibly the second is more like what a user would do (in a workflow where the first step is to investigate appropriate parameters). I can see a case for both but don't have a fully formed opinion which one should be preferred. |
I like the latter aside from the fact we need to manually specify it everywhere and that is pretty error-prone and so should be avoided. The former is very common practice. We can put in some really strong warnings to people that it is just an example in the docs and point at the Epi CRAN task review for resources. |
The idea of having a parameter database didn't end up implemented here (and is now implemented in
epiparameter
and taken on further by the WHO). The corresponding functions can be removed and the default values replaced with examples.The text was updated successfully, but these errors were encountered: