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

Forecast function for EpiAware #243

Open
SamuelBrand1 opened this issue May 29, 2024 · 5 comments
Open

Forecast function for EpiAware #243

SamuelBrand1 opened this issue May 29, 2024 · 5 comments
Labels
enhancement New feature or request EpiAware

Comments

@SamuelBrand1
Copy link
Collaborator

Current state of code

As per #239 we have a neat forecast function for models which have had inference on some time span $(1, T)$. The posterior chain can be used to condition the sampling of the model extended to a longer time span $(1, T + n)$. This is used in the analysis pipeline.

Lack of generality

The problem here is that under the hood there are hard coded options, which reflect our analysis plan but are too specific to promote this function to EpiAware.

Pain points:

  • define_epiprob: hard codes in discretised Gamma distributions.
  • Lack of testing in a wider range of settings.

Proposal

If we can fix these pain points then we can add this nice functionality to EpiAware.

@SamuelBrand1 SamuelBrand1 added enhancement New feature or request EpiAware labels May 29, 2024
@SamuelBrand1
Copy link
Collaborator Author

Worth noting that this forecast approach works for our use case but is not general!

TuringLang/Turing.jl#2239 (comment)

@SamuelBrand1
Copy link
Collaborator Author

Does this

Worth noting that this forecast approach works for our use case but is not general!

TuringLang/Turing.jl#2239 (comment)

suggest that we move towards not having vectorised calls? e.g. no MvNormal calls?

@seabbs
Copy link
Collaborator

seabbs commented Jun 14, 2024

Yes. Do you know what implications this has (performance / limiting flexibility etc?)

@SamuelBrand1
Copy link
Collaborator Author

The main argument against would be AD performance; because known vector-form functions might have adjoints which are accessed rather than calculated.

@SamuelBrand1
Copy link
Collaborator Author

Flexibility would only be improved.

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

No branches or pull requests

2 participants