The thought to make it easy for people building their own packages using rstan as backend is great. As I understand so far the idea is to provide S3 implementations for posterior_predict (rstantools) and pp_check/plot (bayesplot) and that’s it. However, looking at the respective implementation in rstanarm I got the thought that it may make sense to enable a further mechanism which would be via stanreg.
So the idea is that other R package writers shape up their objects such that they are stanreg compatible and then one can simply use the pp_check functions from rstanarm. This would mean that stanreg is sufficiently standardized and other R package writers could simply assign their objects the stanreg and a custom class property.
If this sounds like a possible idea, then I am happy to discuss further and we should possibly arrange for a hangout.
I’ll write more on this soon, but one option would be to expose a stanreg object generator function in rstanarm or possibly rstantools. Then packages would simply need to format results so they can be passed to the arguments of the function.
Sounds great. I think sticking this generator function into rstantools makes more sense, i.e. it would be great if packages need to depend on rstantools and bayesplot, but may not have to pull in rstanarm.
The bayesplot package could then provide a pp_check function which is as fancy as the one in rstanarm.
I like the idea of a generator function, but this needs to be done carefully of course. Maybe one should introduce another object here which reflects the fact that this will be a “basic” version of the stanreg class? But maybe we should not clutter the object space too much. Just a thought.
Yeah I agree that rstantools makes more sense than rstanarm for this. Take a peek at
Right now that’s just an internal function but essentially we would want something like that except cleaner and the input wouldn’t just be some “object” like it is now but rather specific arguments for each required bit of information.