test with different data sets that this works and doesn't affect our ability to fit the model

The vignettes show no meaningful change in results or number of divergent transitions. Benchmarks also show no significant change in performance. If this looks correct to people we can probably merge and explore further building on this.

@seabbs Do you want to take this one?

Testing this on a few data sets I encountered no issues but an eye would have to be kept on this in the near future.

@sbfnk can you plot the change in the prior here if you get a chance?

1. How do people reason on this prior. It means as they fit to new data I would expect they need to constantly update the prior - that feels really quite odd to me

I tend to agree with you here, and I hadn't thought about it like this. Just noting (not taking away from your point) that it's what is done in the Riutort-Mayol paper.

2. This is really quite a long lengthscale in many settings and I would expect it to negatively impact identifiability and performance during long periods of constant Rt (i.e locking in constant Rt beyond our prior expectations)
3. Setting the max to the length of the time series as the default seems likely to lead to non-identifiability to me (support for a range of very nearly the same lengthscales)

These could be easily address by changing the exact prior (which I mean to choose to roughly mirror the current prior with the examples). As far as I can see in the paper the example choices are

Gamma(1.2, 0.2.)
InverseGamma(2, 0.5)
Normal(0, 2)

4. This has moved the prior to be normal vs lognormal unless I am missing a transformation. If there is a transformation what does this mean for the inverse gamma option

This wasn't intended - not sure what happened there. The Inverse Gamma option has gone (as the lengthsacle can now be fixed).

I know you have done some testing but I don't really believe our testing is deep enough to catch above.

Completely agree.

My preference would be we update interface but keep the current defaults. I realise this could be a problem as it means we need to rescale in the model (I think)

We could do this in preprocessing - just would be a bit tricky as we'd have to implement transformation by multiplying with a constant for all the distributions used. Not impossible, though, perhaps could even be done at dist_spec() level.

This is how benchmark results would change (along with a 95% confidence interval in relative change) if 13889e8 is merged into main:

• ✔️default: 23.4s -> 22.1s [-16.35%, +5.25%]
• ✔️no_delays: 27.5s -> 27.5s [-18.93%, +18.77%]
• 🚀random_walk: 11.4s -> 9.79s [-26.19%, -1.72%]
• ✔️stationary: 13.4s -> 13.6s [-16.03%, +18.93%]
• ✔️uncertain: 36.4s -> 38.8s [-13.46%, +26.53%]
  Further explanation regarding interpretation and methodology can be found in the documentation.

Just noting (not taking away from your point) that it's what is done in the Riutort-Mayol paper.

Yup, I intentionally didn't implement it like this at the time. My view then was that they weren't really trying to implement something for reuse but just for their experiments and so they might not have thought about the implications of use across rolling periods and different datasets etc.

These could be easily addressed by changing the exact prior (which I mean to choose to roughly mirror the current prior with the examples)

Yes agree

• just would be a bit tricky as we'd have to implement transformation by multiplying with a constant for all the distributions used.

Yes, agree. Its not ideal. Wouldn't it be divide by a constant? The reason I said in model is that this makes it much more flexible (as some prior distributions might be hard to rescale). If we wanted a quick fix this would also be much easier (though at the cost of some efficiency).

Having sat on this I am happy if you want to set this issue aside for this PR (i.e. make it a new issue and gather some feedback thoughts on if this is really a problem for people).

Wouldn't it be divide by a constant? The reason I said in model is that this makes it much more flexible (as some prior distributions might be hard to rescale). If we wanted a quick fix this would also be much easier (though at the cost of some efficiency)

I already did this in 922f0c9 - I also have a version where the scaling happens in R, which I'll put in a separate issue/PR combo