Comments (7)
Perhaps a useful rule of thumb is to discuss in context of the sampling uncertainy. E.g. With 100 cases, the fatality risk estimate will, roughly speaking, have a 95% confidence interval ±10% of the mean estimate (binomial CI). So if we have >100 cases with expected outcomes on a given day, we can get reasonable estimates of the time varying CFR. But if we only have >100 cases over the course of the whole epidemic, we probably need to rely on the static version that uses the cumulative data.
from cfr.
Thanks @avallecam - the two functions are aimed at providing different functionalities.
-
cfr_rolling()
shows what the estimated CFR would be on each day of the outbreak, given that future data on cases and deaths is not available at the time. The final value ofcfr_rolling()
estimates is expected to be identical to the value ofcfr_static()
on the same data. This is not sensitive to the length of the outbreak (afaik). -
cfr_time_varying()
calculates the CFR over a moving window, and helps to understand changes in CFR due to changes in the epidemic, e.g. due to a new variant or due to increased immunity from vaccination. It performs poorly for short outbreaks as it discards some data at the start (theburn_in
), discards data at the end (due to the size ofsmoothing_window
) (both cases returnNA
), and also returnsNA
where deaths < estimated deaths and estimated deaths > 0. I think that the reason it is less suitable for smaller outbreaks is that these conditions are more common there, returning moreNA
s.
from cfr.
Useful clarification.
cfr_rolling()
shows the daily cumulative sum of cases used bycfr_static()
- about
cfr_time_varying
we could possibly say that it is sensitive to the length, given the discard of data fromburn_in
andsmoothing_window
, and the size of the deaths in the outbreak, given the estimated deaths constraint that it needs.
About the different trends that we get from the two methods, any suggestions about how to discuss it?
from cfr.
About the different trends that we get from the two methods, any suggestions about how to discuss it?
I think the key is to discuss the static and time varying methods and where they apply. The rolling method is perhaps more useful to check whether an outbreak's CFR estimate has stabilised. The rolling and time-varying methods aren't really comparable, so I wouldn't really discuss them together. Is it worth mentioning some reasons not to interpret the rolling estimate in relation to the time-varying one?
from cfr.
Thanks @adamkucharski! @avallecam, did you have any specific suggestions for where these clarifications should be added?
from cfr.
did you have any specific suggestions for where these clarifications should be added?
In the tutorial episode drafted, we include the clarifications shared here. Please, see that section in the working branch (edit suggestions welcome in working PR). At the end, we refer to the vignette on cfr_time_varying()
.
Although this outbreak size detail is mentioned briefly in the get started vignette, probably it would be informative to complement the current vignette showing that point in particular, on how the time-varying method performs under different sizes of cases per day (then, our reference from tutorials to vignette could be more specific). If this content gets too long, we can consider another vignette. If appropriate, this could be based on the reprex above.
from cfr.
Closed as answered, and this will be addressed by #128
from cfr.
Related Issues (20)
- Release cfr 0.1.0 HOT 2
- Consider merging `cfr_static()` and `cfr_rolling()` HOT 3
- Single convolution function for cases and PMFs HOT 1
- Consider `optim()` in `estimate_severity()` HOT 10
- Test for bias due to index shifting
- Motivate use of continuous delay distributions HOT 3
- Clarify when time-varying CFR applies HOT 5
- Explore options for weekly data HOT 6
- End of year cleanup
- add comma when using an `epidist` class object in `density()` HOT 3
- Add DPG badge
- Add message to cfr_rolling()
- CFR stands for Risk or Ratio? HOT 4
- replace `cases` by `confirm` for API consistency HOT 7
- > Thanks - so not related to the delay_density issue then? HOT 1
- Rename CFR function files
- Rename `known_outcomes()`
- Different return values across `cfr_*()` functions HOT 1
- `cfr_rolling()` fails when cumulative case number is 0 HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cfr.