Flexibility of opt-in sampling variables

Modeling
1

I am trying to create a hybrid model with some parameters only applicable to certain model while I want to put everything in one single stan file.
For example

data{
int N;
vector[N] x;
vector[N] y;
int use_beta;
}
parameters {
  real alpha;
  real beta;
  real<lower=0> sigma;
}
model {
  if (use_beta) 
    mu = alpha+beta*x;
  else 
   mu = alpha;
  y ~ normal(mu, sigma); 
}

So when I call my stan model with use_beta = FALSE, I will exclude “beta” from my pars input. By doing so, would I safely avoid any divergence problem of “beta” ? or do I need to explicitly define beta as a size 0 real when use_beta is FALSE as well?

Also, I notice while calling optimizing, we cannot input pars. In that case, will the algo trying to optimize beta and hence causing problem in the case when use_beta is FALSE?

Hope my question is clear!

Edwin

2

Not unless you have a prior on the unused beta. Ordinarily in situations like this, you should have the size of beta depend on use_beta like

data{
  int<lower = 0> N;
  vector[N] x;
  vector[N] y;
  int<lower = 0, upper = 1> use_beta;
}
parameters {
  real alpha;
  real beta[use_beta];
  real<lower=0> sigma;
}
model {
  vector[N] mu = use_beta ? alpha + beta[1] * x
                          : rep_vector(alpha, N);
  y ~ normal(mu, sigma); 
  // priors
}
3

Thanks for the prompt response! Does it mean I can solve the problem by either

  1. Have a size for beta depended on use_beta
    or 2. Have a prior on beta?

Or Do you mean I need both? (For that part, I’m confused since from my understanding, every variables has a default prior (-Inf, Inf)?)

4

It is generally a good idea to have a prior on beta if it is used.

If beta is declared unconditionally but not used, then the posterior is improper and MCMC does not work.

So, it is probably clearer to declare real beta[use_beta];.

1 Like
5

If you do 1) you should still have a prior for the case when use_beta is true. Not using priors is sometimes OK, but having them is definitely preferable and sometimes crucial. The -Inf, Inf is not really a prior (sometimes called improper prior) as it does not integrate to 1. Improper priors often fail to regularize the posterior in a useful way.

Hope I am making sense and best of luck with your model :-)

1 Like