traceplot, xyplot: different output

  • Simone Tenan

    Simone Tenan - 2012-08-23

    Hi all,

    I got my samples using R2jags (

    out <- jags(data, ...)

    ) then Iooked at the trace plot for the two parameters, using both



    out.mcmc <- as.mcmc(out); xyplot(out.mcmc)


    I don't understand why the traces from the two methods are different.

    Here the plots:

    Many thanks in advance.


    Simone Tenan

  • Martyn Plummer

    Martyn Plummer - 2012-08-23

    Well, traceplot and xyplot are two different functions: traceplot uses the
    traditional R graphics engine whereas xyplot uses the grid graphics engine.
    Deepayan Sarkar wrote the various lattice plotting functions for the coda
    package, including xyplot and made a number of different design choices from
    the original traceplot.

  • Simone Tenan

    Simone Tenan - 2012-08-23

    Sorry, I am not able to add the links for the graphs (the system says that the
    url looks like a spam).

    Anyway, from the graphs there is every indication that order for the
    iterations has been changed (and consequently the trace shape) from the jags
    output (out) to the mcmc object (out.mcmc). Might be possible?

    Thanks again,


    Simone Tenan

  • Tom Murray

    Tom Murray - 2013-04-17

    I've had this same observation and it can be a real problem. Here is what is going on.

    When you call: out.mcmc <- as.mcmc(out); xyplot(out.mcmc)
    The out.mcmc must be grabbing the posterior samples from either out$BUGSoutput$sims.matrix, or out$BUGSoutput$sims.list, both of which do not preserve the sampling order! out$BUGSoutput$sims.array is the only object that preserves the sampling order. Why this is, I have no idea. I discovered this here and verified it with my output:

    Do not use: out.mcmc <- as.mcmc(out); xyplot(out.mcmc), it can be misleading if your chain is very sticky.

    Generate your own plots with plot(out$BUGSoutput$sims.array[,,'param_name'],type='l').


  • Wouter Kruijne

    Wouter Kruijne - 2013-07-12

    Perhaps something to add:

    When using as.mcmc() to convert R2Jags-output into coda-mcmc-format, there's a major difference between one chain or multiple. That is that it seems that:

    • the result corresponds to samples in sims.array when multiple chains are used (i.e. correct time series),
    • but it corresponds to sims.list (randomized) when only one chain is used

    I find this highly surprising and confusing -- and dangerous since the R2Jags documentation explicitly states that as.mcmc() is to be used for this conversion.. So would this qualify as a bug in as.mcmc(), in R2Jags, or ...?

  • Martyn Plummer

    Martyn Plummer - 2013-07-12

    Yes this is a bug in the R2jags package, in the as.mcmc.rjags function. Please tell the maintainer Yu-Sung Su.

    > R2jags:::as.mcmc.rjags
    function (x) 
        x <- x$BUGSoutput
        if (x$n.chains > 1) {
            z <- list()
            for (i in 1:x$n.chains) {
                z[[i]] <- mcmc(x$sims.array[, i, ], start = 1, thin = x$n.thin)
            class(z) <- "mcmc.list"
        else {
            z <- mcmc(x$sims.matrix, start = 1, thin = x$n.thin)

    In fact it is sims.matrix in the single chain case, but (according to the R2WinBUGS documentation) this is also randomized. This could be quite serious as the randomization may give a false impression of good mixing.

    To be honest, I never understood the interest in randomizing the observations in R2WinBUGS and R2jags.

  • Avi

    Avi - 2013-07-16

    I've sent an e-mail to Dr. Su with this URL, FWIW.


Log in to post a comment.