Forecasting in epinowcast

Project Proposals
4

Hi,

Thanks for the detailed look at this. As you say the functionality is mainly tailored for our use case, but I am hoping we can come up with a reasonably general solution that could be of use for more people.

Your understanding of the current implementation is correct and I agree that there are benefits and drawbacks to this approach compared with the alternative approach you outlined. A few comments:

  1. I agree that in the current implementation one has to specify the formula for the expectation twice and they have to be identical. It would have been nice to be able to get hold of the formula from the expectation, but since they currently both are specified in the epinowcast function, I did not see a nice way of accessing the enw_expectation object. One probably should require that a enw_expectation object is a parameter for the definition of enw_forecast.
  2. I partly agree with your comments about missing the rest of the observation model. I don’t understand why we would want to include the delays in the forecast as then the forecast would also need to be for some specified observation date in the future. To me it makes more sense that the forecast should be of the final expected counts once we have passed the max delay for the forecasted data. That said, I think that adding the measurement error and probably some form of the missing data model would be important for the forecast so that it could be compared to future data (once we are passed a point where delays are important)
  3. The implementation in the generated quantities block makes conceptual sense to me. I see the point that it might require effects to be specified twice in the code, and that this would likely require some more ongoing work to ensure that it would be up-to-date with the rest of the model. I still think it is quite possible to extend the current approach so that it also can take into account measurement error and missing data and that we could then keep the forecasting completely separate from the inference, which I think it a nice feature.
  4. I agree that it be nice to have a more general way of handling how we either fix or continue the current dynamics. It should be possible to specify in a flexible how the dynamics should be treated in the forecast.

I think the key question now is if we should continue to work on the current approach with the generated quantities block or investigate/implement the other approach instead.