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

Time-varying parameters (i.e. conversion to latent variables) #600

Open
sbfnk opened this issue Mar 6, 2024 · 4 comments
Open

Time-varying parameters (i.e. conversion to latent variables) #600

sbfnk opened this issue Mar 6, 2024 · 4 comments

Comments

@sbfnk
Copy link
Contributor

sbfnk commented Mar 6, 2024

Once #504 and #525 are done this opens the option of extending the distribution interface to allow any parameter to vary over time. An interface for Gaussian processes could e.g. look like

delay <- GP(mean = Normal(mean = 5, sd = 1))

for mean reverting GPs or

delay <- GP(init = Normal(mean = 5, sd = 1))

for GPs on first differences

A similar interface could be created for random walks (RW).

@sbfnk
Copy link
Contributor Author

sbfnk commented Mar 6, 2024

Would require quite a few changes to the underlying model(s) as PMFs would turn from vectors into matrices.

@seabbs
Copy link
Contributor

seabbs commented Mar 6, 2024

We should have a chat at some point because this is feeling like interface -> internal vs epinowcast internals -> interface (i.e replicating the same functionality but in the other direction.

@seabbs
Copy link
Contributor

seabbs commented Feb 3, 2025

I was thinking on read it that this was out of scope but now I look at it I don't agree with past Sam. This seems like a great feature to add. If we do want it then I think we should either choose to do #765 and then this issue or this issue and then that one. I think the ordering should be based on how much we want the features + effort to implement. My read is that this would be potentially easier than #765 and hence we should have a stab it it first. I think if we do want to tackle this then I think the first step is to make some subissues to break this down into easier chunks as its quite a big/hard feature to add with a lot of dangerous edge cases IMO.

@sbfnk
Copy link
Contributor Author

sbfnk commented Feb 4, 2025

In terms of design, I'm thinking it would require making the params vectors arrays/matrices and then use these (with repeated elements if static and otherwise time-varying). Main steps I think would need doing are, I think.

  1. make GP/RW code more general
  2. make param vectors matrices
  3. integrate the two

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants