RStan Initial Value Set Error

[Ryan Brackney]

Thanks to everyone who's answered my questions in the past. I have some new issues trying set the initial parameter values of different chains.  

I have a model with two parameters, "lambda" and "delta_unbound," and am trying to run four chains.

If I set the inits like this:

init_list = list(c1=list(lambda=1,delta_unbounded = 1), 

             c2=list(lambda=2,delta_unbounded = 2), 

             c3=list(lambda=3,delta_unbounded = 3), 

             c4=list(lambda=4,delta_unbounded = 4))

fit1 <- stan(file = 'model_shiftedex.stan', data = exp_dat, 

             iter = 100, chains = 4, init = init_list)

Using this option, Stan only samples from the initial values, and never varies from them. 

I've seen on this listserv that you may need to have a function that returns your initial values. Trying this however does no better:

init_fun = function() { 

  return(list(c1=list(lambda=1,delta_unbounded = 1), 

                     c2=list(lambda=2,delta_unbounded = 2), 

                     c3=list(lambda=3,delta_unbounded = 3), 

                     c4=list(lambda=4,delta_unbounded = 4))); 

} 

fit1 <- stan(file = 'model_shiftedex.stan', data = exp_dat, 

             iter = 100, chains = 4, init = init_fun() )

Any idea what I might be doing wrong?

[Bob Carpenter]

The stan() doc says this for init:

One of digit 0, string "0" or "random", a function that returns a named list, or
a list of named list. "0": initialize all to be zero on the unconstrained support;
"random": randomly generated, see optional parameter init_r; list: a list of lists
equal in length to the number of chains (parameter chains), where each named list
(an element of the list of lists) specifies the initial values for parameters by
names for a chain. function: a function that returns a list for specifying the
initial values of parameters for a chain. The function can take an optional parameter
chain_id. See below notes on that RStan treats a vector of length 1 as a scalar

Here is a simple example of the list of named lists approach:

> fit <- stan('simple.stan',
init=list(list(mu=-10000,sigma=10), list(mu=20, sigma=0.1)),
chains=2);

Here's an example of using a function:

> init_fun <- function() { list(mu=runif(1,-1000,1000), sigma=runif(1,0,10)) }

> fit <- stan('simple.stan', init=init_fun, chains=2)

The doc's a little unclear for someone like me who's not a heavy
R user. So I created an issue in RStan to update the doc with examples:

https://github.com/stan-dev/rstan/issues/29

- Bob

> --
> You received this message because you are subscribed to the Google Groups "stan users mailing list" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to stan-users+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Ryan Brackney]

Thanks Bob. As I'm also not a heavy R user, having examples really helps.

I'm readjusted my code slightly to fall in line with your examples. I'm still having the same issue however.

Not specifying the initial values results in normal sampling:

fit1 <- stan(file = 'model_shiftedex.stan', data = exp_dat, 

             iter = 10, chains = 2)

However, specifying the initial values using the format you specified still results in only sampling the initial values for 'delta_unbounded' and even more strangely, only zero for 'lambda'.

fit1 <- stan(file = 'model_shiftedex.stan', data = exp_dat, 

             iter = 10, chains = 2, init = list(list(lambda=2 ,delta_unbounded = 1), list(lambda=4,delta_unbounded = 2)) )

I've included a cleaned up copy of the r script and model, in case there's something pertinent to the issue in them.

Thanks again!

[Ryan Brackney]

I've spent a little more time exploring this issue, and I'm starting to wonder whether it's there's a bug in STAN instead of an issue with my own ignorance. I ran a simple experiment in which I set initial values for a model using a simple normal distribution, or a simple exponential distribution. 

In both cases, I ran the model without overtly setting the initial values of the chain. I then took the STAN generated initial values, using the "get_inits" function, and reran the model with those initial values that were previously used.

The normal distribution model runs fine this way. However, the exponential model reverts the initial values to the lower bounds of lambda, and only samples from that. In other words, the exponential model works just fine when allowing STAN to decide the initial values, but when you declare the initial values, even using previous ones that STAN decided on itself, it reverts to only sampling the declared lower bound of the lambda as the parameter value.

Since the model I'm actually trying to run (not these examples) relies heavily on exponential distributions, this is a big problem for me. I was wondering if any of the Devs (or someone else) could comment on whether this is in fact a bug, or if I'm completely missing something? 

I've attached the models, and the R script that I used to test this. 

Thanks again!

Ryan

On Wednesday, 27 November 2013 14:04:39 UTC-7, Ryan Brackney wrote:

Thanks Bob. As I'm also not a heavy R user, having examples really helps.

I'm readjusted my code slightly to fall in line with your examples. I'm still having the same issue however.

Not specifying the initial values results in normal sampling:

fit1 <- stan(file = 'model_shiftedex.stan', data = exp_dat, 

             iter = 10, chains = 2)

However, specifying the initial values using the format you specified still results in only sampling the initial values for 'delta_unbounded' and even more strangely, only zero for 'lambda'.

fit1 <- stan(file = 'model_shiftedex.stan', data = exp_dat, 

             iter = 10, chains = 2, init = list(list(lambda=2 ,delta_unbounded = 1), list(lambda=4,delta_unbounded = 2)) )

