fixing mu parameter via mu = some_value?

[venpopov]

Currently there are two ways to fix model parameters to a constant. The older one is via a constant prior, and this works for any parameter:

prior(constant(3), class = "Intercept", dpar = "kappa")

The newer method is to specify par = some_value, e.g.:

bf(resp ~ 1, kappa = 3)

I find the newer method much more intuitive and it is easier and faster to write. Unfortunately, while the first method works for any parameter, including mu, the second only works for non-mu parameters. For example this:

bf(resp ~ 1, mu = 0, kappa ~ 1)

does not work. The model runs, but mu=0 is ignored and an intercept is still estimated.

Interestingly, if we want to fix it to 0 specifically, both of these work:

bf(resp ~ 0, kappa ~ 1)
bf(resp ~ 1, mu ~ 0, kappa ~ 1)

resulting in:

Formula: y ~ 0 
         kappa ~ 1
   Data: dat (Number of observations: 3000) 
  Draws: 4 chains, each with iter = 500; warmup = 250; thin = 1;
         total post-warmup draws = 1000

Regression Coefficients:
                Estimate Est.Error l-95% CI u-95% CI Rhat Bulk_ESS Tail_ESS
kappa_Intercept     0.12      0.03     0.06     0.17 1.00      425      520

I suspect this is not intentional - supressing the intercept results in stan code in which mu is not part of the parameter block, but we have

parameters {
  real Intercept_kappa; // temporary intercept for centered predictors
}

mode {
 // .....
// initialize linear predictor term
    vector[N] mu = rep_vector(0.0, N);
// ....
}

Nevertheless, it works. But only for the specific case of fixing mu=0.

Is it possible to allow fixing mu to an arbitrary value via the formula syntax as for other parameters?

[paul-buerkner]

Let me look into this. Just a note that the contant() prior approach is actually the newer one while the bf(par = value) approach is much older and I am not even sure I like having the latter version in brms at all or if I may want to deprecate it at some point.

[venpopov]

Didn't realize the order, I guess it was newer because I never knew it was possible that way. I like it because it is clearer and shorter. Terms with ~ are estimated, terms with = are fixed, but both are part of the model specification. The constant(value) prior is not really coded as a prior in the underlying Stan code that brms generates, but rather just a fixed variable with that value, which to me is more consistent with the formula approach. But I understand if you prefer the prior approach and decide to deprecated the otherr