I think one of the main reasons might be that it is common in survival analysis for people to fit a regression model on the hazard scale (due to the popularity of the Cox model), but the outcome is observed as a time-to-event. So the approach probably doesn’t feel very familiar to people who are used to more common regression modelling frameworks like, say, a GLM(er) where applying the inverse link function to your linear predictor gets you a predicted value for the outcome.

That’d be great! I’m still pushing changes regularly, so might break things occasionally, but hopefully it will run without too many bugs from now on. I noticed the estimates from the M-splines model, when fit to the Breast Cancer data, were a bit different to the R&P or B-spline estimates, and increasing the df for the M-splines didn’t really improve things (I think this was true when running the model with your .stan file or with `stan_surv`

) – but this only seemed to happen for that one dataset. A simulated dataset seemed to return similar estimates for the M-splines, B-splines, or R&P models, I think. Would be interested to hear what you observe.

(If you want to test using simulated data, then you could download the **simsurv** package).

Yeah, happy to collaborate on the code. Will just be figuring out the logistics! I’ve made a new class `stansurv`

in **rstanarm** that inherits the class `stanreg`

and have added a `print`

and `prior_summary`

method for those objects today. Still some other methods to add (including `summary`

and perhaps a `basehaz_summary`

method). For predictions, hopefully we can just use most of the structure from the `posterior_survfit`

function from `stan_jm`

(although the stan_jm stuff is a lot more messy and dense, but still should be a bit useful). Also things like time-dependent effects, AFT models, trying out the constrained likelihood thing… I think we could each work on aspects of those, without confusing each other too much with conflicting commits? The method you mentioned here:

could be quite cool to implement too, if possible – perhaps you could try add it to the surv.stan file I’ve started in **rstanarm**? In any case, this thread is probably the wrong place for this discussion! – if your keen to collaborate on the **rstanarm** code then we could move this discussion to GitHub. I’ll open an issue on the **rstanarm** repo so that we can discuss ideas there…