[Interface roadmap] fit objects and `extract`

[jonah]

@seantalts

So I think maybe the solution here is to view the interface roadmap as a set of minimal functions required and let @bgoodri or other RStan contributors like @jonah decide if they’d like to add the functions @andrewgelman is asking for. I think this roadmap unification is an attempt to find the maximal common ground between the interfaces that their leads are already thinking about rather than a top-down prescription.

Well put. That seems sensible to me.

[jonah]

@seantalts

RStan contributors like @jonah decide if they’d like to add the functions @andrewgelman is asking for.

@seantalts I presume this would apply to things like visualizations too? They’re explicitly not covered in the roadmap on purpose but we’re not saying that we can’t have any visualization tools at all, right? The Plotting for Bayesian Models • bayesplot site is pretty established and linked to from all over the internet, so we’re not taking about suddenly getting rid of that right? Just that visualization tools are not covered in this roadmap for interface unity. Just want to be sure I understand.

[seantalts]

Yep, that’s right :)

[Bob_Carpenter]

@jonah

I think this roadmap unification is an attempt to find the maximal common ground between the interfaces that their leads are already thinking about rather than a top-down prescription.

What happens when RStan adds feature foo() that isn’t in PyStan or CmdStan or the other interfaces? Does it set a precedent? Or can PyStan implement a different version of that feature?

In other words, is the roadmap responsible for coordinating the interfaces? It sounds like the answer is no.

This has come up with RStan going its own way on a lot of things that they found more expedient to code directly in RStan rather than generalizing to C++ for inclusion in all interfaces. For example: file includes, Hessians for Laplace approximations, sampling from ADVI and Laplace approximations, reporting medians and rank-based R-hat, user-defined external functions, etc.

This isn’t a theoretical concern. @andrewgelman has been asking for a lot of things that aren’t on the roadmap: timing based runs, ragged chains for R-hat and n_eff (required for timing based runs), different default outputs, R-hat based on ranks, reporting medians rather than means by default, etc. I’m guessing these will all go into RStan first because that’s the only interface that registers with @andrewgelman in practice.

[andrewgelman]

Relatedly, we had a long discussion a few months ago about how to implement new algorithms such as GMO and EP, and I think the consensus was that it was best to try to program these in R or Python, calling STan to do the internal samping and optimization steps but programming the larger algorithms in R or Python, then only putting these all the way into Stan when we’d demonstrated the effectiveness of the algorithms. This is slightly different because it is development of new algorithms, rather than adding features to existing algorithms. But it seems related.

Also I’ve heard that CmdStanR is coming soon so perhaps that will affect what I will use.