'lub_free' error, possible bug when initializing parameters bounded by other parameters

Developers
1

I am using CmdStanR 0.1.3, cmdstan-2.24.1, and R 3.4.4 on an Ubuntu computer. I installed CmdStan via CmdStanR a few days ago.

I ran into the following error when providing an initial parameter value to a parameter whose upper bound was another parameter.

“lub_free: Bounded variable is 0.0001, but must be in the interval [0, -3.76792]”

and in my stan code I have:

parameters{
    real<lower=0> mu; 
    real<lower=0, upper=mu> killrate;
...

In R, I created a list of lists for initial parameter values where killrate was initialized to 0.0001 and mu was initialized to 0.0231. As in

myinits = list()
for (c in 1:nChains){
    myinits[[c]] = list("mu"=0.0231, "killrate"=0.0001)
}
...
myStanModel = cmdstan_model(mystanfile, cpp_options = list(stan_threads = TRUE))
myStanFit <- myStanModel$sample(data = datalist, init=myinits, ...

You will notice that log(0.0231) is precisely -3.76792.

Why is the log-transformed value of mu being used for the upper bound? Is this a bug? Or am I misreading the manuals?
From the Stan manuals’ examples, I don’t see instructions to initialize parameters with log-transformed values when using the init option during sampling.

When I instead put this in my Stan model to correct this alleged bug, the model doesn’t show the above ‘lub_free’ error.

parameters{
    real<lower=0> mu;
    real<lower=0, upper=exp(mu)> killrate;

(Full report: My model isn’t running correctly right now, for what I believe is a separate overflow issue. When using exp(mu) as above, or when not providing any initial parameter values, I get the more mundane message: “Rejecting initial value: Log probability evaluates to log(0), i.e. negative infinity.”)

2

Hi Eric,

This is because when you pass an initial value for a constrained parameter (i.e., a lower bound), Stan assumes that the initial value is on the constrained scale, and unconstrains it before applying it to the parameter.

For your example specifically, when you declare a parameter with a lower bound:

real<lower=lb> mu;

Stan enforces that bound by sampling the transformation: exp(mu) + lb, which for a lower-bound of zero simplifies to exp(mu).

So when you’re passing an initial value of 0.0231 (on the constrained scale), you’re telling Stan that exp(mu) = 0.0231, or in other words mu = log(0.0231).

Cheers,
Andrew

3

Thanks Andrew!
One more question. Suppose my model contains unbounded/unconstrained and bounded/constrained parameters, and I want to pass initial parameter values. Should I use non-transformed values for the unconstrained parameters and transformed values (where the transform options are listed here) for the constrained parameters? In essence, I should I always be passing values in the domain that the chains actually traverse, right?

Looking back, I see that the Stan and RStan manuals can be read as assuming that chains will start at exactly the numeric values you provide. Thus, you should provide values that have been transformed. This fact is not explicitly stated anywhere, so I followed my own assumptions.

4

Yep, if you want to have specific values be supplied to constrained variables, you need apply the appropriate transformation to the initial values before supplying them. You can find more information about this in the Stan manual here: https://mc-stan.org/docs/2_24/reference-manual/initialization.html

5

This is a bug. Code like

parameters{
    real<lower=0> mu; 
    real<lower=0, upper=mu> killrate;
...

should never fail with a negative upper bound for killrate because if mu is negative then it’s the first and not the second statement that reports the problem. The old compiler did handle this correctly but the new compiler generates code that unconstrains mu and uses the unconstrained mu as the upper bound for killrate.

The fix is under way

2 Likes
6

Edit: Niko has addressed my concerns.
But for future readers I’ll post anyways.

Hi Andrew,

I have become confused again. The manual says that the transform applied to a variable with a lower bound is the log function, not the exp function. Doesn’t this mean that . I have a feeling that I’m just not reading the language correctly.

Also, the manual seems to say that Stan checks if user-supplied initial param values meet the constraints before it transforms the initial values. In the example for why one should not initialize real<lower=0, upper=1> theta with the value 0 because it will be transformed to -Inf, the user supplies 0 and not -Inf. Is this correct?

If I transform my initial values by what the manual says is the corresponding transformation, namely log and log-odds, then it is mu's value of -3.76792 that triggers the program to stop with “Lower bounded variable is -3.76792, but must be greater than or equal to 0”.

If I transform my initial values using the functions listed as “inverse transformations” in the manual, namely exp and inverse logit, I believe the new values aren’t unconstrained and instead are constrained to [1, Inf) instead of [0, Inf) for the exp case. But in this case I don’t get a constraint-related error, just one instance of “Log probability evaluates to log(0), i.e. negative infinity” followed by “Warning: Chain 1 finished unexpectedly”, which may be a separate problem.

1 Like
7

Silly question, but how do I know which version of Stan will contain the fix, and how do I obtain it?

8

It won’t be fixed until the next release, a month from now or so. In the meantime you could try the old compiler. I don’t know if CmdStanR has an option for it but you can find your CmdStan installation and add line

STANC2=true

to the file make/local (you probably need to create the file).

1 Like
9

Yeah this can be set via the cpp_options argument when compiling. For example:

mod <- cmdstan_model(stan_file, cpp_options = list(STANC2 = TRUE))