Non Constant Hyperparameter in RJMCMC

[Colton Padilla]

Hey everyone,

I am currently working on a model where I am wanting to implement a reversible jump routine that has a non-constant hyperparameter on the scale parameter. I understand that nimble's base routine does not allow for this; however, what I am wondering is if it is due to some statistical backing that having a non-constant scale will cause issues within the model itself. I believe that I could create my own nimble function that allows that sampler to input the non-constant hyperparameter, but I am just unsure if this is going to be an issue on a statistical side. I am not seeing any documentation as to why that is only allowed to be a fixed value at this point. Could anyone provide some explanation or clarification surrounding this? Thanks for any help.

[Sally paganin]

Hi Colton,

Sorry for the delay getting to this.  

I am not sure I fully understood the exact model you have in mind, but I think we set up the restriction in the reversible jump sampler for simplicity, rather than because having a hyperprior on a parameter involved in RJ is problematic from a statistical perspective. There is a nimbleOption called MCMCRJcheckHyperparam that can be used to disable the check, but then it becomes the user’s responsibility to ensure that the resulting sampler is mathematically valid.

Here are some thoughts about the cases I have in mind. For example, suppose you have something like

for(j in 1:p){     

 beta[j] ~ dnorm(0, sd = tau) 

} 

tau ~ somePrior()

In this case, tau is shared across coefficients and is always part of the model. The question then becomes how tau should be updated relative to the RJ moves. My interpretation here is that tau would be informed only by the coefficients that are in the model. So in this case, I think a user could write their own sampler for tau.

A different situation would be something like

for(j in 1:p){

 beta[j] ~ dnorm(0, sd = tau[j])     

 tau[j] ~ somePrior()

} 

where each coefficient has its own local scale parameter. Conceptually, here, inclusion moves could involve jointly proposing both beta[j] and tau[j]. However, I would also be a bit cautious here since each tau[j] would be informed only through a single coefficient, but there might be contexts where a model like this would be reasonable. 

Hope this helps!

Sally