General guidance for RW_block samplers

[Matthijs Hollanders]

Hi all,

I have another question. Is there any guidance for the use of RW_block samplers, specifically regarding the number of nodes to block? Is there a number of nodes where the computations of the multivariate proposals become too demanding? I have a model with two RW_block samplers with 4 and 8 nodes, but am wondering if I could block a few more. I have reason to think that it would be useful to block these parameters, but am already dealing with very long model runtime and am wondering if this will be too costly.

Thanks!

Matt

[Matthijs Hollanders]

Related to this, I just ran some simulations of multiple regression with four predictors, with no RW_block samplers, one assigned for the coefficient vector, and one assigned to the intercept + coefficient vector. Although sampling time was considerably reduced, the effective sample size took a big hit with the block samplers and the n_eff / time did not improve either (see attached figure). I posted on Twitter too but thought I'd update the thread here in case it's of interest to anyone. 

[Perry de Valpine]

Hi Matt,

I recommend playing with the tuning parameters available for the block sampler (see help(samplers)).

You can set the "tries", which is the number of propose-accept-reject trials done within one call to the sampler.  Since a block sampler groups multiple nodes, they will all be updated or not together.  If you stick with the default of tries = 1, and you block say 3 nodes, you will be replacing 3 potential updates (1 for each) with 1 potential update to all, often resulting in faster computation but slower mixing.  I have sometimes seen good performance from increasing tries in proportion to the number of nodes in the block (perhaps tries = 0.5 * number of nodes, but experiment). 

You can also set the adaptInterval.  This sets the pace of trying to update the covariance structure of proposals.  The default of 200 is somewhat conservative and you may want to decrease it.  The adaptFactorExponent also impacts the schedule of self-tuning.

Block sampling typically only has potential to improve on scalar sampling if the posterior correlation is sufficiently high.  Otherwise scalar sampling will do just as well or better.

A final consideration is whether the nodes being blocked share their dependencies or have different dependencies.  If they share their dependencies, then the computational burden is not much more than scalar sampling.  But if they have very different dependencies, then the computational burden will be more than either alone (because it must calculate dependencies of all nodes in the block).  

Also it is useful to be deliberate about whether you remove the default scalar samplers that might have been assigned to nodes when you add a block sampler, or whether you keep both.

Finally, we have recently put a package on CRAN called 'compareMCMCs' that can help manage the workflow for such projects. I hope it is useful.

Perry

--
You received this message because you are subscribed to the Google Groups "nimble-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nimble-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/nimble-users/f31f8234-eef8-42e8-8d50-157d731df38an%40googlegroups.com.

[Chris Paciorek]

I particularly recommend experimenting with `adaptFactorExponent`, probably reducing it, as we've found in some examples that that can improve mixing a lot.

Also if you have an informed guess as to the proposal covariance, it's a good idea to set that manually, to at least get the relative scales for the different elements roughly right. And we've seen that it's particularly bad to start with proposal variances that are too big -- it's better to have them start too small if anything.

To view this discussion on the web visit https://groups.google.com/d/msgid/nimble-users/CABeTmqjGChy7uYp%2BdGg2iBdAZkXUBkQu-QcCPsZESDq1Mxft0A%40mail.gmail.com.