Outsource MCMC standard error calculations to mcmcse::mcse.multi()?

[krivit]

Essentially, instead of specturm0.mvar(), we call that function; it seems to do everything we need except handle parallel chains, and it may well do so faster and more robustly. (At the moment, particularly for many-parameter models, an unfortunate amount of time is spent figuring out what the ESS is.)

[krivit]

Addendum: there is a package stableGR that uses mcse.multi() on the backend implements a multi-chain version of mcse.multi() as well as a Gelman-Rubin diagnostic.

[dvats]

Hi Krivit, few things to add here. (1) Yes, ESS is a bit expensive right now due to the batchSize() function being slow. I am hoping to get the speed down sometime this month (2) You are correct that you can use asym.var in stableGR to do multiple chain variance. We hope to integrate that into the mcse.multi package as well.

[krivit]

@dvats , thanks for visiting our little corner of GitHub! (I am a bit curious how you found us; Google Alerts?)

I was actually referring to the slowness of our current mechanism for ESS calculation (found in https://github.com/statnet/ergm/blob/master/R/approx.hotelling.diff.test.R). This is basically a multivariate generalisation of coda::spectrum0.ar, along with some tricks to stitch together replications without having them intrude on each other when calculating lagged covariances and some linear algebra to handle situations in which the variables are linearly dependent.

As you say in your paper, particularly when dealing with models with large numbers of parameters, even calculating the multivariate ACF takes a long time.

[dvats]

@krivit I found this because you starred the mcmcse package and was meandering about on the internet over my morning cup of joe.

These are some of the same challenges we are dealing with right now as well. Currently working on better estimation of lag covariances from replicated chains and we have some promising results. Soon enough these will be part of the package, so hopefully your team can find it useful as well. I will keep a lookout for what you're doing as well!

[krivit]

@dvats, I'm happy to hear that. Automatic MCMC tuning and stopping that is agnostic to the structure of a sample space is important for us.