-
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
Change ARStep to reverse AR parameters #441
base: main
Are you sure you want to change the base?
Conversation
Try this Pull Request!Open Julia and type: import Pkg
Pkg.activate(temp=true)
Pkg.add(url="https://github.com/CDCgov/Rt-without-renewal", rev="440-ar-parameters-in-reverse-order", subdir="EpiAware")
using EpiAware |
@@ -81,23 +81,26 @@ Generate a latent AR series. | |||
damp_AR ~ latent_model.damp_prior | |||
ϵ_t ~ filldist(Normal(), n - p) | |||
|
|||
ar = accumulate_scan(ARStep(damp_AR), ar_init, σ_AR * ϵ_t) | |||
ar_step = ARStep(reverse(damp_AR)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For efficieny I don't think we want to do this at run time?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To avoid doing reverse
? That would suggest reversing at the constructor level I think.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
e.g. we add a rev_damp_prior
field to AR
and have damp_AR ~ latent_model.rev_damp_prior
. Obvs we could just reverse damp_prior
but that might get confusing for users?
@seabbs had a good shout about not doing the reverse at run time. I've added a |
Nice change. I think we should pause on this until #438 is in (ideally today) as that changes the names and structure of a lot of the AR model. |
Benchmark resultJudge resultBenchmark Report for /home/runner/work/Rt-without-renewal/Rt-without-renewalJob Properties
ResultsA ratio greater than
Benchmark Group ListHere's a list of all the benchmark groups executed by this job:
Julia versioninfoTarget
Baseline
Target resultBenchmark Report for /home/runner/work/Rt-without-renewal/Rt-without-renewalJob Properties
ResultsBelow is a table of this job's results, obtained by running the benchmarks.
Benchmark Group ListHere's a list of all the benchmark groups executed by this job:
Julia versioninfo
Baseline resultBenchmark Report for /home/runner/work/Rt-without-renewal/Rt-without-renewalJob Properties
ResultsBelow is a table of this job's results, obtained by running the benchmarks.
Benchmark Group ListHere's a list of all the benchmark groups executed by this job:
Julia versioninfo
Runtime information
|
ah okay. Shall we just merge this in then and I will deal with it in #438 |
@@ -28,6 +28,8 @@ struct AR{D <: Sampleable, S <: Sampleable, I <: Sampleable, P <: Int} <: | |||
init_prior::I | |||
"Order of the AR model." | |||
p::P | |||
"Reversed order of the damping coefficients for computation." | |||
rev_damp_prior::D |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why would we want both damp_prior and reverse damp prior in the struct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Basically for having ar_model.damp_prior
, I'm OK with getting rid of it but we need to be clear that the field is in reverse to expected order.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm quite unclear why this would have a performance impact?
It shouldn't in general (right?) but in the replication notebook we effectively had strong priors on the AR parameters in the wrong order (which strongly effects the prior variance of the process etc). |
This is blocked by #438 |
This fixes #440 by choosing to reverse the AR parameters, whilst maintaining everything else as is.
To cover this bug I've also added a unit test that would have picked up swapping the AR parameters in an AR(2) process by comparing a long single draw to its known theoretical stationary distribution.
Closes #440