New rstanarm user here. This is excellent software, thank you!
Question: I am a bit confused by the possible priors for models
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.)
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
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.
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.
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
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.
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).