Wish I could edit my comment. I want to emphasize that I’m not criticizing rstanarm or suggesting it should not continue. Just saying that I don’t think it should be the foundation or inspiration for a higher-level-of-abstraction tool built on Stan that I think you’re talking about in this week’s Stan status. I just feel that brms and it’s flexible formula-based approach should inspire your thinking.

]]>Agreed. I’m just suggesting that at the strategic level we’re talking about here the rstanarm approach — which regularly appears in the Stan updates — may be fragmenting rather than unifying and flexible. Some people are more comfortable switching to something that is named and works almost exactly as their old tool does. But that approach also keeps the silo’d mentality rather than encouraging a systemic, modular approach that Stan can support.

If we are going to build a higher-level system on Stan that has Stan-like flexibility but works at a higher level of abstraction and is modular, brms offers a compelling vision. It has chosen to broaden and deepen R’s formula language, but other variations are possible.

]]>Wayne:

One key aspect of Stan’s design is that it is open and transparent and easy to build upon; thus we can have rstanarm, brms, StataStan, and all sorts of other ways to access Stan’s power and flexibility.

]]>Agreed. Another advantage of brms’ approach is that the Stan code is much like Stan code that you or I might generate. The rstanarm code is very sophisticated and highly optimized, but it’s not something you might copy/paste and then build on.

]]>I really think the `rstanarm` approach might be a bridge from frequentist to Bayesian approaches or it might be a trap that makes a high-level unified approach more difficult to achieve.

I cautiously cast my vote for “trap”. I have been using brms as well, and I think it is much more in the spirit of generalization that makes Bayesian modeling so powerful. I also don’t think the difficulty translating code from [some r function] to an interface like brms is high enough to justify the loss in expressiveness from a less generic interface like rstanarm.

Some API developers call this the floor/ceiling tradeoff: I think the floor (ease of getting started) of rstanarm is only slightly lower than brms, but the ceiling (expressiveness, longterm usability for an expert, etc) of brms is much higher. The similarity in floor but difference in ceiling makes brms preferable.

]]>My sense is that Stan is the “assembler language” built on top of the “machine language” of MCMC, and we will want to build a higher-level language on top of Stan.

I believe `brms` is a great illustration of this. With a single function (brm), and a single “language” (an extended R formula and families), brms lets me fit a huge variety of regression models such as:

Simple regression: y ~ x1 + x2, family=normal

Regression with monotonic predictor: y ~ mo (x1) + x2, family=

Logistic regression: y ~ x1 + x2, family=bernoulli

Ordinal model with category-specific predictor and group-level intercept: y ~ cs (x1) + (cs(1) | g), family=acat

GAM-style regression: y ~ s(x1) + x2, family=

Censored logistic regression: y | cens (c1) ~ x1 + x2, family=

Mixed-Effects regression: y ~ x1 + (1 + x1 | g1), family=

Survival model: y | cens (c1) ~ x1 + x2, family=weibull

Survival model with frailty: y | cens (c1) ~ x1 + x2 + (1 + x1 | g1), family=weibull

Regression with errors-in-variables: y ~ me (x1, sdx), family=

Mixture model: y ~ 1, mu1 ~ x, mu2 ~ z, family = mixture (gaussian, gaussian)

Zero-inflated model, prediction zero-inflated (zi) part: y ~ x * z + (1 + x |ID1| g), zi ~ x + (1 |ID1| g)

I’ll stop here, but I think this shows how I can build complex models or change model types piece-by-piece, which I believe is a critical component of the task you’re describing. I’ve stopped showing examples, but brms can handle nonlinear models, multivariate models, Conditional Autoregressive (CAR) models, zero-inflated and hurdle models, GAM, GAMM, survival, and a whole host of models, with a single formula language that is translated into Stan, rather than a dozen different frequentist-style functions that happen to use Stan under the hood. I really think the `rstanarm` approach might be a bridge from frequentist to Bayesian approaches or it might be a trap that makes a high-level unified approach more difficult to achieve.

]]>Something along those lines for a fixed set of models could work. In some sense that’s also what RStanArm is doing—making it easier to experiment with a range of Stan models that’d be cumbersome to type out and manage. I was more looking for an in-Stan solution, though, rather than a new add-on language. Though that may be what it takes in the end.

]]>“Any ideas on how to manage developing a model would be appreciated”.

I have only played with Stan a little, so I am not certain I understand totally what the discussion is about. But just wondering if you have looked at what McElreath does in the “rethinking” package. He has some programs that make it in some sense easier to write out the desired model, which than gets translated to Stan, which can also be saved and edited if it is just as you would like.

Again, this may be far from what the concern is, but just in case,,,,

]]>