I've included a cleaned up copy of the r script and model, in case there's something pertinent to the issue in them.

Thanks again!

On Wednesday, 27 November 2013 13:37:10 UTC-7, Bob Carpenter wrote:

[Ross Boylan]

On Tue, 2013-12-03 at 15:44 -0800, Ryan Brackney wrote:
> I've spent a little more time exploring this issue, and I'm starting
> to wonder whether it's there's a bug in STAN instead of an issue with
> my own ignorance. I ran a simple experiment in which I set initial
> values for a model using a simple normal distribution, or a simple
> exponential distribution.
>
>
> In both cases, I ran the model without overtly setting the initial
> values of the chain. I then took the STAN generated initial values,
> using the "get_inits" function, and reran the model with those initial
> values that were previously used.
>
>
> The normal distribution model runs fine this way. However, the
> exponential model reverts the initial values to the lower bounds of
> lambda, and only samples from that.

What exactly do you mean by "reverts"?

If you mean the chain ends up at the lower bounds, you may have a
problem getting estimates from the initial values, but not a difference
based on how you set the initial values.

Specifically, your script has (with labels added)
#run a exponential distribution fit without specific initial values
# fit 1
exp_fit1 <- stan(file = 'model_ex_simple.txt', data = norm_dat,
iter = 100, chains = 2)
used_exp_inits1 <- get_inits(exp_fit1)
la_exp1 <- extract(exp_fit1)

#rerun the exponential distribution fit with the previously used initial values
# fit 2
exp_fit2 <- stan(file = 'model_ex_simple.txt', data = norm_dat,
iter = 100, chains = 2, init = used_exp_inits1)

used_exp_inits2 <- get_inits(exp_fit2)
la_exp2 <- extract(exp_fit2)

are you saying the chains from fit 1 and fit 2 are different?

Your problem sounds similar to mine (see the "tuning troubles" thread
from last month). For some initial values the chain simply stayed on
the initial values for every step. It sounds as if you got some
movement, but it moved to a point at which it stuck (like my initial
values).

I suggest setting the seed argument to assure you (and others) can
reproduce your results. Actually, I'm not sure if the seed argument to
stan will affect the initial value creation (previous discussion on this
list said it would not affect the values drawn from a user-defined
initialization function, but you are not using such a function). To be
sure, you could call set.seed at the start of the script (as well as
using the seed argument to the stan function).

Ross

[Bob Carpenter]

On 12/3/13, 8:16 PM, Ross Boylan wrote:
> On Tue, 2013-12-03 at 15:44 -0800, Ryan Brackney wrote:
>> I've spent a little more time exploring this issue, and I'm starting
>> to wonder whether it's there's a bug in STAN instead of an issue with
>> my own ignorance. I ran a simple experiment in which I set initial
>> values for a model using a simple normal distribution, or a simple
>> exponential distribution.
>>
>>
>> In both cases, I ran the model without overtly setting the initial
>> values of the chain. I then took the STAN generated initial values,
>> using the "get_inits" function, and reran the model with those initial
>> values that were previously used.
>>
>>
>> The normal distribution model runs fine this way. However, the
>> exponential model reverts the initial values to the lower bounds of
>> lambda, and only samples from that.

> What exactly do you mean by "reverts"?

I assume you (Ryan) mean that the only value sampled for
the parameter is the lower bound. This could indicate a problem
with the model, the data, or with Stan itself.

By the way, you don't need the upper=positive_infinity()
constraint --- no constraint is the default. It's OK
to leave it --- there's just a run-time conditional evaluation
that reduces it to the lower-bound-only transform if there is a +infinity
upper bound.

> If you mean the chain ends up at the lower bounds, you may have a
> problem getting estimates from the initial values, but not a difference
> based on how you set the initial values.
>
> Specifically, your script has (with labels added)
> #run a exponential distribution fit without specific initial values
> # fit 1
> exp_fit1 <- stan(file = 'model_ex_simple.txt', data = norm_dat,
> iter = 100, chains = 2)
> used_exp_inits1 <- get_inits(exp_fit1)
> la_exp1 <- extract(exp_fit1)
>
> #rerun the exponential distribution fit with the previously used initial values
> # fit 2
> exp_fit2 <- stan(file = 'model_ex_simple.txt', data = norm_dat,
> iter = 100, chains = 2, init = used_exp_inits1)
>
> used_exp_inits2 <- get_inits(exp_fit2)
> la_exp2 <- extract(exp_fit2)
>
> are you saying the chains from fit 1 and fit 2 are different?

Unless you specify a seed in the call to Stan, you can expect
results to vary across calls.

> Your problem sounds similar to mine (see the "tuning troubles" thread
> from last month). For some initial values the chain simply stayed on
> the initial values for every step. It sounds as if you got some
> movement, but it moved to a point at which it stuck (like my initial
> values).
>
> I suggest setting the seed argument to assure you (and others) can
> reproduce your results. Actually, I'm not sure if the seed argument to
> stan will affect the initial value creation (previous discussion on this
> list said it would not affect the values drawn from a user-defined
> initialization function, but you are not using such a function).

