Clik here to view.
Putting priors on transformed parameters
In a lot of situations it’s easier to put priors on parameter transformations than on the immediate model parameters. When one does so, one is always greeted with the Stan warning that one should...
View ArticleClik here to view.
Putting priors on transformed parameters
Logit: when the warning is warranted, just HOW exactly does one augment the += statement? What does one write exactly? The right-hand side of the target += must be the logarithm of the absolute value...
View ArticlePutting priors on transformed parameters
Thank you tons, Ben. Great suggestion on using beta priors instead of normal. I can easily replace the priors for the above transformed parameters as follows: Group1Share ~ beta(50, 100); Group2Share...
View ArticlePutting priors on transformed parameters
If you are transforming intercept + b[i] with inv_logit — which is equivalent to logistic_cdf(intercept + b[i] | 0, 1), then your log-Jacobian is the sum of three terms involving the derivative of its...
View ArticlePutting priors on transformed parameters
I’m sorry if I’m sounding dense here, Ben, but just to be sure… When you wrote, logistic_lpdf(intercept + b | 0, 1) that’s just an example, right? One needs to replace the shape=0 and scale=1...
View ArticleClik here to view.
Putting priors on transformed parameters
There’s a chapter in the manual with examples on how to deal with Jacobians for non-linear transforms and when you’ll need them. Logit: When you wrote, logistic_lpdf(intercept + b | 0, 1) that’s just...
View ArticlePutting priors on transformed parameters
This is a fascinating discussion. I have a need to specify normal priors with varying \sigma for a user-given number c (including zero) of linear combinations of parameters in the model. Perhaps this...
View ArticlePutting priors on transformed parameters
Something like this? data { int p; // number of coefficients int c; // number of combinations matrix[c, p] C; // combinations vector[c] mus; // prior means vector[c] sigmas; // prior std. devs }...
View ArticlePutting priors on transformed parameters
Wow is it really that easy? Thanks! The one trick I’ve had to do is to keep a subset of the parameters outside of the QR decomposition of the design matrix so that the priors can be mapped to...
View ArticlePutting priors on transformed parameters
What a treat to be able to help you. I learnt a lot from your book and from your forum. I am not sure what you mean regarding the QR decomposition. Can you describe your issue and how you want to use...
View ArticlePutting priors on transformed parameters
Thanks for the nice words and for this great help. The description about the multiple priors makes sense. Regarding QR, I use a standard Stan approach for accelerating sampling by getting rid of...
View ArticlePutting priors on transformed parameters
This makes sense. In this situation I see no issue, because the held-out parameters do not enter the contrasts. You can specify any prior you want on them separately and there can be no conflict. Read...
View ArticlePutting priors on transformed parameters
In this case I would hold out parameters because they do enter contrasts. I want priors to be for contrasts on the original pre-QR parameter space. Read full topic
View ArticlePutting priors on transformed parameters
Marek my current model block looks like model { target += log_lik; target += normal_ldf(beta | 0, sds); ... } How would I bring in the prior for C*beta in this form? Is it as easy as target +=...
View ArticlePutting priors on transformed parameters
Yes, only it should be normal_lpdf, not normal_ldf. You can mix the ~ and the target += syntax by the way, so you can have model { target += log_lik; beta ~ normal(0, sds); C*beta ~ normal(mus, sds);...
View ArticlePutting priors on transformed parameters
I have implemented priors on contrasts in the upcoming new release of the rmsb package, in a way that makes it easy for the user to specify the contrasts. It’s written up here: Regression Modeling...
View Article
