Reminder of why should change our language

[Daniel Lee]

This was on the users list today. The whole message is below, but I've clipped the section that indicates the problem (I added bold for emphasis):

model {
 exp_subclinical[1] ~ uniform(1,upper_lambda1);
 for( oy in 2:n_years ){
   exp_subclinical[oy] ~ gamma(exp_subc_k, exp_subc_k/exp_subclinical[oy-1]);
 }
...
}

...

When I am running the model I get Metropolis proposals rejected because of:

Exception thrown at line 104: stan::math::gamma_log: Inverse scale parameter is -61.6392, but must be > 0!

I don't understand how the inverse scale parameter can become negative, being the division of a positive value by a value which is either from a uniform(1,some positive value I supplied) or a gamma distribution.

I don't think we'll break this notion of not generating a random number from a distribution without a change in language. I think novices will continue to think this as long as this is around. I think the change will help -- not sure what new users will think, but hopefully they won't assume we're generating random numbers.

Daniel

---------- Forwarded message ----------
From: <rcdr...@gmail.com>
Date: Thu, Feb 4, 2016 at 10:35 AM
Subject: [stan-users] gamma_log encountering negative inverse scale parameter
To: Stan users mailing list <stan-...@googlegroups.com>

Hi,

I'm having some problems with a model I'm trying to run.

I have a series of values I'm trying to estimate and am fitting them as a random walk.

So in the parameters section I have:

parameters {
...
 real exp_subclinical[n_years];
...
}

where n_years is an integer passed in as data, and in the model section:

model {
 exp_subclinical[1] ~ uniform(1,upper_lambda1);
 for( oy in 2:n_years ){
   exp_subclinical[oy] ~ gamma(exp_subc_k, exp_subc_k/exp_subclinical[oy-1]);
 }
...
}

where exp_subc_k is a positive number provided as part of the data.

When I am running the model I get Metropolis proposals rejected because of:

Exception thrown at line 104: stan::math::gamma_log: Inverse scale parameter is -61.6392, but must be > 0!

Line 104 is the line within the for loop with the gamma sampling statement, and there can be quite a lot of these messages.

I don't understand how the inverse scale parameter can become negative, being the division of a positive value by a value which is either from a uniform(1,some positive value I supplied) or a gamma distribution.

I did not observe this when I initially ran the problem for few iterations with unrealistic initial values (all exp_subclinical were 1000) but did when running for many iterations - the values of exp-subclinical decline from 1:n_years so providing more realistic initial values lets me see the problem at lower numbers of iterations and would indicate that it is related to low exp_subclinical values.

I have tried this with cmdstan and rstan with the same outcome.

Why would this be happening?

Thanks.

--
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.
To post to this group, send email to stan-...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jonah Gabry]

Yeah, and when I responded to him I didn't even go into that. I just tried to help him declare the parameters with the proper constraints. But maybe I should have also said that it's not actually drawing a value.

[Jonah Gabry]

On Thursday, February 4, 2016 at 12:07:58 PM UTC-5, Jonah Gabry wrote:
> Yeah, and when I responded to him I didn't even go into that. I just tried to help him declare the parameters with the proper constraints. But maybe I should have also said that it's not actually drawing a value.

Actually I think I will do that now.

[Bob Carpenter]

The problem wasn't an undefined variable, but a lack of constraint
in a parameter declaration:

> parameters {
> ...
> real exp_subclinical[n_years];
> ...
> }

> model {
> exp_subclinical[1] ~ uniform(1,upper_lambda1);
> for( oy in 2:n_years ){
> exp_subclinical[oy] ~ gamma(exp_subc_k, exp_subc_k/exp_subclinical[oy-1]);
> }

> I don't understand how the inverse scale parameter can become negative, being the division of a positive value by a value which is either from a uniform(1,some positive value I supplied) or a gamma distribution.

Do you think having them write this:

target += uniform_lpdf(exp_subclinical[1] | 1, upper_lambda1);
for (oy in 2:n_years)
target += gamma_lpdf(exp_subclinical[oy] | exp_subc_k,
exp_subc_k / exp_subclinical[oy-1]);

would've made it clear to them that their variable needed
a constraint?

This might be something we can catch for at least simple variables.

- Bob

[Jonah Sol Gabry]

On Thu, Feb 4, 2016 at 2:26 PM, Bob Carpenter <ca...@alias-i.com> wrote:

The problem wasn't an undefined variable, but a lack of constraint
in a parameter declaration:

That was the problem with his Stan program, but I think Daniel was referring to the fact that later in the original post the author also thought that Stan was generating values from the priors instead of just incrementing lp.

 

Do you think having them write this:

  target += uniform_lpdf(exp_subclinical[1] | 1, upper_lambda1);
  for (oy in 2:n_years)
    target += gamma_lpdf(exp_subclinical[oy] | exp_subc_k,
                                               exp_subc_k / exp_subclinical[oy-1]);

would've made it clear to them that their variable needed
a constraint?

No I don't think the constraints problem would have been any more clear if it had to be written that way, but he maybe have been blessed confused about sampling from the prior vs incrementing lp. 

[Jonah Sol Gabry]

Weird autocorrect there. 

he maybe have been blessed confused 

should be 

he maybe would have been less confused 

[Michael Betancourt]

Agreed — in this case the user assumed that the gamma distribution

imposed the constraint for them, which was the source of the confusion.

The language change wouldn’t make the right answer any more obvious,

but it would make the wrong answer more clear.