Giter Site home page Giter Site logo

Comments (7)

adamkucharski avatar adamkucharski commented on June 26, 2024 2

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.

pratikunterwegs avatar pratikunterwegs commented on June 26, 2024

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 of cfr_rolling() estimates is expected to be identical to the value of cfr_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 (the burn_in), discards data at the end (due to the size of smoothing_window) (both cases return NA), and also returns NA 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 more NAs.

from cfr.

avallecam avatar avallecam commented on June 26, 2024

Useful clarification.

  • cfr_rolling() shows the daily cumulative sum of cases used by cfr_static()
  • about cfr_time_varying we could possibly say that it is sensitive to the length, given the discard of data from burn_in and smoothing_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.

pratikunterwegs avatar pratikunterwegs commented on June 26, 2024

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.

pratikunterwegs avatar pratikunterwegs commented on June 26, 2024

Thanks @adamkucharski! @avallecam, did you have any specific suggestions for where these clarifications should be added?

from cfr.

avallecam avatar avallecam commented on June 26, 2024

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.

pratikunterwegs avatar pratikunterwegs commented on June 26, 2024

Closed as answered, and this will be addressed by #128

from cfr.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo 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.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.