stan syntax

27 views
Skip to first unread message

Jack Tanner

unread,
Mar 31, 2012, 9:45:09 AM3/31/12
to stan...@googlegroups.com
How set in stone is stan syntax at this date?

As a case in point, lately I've been writing BUGS/JAGS models, and I
came across this inconsistency.

If you have a univariate normal parameter, you can write:

alpha ~ dnorm(0, 0.001)

If you have a multivariate normal parameter, you have to write:

alpha ~ dmnorm(mu[], tau[,])

and then you have to define mu[] and tau[,] in the data that you pass to
BUGS. It'd be more convenient and consistent to define mu[] and tau[,]
directly in the model file, not in the data.

Ben Goodrich

unread,
Mar 31, 2012, 3:44:45 PM3/31/12
to stan...@googlegroups.com
I don't think anything in stan is set in stone, but the stan syntax already avoids your complains about BUGS / JAGS.

If mu and / or Sigma (covariance matrix) are parameters, then you can define them in the parameters, transformed parameters, or model sections. For example,

parameters {
  cov_matrix(K) Sigma;
}

where K is known and defined in the data section. There are several choices for a prior density for Sigma in stan.

You might use the transformed parameters section if you wanted a covariance matrix for an AR1 process where Sigma is a function of rho and sigma^2. You might use the model section if you considered Sigma to be a nuisance parameter and didn't want to store the draws for it.

If mu and tau (precision matrix) are fixed constants, then you can define them in the data or transformed data sections. Actually, at the moment we do not have a version of the multivariate normal density that takes a precision matrix, so your code would be much faster if you increment the log posterior yourself in the model section with something like

lp__ <- lp__ - 0.5 * (x - mu)' * tau * (x - mu);

when both x and mu are defined as vectors.

Eventually, we will probably add convenience functions for AR1, multivariate normal parameterized with a precision matrix, etc. But in the meantime, stan is certainly capable of letting the user implement these things manually.

Ben

Bob Carpenter

unread,
Mar 31, 2012, 3:54:57 PM3/31/12
to stan...@googlegroups.com
The syntax isn't set in stone. But it's
pretty solid at this point. I'm writing up
that part of the manual over the weekend so things
will be clearer.

As Ben says, you can define constants in the
"transformed data" section of the model file,
which is for any variables that can be defined
solely in terms of the variables in the "data" block
or earlier in the "transformed data" block.

Also, you won't need the brackets. It'll look
like:

transformed data {
covar_matrix(2) Sigma;
vector(2) mu;

Sigma[1,1] <- 1.7;
Sigma[2,2] <- 1.3;
Sigma[1,2] <- 0.4;
Sigma[2,1] <- Sigma[1,2];

mu[1] <- 3.7;
mu[2] <- -14.2;
}
model {
y ~ multi_normal(mu,Sigma);
...
}

I keep thinking I should add a literal assignment syntax for
matrices, to allow something like:

Sigma <- ((1,7. 0.4),
(0.4, 1.3));

mu <- (3.7, -14.2);

or even a general expression that would allow variables
or other expressions as well as constants.

It's on the to-do list, but I'm in the middle
of trying to refactor the parser to break it into
multiple translation units to ease the burden on
the C++ compilers and assemblers.

We'll also be adding other parameterizations and vectorized
versions for multiple samples.

We will try very very hard to keep the model syntax
backwards compatible.

You can look in the directory of BUGS examples for more
examples of Stan's syntax.

- Bob

Reply all
Reply to author
Forward
0 new messages