You can always make it faster…

… but sometimes you just need a good example to show you how. Saana Isojunno from the University of Saint Andrews wrote to me with an example that stopped working when she upgraded from JAGS 3.4.0 to JAGS 4.2.0. Saana’s model showed the classic signs of a memory leak. Compilation was very slow and memory consumption increased until all available RAM was used and the process was killed by the operating system. Continue reading

PyJAGS

Editors note: I am very pleased to announce that Tomasz Miąsko has created a Python interface to JAGS. The rest of this post is by Tomasz.

Nowadays Python users certainly cannot complain about a lack of MCMC packages. We have emcee, PyMC, PyMC3, and PyStan to mention a few. Recently this list was extended by one more; PyJAGS – a Python interface to JAGS. JAGS is a program for analysis of Bayesian hierarchical models using Markov Chain Monte Carlo (MCMC) simulation, quite often used from within the R environment with the help of the rjags package. The PyJAGS package offers Python users a high-level API to JAGS, similar to the one found in rjags. Current rjags users interested in migrating to Python should feel at home. Of course, other interested in doing Bayesian data analysis may also find PyJAGS useful. Continue reading

JAGS 4.0.0 is released

After a long gestation period, JAGS 4.0.0 was finally released last week. If you go to the project page on Sourceforge then you should see an appropriate download link for your platform (binary packages for Windows and Mac OS X; source tarball for other platforms). Binary packages are also available for some Linux distributions. See the JAGS homepage for details.

Mac users should note that you need OS X 10.9 or later (i.e. Mavericks, Yosemite, or El Capitan). Older releases are no longer supported.

The rjags package for R has been updated to work with the new release of JAGS. It is not yet uploaded to CRAN, and the version of rjags that is available on CRAN (rjags_3-15) does not work with JAGS 4.0.0. However, you can download rjags_4-3 from Sourceforge. Again, binary packages are available for Windows (.zip) and Mac OS X (.tgz).

What’s new in JAGS 4.0.0 part 3/4: R-style features

The BUGS language is syntactically very similar to R and there are several packages that allow R users to interface with the JAGS library. When you are using both R and JAGS simultaneously, small differences between the languages can be frustrating. Consequently there is some pressure to narrow the gap between the two languages.  There are some things we cannot change, such as the parameterization of the distributions, but there is a tendency for JAGS to become more R-like with each release. JAGS 4.0.0 introduces a few more R-like features. Continue reading

What’s new in JAGS 4.0.0 part 2/4: dealing with undefined nodes

I know from questions in the JAGS forums that undefined nodes can be a source of frustration for JAGS users. Here is a simple example:

for (i in 2:N) {
    x[i] ~ dnorm(0, 1)
}

The compiler creates a node array x of size N, but the element x[1] is undefined. In JAGS 3.4.0 this can potentially cause two problems.

Firstly, if you tried to set a trace monitor for x then you would get an unhelpful message “Node not found”. This is a frequent issue with state space models, in which the observations for series i start at time T[i] and anything that happens in the range 1:(T[i]-1) is undefined.

Up until now, the remedial action has been to identify the undefined elements of the array and fill them in with an arbitrary constant value, e.g.

x[1] <- 0

so that the node x[1:N] can be defined and monitored. This is no longer necessary. JAGS 4.0.0 allows you to create a trace monitor for a node array that has undefined values. The elements of the monitor corresponding to the undefined elements have value NA (not available).

The second problem occurs if you reference the undefined value x[1] in the model, by using it on the right hand of a relation. It is easy to do this indirectly. For example, given this

y <- sum(x)

the compiler will try, and fail, to create a node y that is the sum of all the elements of x. The error message from the compiler in this case is

Unable to resolve node XXX. This may be due to an undefined
ancestor node or a directed cycle in the graph

where “XXX” is some node in the graph. It might be the missing node x[1] but usually it is another node that depends on it (e.g. y or some node that that depends on y). This is why the error message refers to an “undefined ancestor”. Tracing the error back from the cited node XXX to the source of the problem can be hard work. In addition, the message fails to distinguish between two completely different issues: undefined nodes versus directed cycles.

In JAGS 4.0.0, the compiler tries a lot harder to zero in on the source of the problem and distinguish between the two issues. The error message for the above model is now.

Unable to resolve the following parameters:
x[1]
Either supply values for these nodes with the data
or define them on the left hand side of a relation.

If you have a directed cycle, like this

model {
   y[1] ~ dnorm(y[2], tau)
   y[2] ~ dnorm(y[1], tau)
   tau ~ dgamma(1,1)
}

then the message will be

Possible directed cycle involving some or all
of the following nodes:
y[1]
y[2]

There is no remedial action in the case of a directed cycle, as these are still forbidden in JAGS.