6
$\begingroup$

Does JAGS have an R front end like brms / rstanarm for Stan? Is anyone working on one for JAGS?

$\endgroup$
  • 2
    $\begingroup$ Sorry for the ambiguity. brms is not merely a package for communicating with Stan from R. brms uses R's formula syntax for specifying hierarchical models in Stan. (brms at CRAN: cran.r-project.org/web/packages/brms/index.html) I'm wondering if there is something analogous for JAGS, that is, a package that lets the user specify models with R's formula syntax, and then builds the hierarchical JAGS model specification behind the scenes $\endgroup$ – John K. Kruschke Jun 15 '16 at 1:37
  • 1
    $\begingroup$ I have looked extensively and do not think there is one. As for developing one, I think it would be hard to compete with brms which covers basic regression models to time series generalized linear mixed models and everything in between. If bayes factors are wanted, they can easily be obtained for complex models as well. I have also used rstanarm and it does not come close to brms. $\endgroup$ – D_Williams Jun 15 '16 at 1:38
  • 3
    $\begingroup$ The runjags package has template.jags which generates code for (basic) generalised linear mixed models, but the motivation is to help the user write their own code rather than doing all the work without the user having to think about or understand anything (this way potential disaster lies). Having said that it is possible to simply run the template without edits, even if it is not advisable... I am still developing these functions although have not yet decided how far I will take them. $\endgroup$ – Matt Denwood Jun 15 '16 at 5:42
  • 2
    $\begingroup$ To clarify, rstanarm contains a fixed set (currently 6) of hand-written Stan programs that can be called from R. That does not sound as if it would be so difficult to do for JAGS, but in order to support more than 6 "models", the Stan programs utilize a lot of features that have not been part of the BUGS language, such as conditional logic, local functions, etc. The brms and rethinking packages generate Stan syntax at runtime, which is closer to a translation of R syntax into Stan syntax. That sounds more like what @JohnK.Kruschke is looking for but with JAGS. $\endgroup$ – Ben Goodrich Jun 15 '16 at 13:25
  • 1
    $\begingroup$ Right, I'm hoping for a runtime translation of R-formula syntax into JAGS model specification. $\endgroup$ – John K. Kruschke Jun 15 '16 at 15:07
2
$\begingroup$

Based on your last comment ("I'm hoping for a runtime translation of R-formula syntax into JAGS model specification"), I think runjags::template.jags does what you want (at least partly). It automatically generates a complete JAGS model (and data) representation of a (G)L(M)M based on lme4-style syntax and a data frame supplied by the user. For example:

library('runjags')

# Use an example from glmer:
library('lme4')
fitdata <- cbpp
fitdata$Resp <- cbind(fitdata$incidence, fitdata$size - fitdata$incidence)
# As in ?glmer:
gm1a <- glmer(Resp ~ period + (1 | herd), fitdata, binomial)

# Create (and display) the JAGS code:
mf <- template.jags(Resp ~ period + (1 | herd), fitdata, n.chains=2, family='binomial')
cat(readLines(mf),sep='\n')

r <- run.jags(mf, burnin=5000, sample=10000)

r
summary(gm1a)

There are two obvious things missing: random slopes are not yet supported (but that is something I am looking to add), and non-linear models are not directly supported (but a linear model could be generated and then edited by the user). Note that it's not possible to include arbitrary R functions in the JAGS code, so these will have to be re-written in JAGS (or in C++ as a JAGS module).

To repeat my earlier comment, the motivation is to help the user write their own code rather than doing all the work without the user having to think about or understand anything. To clarify: I see the benefit of helping a reasonably knowledgable user to quickly generate code which otherwise might be tedious to write (particularly if they struggle with BUGS syntax despite understanding the theory of MCMC), but I am uncomfortable with the idea of truly novice users using the automatically generated code without understanding what is happening (i.e. as a totally black box). But perhaps I am being overly cautious ... I would be very interested to hear others' opinions (privately by email to the maintainer of the runjags package if preferred) as I have not yet decided how far to develop these functions, and would certainly take on board useful comments and suggestions.

$\endgroup$
  • 2
    $\begingroup$ IMHO, there is a need for things like your template.jags function, my rstanarm package, brms / rethinking, etc. It is true that these can be used without the user really understanding what is going on, but in my experience the same is true for lme4 users. One thing that made me worried is that it is difficult to validate at runtime that the generated code corresponds to what the user's R code implies if you try to support a wide range of R syntax. Paul seems to have done a better job of this with brms than others have. But that is one reason why we hand-wrote the Stan programs in rstanarm. $\endgroup$ – Ben Goodrich Jun 16 '16 at 15:26
  • 1
    $\begingroup$ Thanks Ben. It is certainly true that lme4 etc can also be used without understanding, but lack of a manual verification of the JAGS code would still make me a bit more nervous than running the equivalent model in a classical framework. Partly because of prior selection (I don't believe in the existence of a single prior that is minimally informative in all situations), and partly because being a more flexible language gives more opportunity for error, but also I guess because I trust Bates et al more than I do my own coding abilities! $\endgroup$ – Matt Denwood Jun 16 '16 at 15:40

Not the answer you're looking for? Browse other questions tagged or ask your own question.