Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅ 📢 Thoughts on this report? Let us know! 🚀 New features to boost your workflow:
|
|
Lots of chaff here (linting, adding package dependencies, |
This comment has been minimized.
This comment has been minimized.
|
Never mind, figured it out. |
zsusswein
left a comment
There was a problem hiding this comment.
Thanks Ben -- this is fabulous.
I'm sorry I didn't get to this sooner. I left a few thoughts below on my way to the airport, but I didn't give it as thorough a read as it deserves. My apologies. I noted a few things I was interested in, but don't let those disrupt the direction you're going here.
I tagged my colleague Sam for your question about citations on delays. I'm hoping he'll have something top-of-mind.
I'm approving so as to not hold you up in my absence. Sorry about the CI pain! For future reference, there's a justfile you can use to run the checks locally and auto-format.
|
|
||
| ## To do | ||
|
|
||
| * is there intuition/math for why taking the convolution into account |
There was a problem hiding this comment.
I can give a more thorough look when I'm back next week but I think @SamuelBrand1 might be the person to ask? Sam does anything spring to mind?
|
|
||
| Will want to compare true_rt, true_incident_cases | ||
| also, maybe, true growth rate? (maybe adjust code to | ||
| return true_Rt and true_rt/true_growth? Back-calculating |
There was a problem hiding this comment.
I believe predict.RtGam should do it for you. You could also just difference the linear predictor with no shift?
There was a problem hiding this comment.
wouldn't differencing the linear predictor give me (an approximation to) growth rate ("little-r"), not Rt? Or maybe I'm missing something ...
There was a problem hiding this comment.
Sorry was unclear -- I meant for little-r. predict.RtGam should give you both r and R.
| * will need extra machinery for prediction | ||
| * computational cost? | ||
| * fragility? | ||
| * end effects? |
There was a problem hiding this comment.
To this point, I'd be interested in seeing the differences in Rt here -- maybe across a range of GIs?
It's probably not reasonable to make a general statement, but if you think it's feasible I'd be interested in the impact on Rt from using on one approach vs the other.
Clearly there will be a bias. When is the bias most extreme (I.e. is it Rt peak or infection peak)?
| start = list(theta = 3), | ||
| delay_pmf = delay_pmf | ||
| ) | ||
| a3 <- augment(m3) |
There was a problem hiding this comment.
I'm not totally following this augment() call. I can see it's adding some stuff from the functions file?
this is a first draft of machinery for handling case reporting delays via
mgcvsmooth machinery exported to RTMB.The summary document is here
Conclusions so far:
Obvious challenges/to do:
glmmTMBmachinery this is based on]bam-style optimization ...)