Rstanarm prior specification: stan_glm.nb() and stan_glm() Poisson

Interfaces rstanarm
1

New rstanarm user here. This is excellent software, thank you!

Question: I am a bit confused by the possible priors for models stan_glm.nb() and stan_glm(family=Poisson()) after reading through the documentation via help("priors") and the vignette: https://cran.r-project.org/web/packages/rstanarm/vignettes/priors.html

Are there recommended priors for these models? Given the model/rstanarm function, are there priors recommended for rstanarm users?

It doesn’t look like the weakly informative priors used by rstanarm models are documented, by model. Is this information freely available? At the moment, it appears users would need to run the model, then check with prior_summary() (Apologies if I have missed documentation.)

2

The recommendation is that if you don’t know that you want to put an informative prior on any of the coefficients, specify QR = TRUE. Then the default independent normal priors should be okay. That goes for any stan_glm{er} model.

3

The recommendation is that if you don’t know that you want to put an informative prior on any of the coefficients, specify QR = TRUE.

So, the default is QR=FALSE? If so, what is the default prior for QR=FALSE?

Then the default independent normal priors should be okay.

Interesting. I had presumed that this wouldn’t be the same for count regression.

4

For QR = FALSE, you pretty much have to do prior_summary to figure out what the priors were. By default, it is normal with mean zero but the scales are a function of the standard deviations of the variables.

5

Understood.

I noticed that when executing the model using QR=TRUE, this results in many more messages of the form

“”“
Rejecting initial value:
Log probability evaluates to log(0), i.e. negative infinity.
Stan can’t start sampling from this initial value.
”"""

I never noticed this when running models without specifying QR. Could you offer a short explanation why this behavior exists?

Thanks for the help

6

No, but you could probably also specify init_r = 0.5 or something less than 2 to get starting values that are closer to zero.

7

The problem is that Stan initializes uniformly in (-2, 2) on the unconstrained scale. This can sometimes lead to initial parameter guesses that are far enough out in the tail when transformed back to the constrained scale that they cause arithmetic problems. Specifing 0.5 gives you narrower inits in (-0.5, 0.5).

1 Like