Problem with static HMC

Modeling
1

[Please include Stan program and accompanying data if possible]

I was trying to use the “Fixed_param” algorithm to draw from a standard normal distribution and found that it a) fails to accept any proposal , b) always output 0 log posterior .

// Stan code
parameters{
real mu;
}
model{
mu ~ normal(0,1);
}

library(rstan)
fit ← stan(file=‘st_normal.stan’, algorithm=“Fixed_param”,
iter=1200, control=list(stepsize=0.1,int_time=1),warmup=500, chains=1)
as.matrix(fit)[1:5,]
fit2 ← stan(file=‘st_normal.stan’, algorithm=“HMC”,
iter=1200, control=list(stepsize=0.1,int_time=1),warmup=500, chains=1)
as.matrix(fit2)[1:5,]

as.matrix(fit)[1:5,]
parameters
iterations mu lp__
[1,] -0.8627348 0
[2,] -0.8627348 0
[3,] -0.8627348 0
[4,] -0.8627348 0
[5,] -0.8627348 0

as.matrix(fit2)[1:5,]
parameters
iterations mu lp__
[1,] 1.8232918 -1.6621964
[2,] 1.4243932 -1.0144480
[3,] -0.8341524 -0.3479051
[4,] -2.0904505 -2.1849916
[5,] -2.4378438 -2.9715412

2

I am not sure how you would expect something with fixed parameters to yield anything other than constant output. Just use the default MCMC algorithm.

3

There isn’t a lot of documentation on what algorithm=“Fixed_param” does exactly. So it is not actually a sampler since it produces constant output? I just thought it is the static HMC algorithm where nothing gets adapted.

For example, what’s the difference between algorithm= “Fixed_param” and algorithm=“HMC”?

4

algorithm="Fixed_param" fixes the parameters and hence is really only useful if you supply initial values for them and care about what is in the generated quantities block. algorithm="HMC" samples the parameters but with static integration time, which is really only useful if you want to demonstrate that sampling with static integration time is worse than algorithm="NUTS".

5

I don’t understand your explanation of Fixed_param . What do you mean by a generated quantities block ? What would be an example use case of algorithm="Fixed_param" ?

6

There are very few use cases for algorithm="Fixed_param". I have heard second or third-hand that a single-digit number of people have used it to simulate data from complicated data-generating processes that do not have a better algorithm for pseudo-random number generation. A simple but useless example would be

data {
  int<lower=0> N;
}
parameters {
  real mu;
  real<lower=0> sigma;
}
generated quantities {
  vector[N] x;
  for (n in 1:N) x[n] = normal_rng(mu, sigma);
}
7

Just adding: That this is the way algorithm = "Fixed_param" works was unclear to me as well. As @Yiu_Lau said, there is little documentation about this, I do not remember finding this in the manual (and then simply not caring enough to try it out). As a starting user, I would suggest/be happy about a sentence like this in the manual (either the Stan ref. itself or in the rstan (etc) manuals).

Enjoy your day!

8

See the Stan manual. It explains all the blocks in a Stan program and how they’re executed. It’s also where the various algorithms are described.

I’m all for making the RStan doc more explanatory. It’s easy to submit a pull request for something like this!

There’s a chapter describing the algorithms. The HMC chapter describes the differences between static HMC and NUTS, as well as how the adaptation parameters work. There is a section “sampling without parameters” that describes how and why to used “Fixed_param”. Sorry everything’s so hard to find!

9

Ah, thanks! I don’t know about the other interfaces, as I only use rstan, but then I would suggest adding “fixed_param” in that sentence about the “fixed-parameter setting” (p. 399 in my version). I was searching for that. Of course if this is named differently in other interfaces, this might not be feasible.

All in all, I am being very picky. I feel Stan is very well documented! Thanks!

10

You’re welcome. We have a ways to go before it’s well documented. Please be picky and let us know how we can improve. Even better, fire up your editor and GitHub and submit a pull request.

Also, it’s “Fixed_param” with the cap for some reason.

We’ll be trying to make everything more coherent across interfaces as we inch toward Stan 3.