The seed passed to Stan determines all randomization within calls to stan().

I'm pretty sure that includes initialization if you don't specify initial
values. Our intent is to make the results exactly reproducible. I opened
an issue to clarify the RStan doc on this point:

https://github.com/stan-dev/rstan/issues/31

> To be
> sure, you could call set.seed at the start of the script (as well as
> using the seed argument to the stan function).

set.seed() will determine the randomization within R.

If you use a specified seed in the function stan(), set.seed() won't have
any effect on the sampling within the call to stan().

If you do not specify a seed for the call to stan(), then R generates
the seed and passes it to Stan. (See the doc for stan() in the RStan doc.)

- Bob

[Ryan Brackney]

Thanks for the notes, Bob and Ross. To clarify, in the exponential, set init case, the chain starts at the lowerbound, and stays there, in other words, the chains for the first and second run are very different. 

 The only difference between the runs is that Stan decided on the inits in the first run, and in the second run those very same inits are instead declared ahead of time. The data and model are the same in both cases, which is what makes me think this is an issue with Stan. 

[Bob Carpenter]

On 12/3/13, 9:11 PM, Ryan Brackney wrote:
> Thanks for the notes, Bob and Ross. To clarify, in the exponential, set init case, the chain starts at the lowerbound,
> and stays there, in other words, the chains for the first and second run are very different.
>

> The /only /difference between the runs is that Stan decided on the inits in the first run, and in the second run those

> very same inits are instead declared ahead of time. The data and model are the same in both cases, which is what makes
> me think this is an issue with Stan.

I want to tease apart two issues here.

1. Reproducible inits

Whether the behavior is reproducible using inits. You
should get the same behavior if you specify the same seeds for
the call. Can you try reproducing the problem using fixed
random seeds?

2. Sampler getting stuck

Whether it's a bug in Stan for samples not to move is another
issue. That's usually a model problem, but can indicate
a problem in Stan. Diagnosing these kinds of problems with models
is one of the reasons we recommend using a diffuse set of initial
values.

Samples for parameters can get pinned at boundaries if the boundary
were removed and the probability mass is beyond the boundary.
For instance, if I do this:

parameters {
real<lower=10> y;
}
model {
y ~ normal(0,1);
}

you would expect to see the samples converge to y=10 in warmup
and then not move (or move very very little).

- Bob

[Jiqiang Guo]

On Tue, Dec 3, 2013 at 9:00 PM, Bob Carpenter <ca...@alias-i.com> wrote:

On 12/3/13, 8:16 PM, Ross Boylan wrote:

On Tue, 2013-12-03 at 15:44 -0800, Ryan Brackney wrote:

I've spent a little more time exploring this issue, and I'm starting
to wonder whether it's there's a bug in STAN instead of an issue with
my own ignorance. I ran a simple experiment in which I set initial
values for a model using a simple normal distribution, or a simple
exponential distribution.


In both cases, I ran the model without overtly setting the initial
values of the chain. I then took the STAN generated initial values,
using the "get_inits" function, and reran the model with those initial
values that were previously used.


The normal distribution model runs fine this way. However, the
exponential model reverts the initial values to the lower bounds of
lambda, and only samples from that.

What exactly do you mean by "reverts"?

I assume you (Ryan) mean that the only value sampled for
the parameter is the lower bound.  This could indicate a problem
with the model, the data, or with Stan itself.

By the way, you don't need the upper=positive_infinity()
constraint --- no constraint is the default.  It's OK
to leave it --- there's just a run-time conditional evaluation
that reduces it to the lower-bound-only transform if there is a +infinity
upper bound.

It seems it is not ok to leave it for now.  In the code about a model with exponential data posted by Ryan, the initial values for the call of stan() should be the same  since the latter one uses the one returned from the previous one. But it's not the same.  I guess it is because of the positive_infinity() constraint. 

--

Jiqiang 

[Bob Carpenter]

If so, this is a bug in Stan.

real<lower=x, upper=positive_infinity()> y; // (1)

should behave identically to:

real<lower= x> y; // (2)

The code that tries to make sure they're same is on line 696 of prob/transform.hpp:

if (ub == std::numeric_limits<double>::infinity())
return lb_constrain(x,lb);

And on line 145 of test/prob/transform_test.cpp there's a test:

EXPECT_FLOAT_EQ(stan::prob::lb_constrain(1.8,3.0),
stan::prob::lub_constrain(1.8,
3.0,
+std::numeric_limits<double>::infinity()));

If someone can create an example where Stan produces different values given
the same inits and same seed for the two declarations (1) and (2), I'll create
an issue and track it down.

- Bob

On 12/4/13, 5:58 PM, Jiqiang Guo wrote:

[Jiqiang Guo]

I created an issue https://github.com/stan-dev/stan/issues/432

It behaves somehow differently in Stan, but I think there is a bug. 

--

Jiqiang

To unsubscribe from this group and stop receiving emails from it, send an email to stan-users+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "stan users mailing list" group.

To unsubscribe from this group and stop receiving emails from it, send an email to stan-users+unsubscribe@googlegroups.com.