Skip to content
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

Open
athowes opened this issue May 20, 2024 · 9 comments · May be fixed by #52
Open

Create longer form DDD vignette #48

athowes opened this issue May 20, 2024 · 9 comments · May be fixed by #52
Assignees
Labels
documentation Improvements or additions to documentation enhancement New feature or request

Comments

@athowes
Copy link
Collaborator

athowes commented May 20, 2024

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

  • An .Rmd showing a longer form use of the epidist package
  • Exact details of the use remain to be determined. Writing now, I anticipate the vignette to include:
    • Loading the Ebola data
    • Transforming the Ebola data to be compatible with the model function
    • Fitting a model to the Ebola data with a lognormal delay
    • Fitting a model to the Ebola data with a gamma delay
    • Extracting posterior distributions from the lognormal and gamma models
    • Comparing the fitted distributions with the two different models

Out of scope

  • This issue could be considered resolved when the longer form vignette is written, even if the functions are not all currently working. That is, it is not required that the vignette all runs to consider this issue complete, just that we are happy with the proposed functions and workflow.

Related documents

@athowes athowes self-assigned this May 20, 2024
@athowes
Copy link
Collaborator Author

athowes commented May 20, 2024

Requesting feedback on 1. issue design, and 2. contents of issue @kgostic @seabbs @parksw3

@seabbs seabbs added documentation Improvements or additions to documentation enhancement New feature or request labels May 20, 2024
@seabbs
Copy link
Contributor

seabbs commented May 20, 2024

This looks good to me. I think we might also want to consider:

  • Visualising the delay data as an initial step
  • Posterior predictions for a single or both models (may be included in your above)
  • Translating a fitted distribution to a pmf (this is most likely of my suggestions to be out of scope here)

@kgostic
Copy link
Collaborator

kgostic commented May 20, 2024

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.

Translating a fitted distribution to a pmf (this is most likely of my suggestions to be out of scope here)
I would also like this to be in scope! I think it's important.

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?

@seabbs
Copy link
Contributor

seabbs commented May 20, 2024

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

@kgostic
Copy link
Collaborator

kgostic commented May 20, 2024

@athowes
Copy link
Collaborator Author

athowes commented May 21, 2024

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:

  • Visualising the delay data as an initial step
  • Posterior predictions for a single or both models (this clarifies what I had "extracting posterior distributions" -- still unclear exactly what is being predicted here)

Nice to have / with pseduocode:

  • Translating a fitted distribution to a PMF

@athowes athowes linked a pull request May 21, 2024 that will close this issue
9 tasks
@seabbs
Copy link
Contributor

seabbs commented May 21, 2024

fter recieving feedback where I think I'd like to update the scope of the issue

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

@seabbs
Copy link
Contributor

seabbs commented May 21, 2024

Posterior predictions for a single or both mod

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

@parksw3
Copy link
Collaborator

parksw3 commented May 22, 2024

Posterior predictions for a single or both models (this clarifies what I had "extracting posterior distributions" -- still unclear exactly what is being predicted here)

You can plot the fit to the actual data as eval metric. We use this @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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants