-
Notifications
You must be signed in to change notification settings - Fork 3
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
Create longer form DDD vignette #48
Comments
This looks good to me. I think we might also want to consider:
|
I agree with @seabbs. Structure of the issue looks great. Visualizing the delay and generating posterior predictions are both in scope and should be included.
From our previous discussion, it sounded like the main blocker is that @seabbs would like the function used to convert the fitted pdf into a double censored (discrete) pmf to live in another yet-to-be-created package that doesn't require heavy stan dependencies. I'd propose just putting that function here for now or using an existing one from epinow2 or epinowcast until it can be moved? |
Yes either this or just using a placeholder function name for now and seeing where we are when we get to this point |
@athowes, here's the relevant function from epinowcast: https://github.com/epinowcast/epinowcast/blob/e9a7a7cc9c2e02bab20491edea3bc0dc5ec2899b/R/model-module-helpers.R#L297 |
Generic question: after recieving feedback where I think I'd like to update the scope of the issue, is it better that I update the initial issue, or that I note that I'm updating the issue in a comment in the thread? Adding:
Nice to have / with pseduocode:
|
I would typically update the initial issue with a note that I have done so and a link to the comment etc that motivated it. Not sure if there is a good practice guide for this but I like it as it makes it easier to find info when coming from a PR |
You can plot the fit to the actual data as eval metric. We use this in the @parksw3 paper for the ebola case study I believe |
I feel there are several other ways we can visualize the posterior. In our paper, we show truncated mean vs empirical delay, but other people might prefer to see pdfs and cdfs? |
Goal
This issue is for creation of a longer form vignette. This vignette would show a fuller picture of the package's potential functionality than the getting started vignette. Here, DDD refers to documentation-driven development (#43).
Context
The package is undergoing refactoring. As part of the refactoring we will be editing existing functions and adding new functions. To help us make these choices we need to determine which user workflows we would like to support. Once way to do this is to start to write out those user workflows. This vignette serves as one way to do this.
Required features
.Rmd
showing a longer form use of theepidist
packageOut of scope
Related documents
The text was updated successfully, but these errors were encountered: