dead-flat traceplots: what's going on?

[Greg Werbin]

Hi all,

I'm getting dead-flat traceplots for this model (attached file) and I'm not sure what's going wrong. My guess (hope?) is that I've made a mistake in the code, rather than a mistake in the math.

It also seems to take a very very long time at the beginning of the warm-up phase, when I get lots and lots of these:

Informational Message: The current Metropolis proposal is about to be rejected because of the following issue:
stan::prob::gamma_cdf(N4stan5agrad3varE): Shape parameter is inf:0, but must be finite!
If this warning occurs sporadically, such as for highly constrained variable types like covariance matrices, then the sampler is fine,
but if this warning occurs often then your model may be either severely ill-conditioned or misspecified.

Stan had given me an error when I tried to put a constraint on shape, which is what I'm assuming the message is warning me about.

Here is R's output for the "sampler_params" attribute of the stanfit object's sim slot, after one chain of 25 iterations (more iterations don't seem to change anything):

attr(,"sampler_params")$accept_stat__
 [1] 0.03189612 0.00000000 0.00000000 0.00000000 0.00000000 0.00000000 0.00000000 0.00000000 0.00000000
[10] 0.00000000 0.00000000 0.00000000 0.00000000 0.00000000 0.00000000 0.00000000 0.00000000 0.00000000
[19] 0.00000000 0.00000000 0.00000000 0.00000000 0.00000000 0.00000000 0.00000000


attr(,"sampler_params")$stepsize__
 [1] 1.001042e-146  2.474486e+00  2.482122e-01  1.817540e-02  1.171887e-03  7.278396e-05  4.566827e-06
 [8]  2.971688e-07  2.034492e-08  1.476587e-09  1.140058e-10  9.373455e-12  1.390069e-08  1.390069e-08
[15]  1.390069e-08  1.390069e-08  1.390069e-08  1.390069e-08  1.390069e-08  1.390069e-08  1.390069e-08
[22]  1.390069e-08  1.390069e-08  1.390069e-08  1.390069e-08


attr(,"sampler_params")$treedepth__
 [1] 7 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1


attr(,"sampler_params")$n_leapfrog__
 [1] 116   1   1   1   1   1   1   1   1   1   1   1   1   1   1   1   1   1   1   1   1   1   1   1   1


attr(,"sampler_params")$n_divergent__
 [1] 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

[Daniel Lee]

Where are the traceplots?

--
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/d/optout.

[Ben Goodrich]

According to https://en.wikipedia.org/wiki/Copula_%28probability_theory%29#Gaussian_copula , the Gaussian copula density function is


Your last line

Z[i] ~ multi_normal_cholesky(zeroes, R_L);

doesn't do the equivalent of that. You have to use increment_log_prob().

Ben

[Greg Werbin]

Thanks. I did that, and now I'm getting this error when I try to sample:

Error : 

Initialization between (-2, 2) failed after 100 attempts. 

 Try specifying initial values, reducing ranges of constrained values, or reparameterizing the model.

error occurred during calling the sampler; sampling not done

I attached the second version of my code. I also made some other changes. Am I abusing the ability to declare variables in the model block? Only the regression coefficients are unbounded in the parameters block; surely it can't be the case that there are 100 values between -2 and 2 that are valid for one of the coefs. Or is some kind of initialization happening for other values as well?

And I guess here's a feature request: have the warning message state which parameter failed to initialize.

[Bob Carpenter]

My guess is that you're using a variable
somewhere that's not defined. print() is a good way to debug this.
Just print variable values before you use them and you'll usually see
where one snuck by that wasn't initialized.

The other altnernative is tha tyou have some densities that evaluate
to NaN.

Also, the model as written is going to be very inefficient because
you're computing determinants repeatedly rather than computing them
once and re-using the value. There's also a log_determinant function
that should be more stable than log(determinant(Sigma)), which is prone
to underflow or overflow.

More below on specifics.

> On Dec 17, 2014, at 4:57 PM, Greg Werbin <ourob...@gmail.com> wrote:
>
> Thanks. I did that, and now I'm getting this error when I try to sample:
>
> Error :
>
> Initialization between (-2, 2) failed after 100 attempts.
> Try specifying initial values, reducing ranges of constrained values, or reparameterizing the model.
>
> error occurred during calling the sampler; sampling not done
>
> I attached the second version of my code. I also made some other changes. Am I abusing the ability to declare variables in the model block? Only the regression coefficients are unbounded in the parameters block; surely it can't be the case that there are 100 values between -2 and 2 that are valid for one of the coefs. Or is some kind of initialization happening for other values as well?

Initialization happens for all variables declared as parameters.
We try 100 random initializations of all parameters, and in your
case, none of the 100 random initializations were valid.

This usually means variables not defined or violations of constraints,
though that's usually diagnosed with a warning message.

>
> And I guess here's a feature request: have the warning message state which parameter failed to initialize.

Making this more informative is already pending as a feature request:

https://github.com/stan-dev/stan/issues/779

But it's not going to be able to isolate a "which parameter failed to initialize"
because initialization doesn't work that way. There are two potential failure
points,

1. while reading in inits from a file or data list/function in R.

a. missing value for some parameter

b. parameter given value that violates constraint

2. while executing log density

Case (1) can be isolated to a given parameter. Case (2) arises when some
parameters aren't consistent. For instance, a, b, and c in:

a ~ uniform(b,c);

This requires a to be initialized between b and c, so there are
multiple ways to fix it by changing subsets of a,b,c. In some cases,
for some mathmetical functions, we'll get inputs to a non-primitive
function that throws an exception and that we can trap and list. If
the density just evaluates to -infinity or NaN through primitive
operations (like adding -1/0 as a term), then there's really no way for
us to catch it --- you need to add print statements to figure out when
the log density goes wrong.

- Bob

[Ben Goodrich]

I meant you just needed to add

increment_log_prob(0.5 * dot_self(Z[i]));

to the loop to account for the

-0.5 * Z' * (-I) * Z

part of the log copula density. In other words, what you had only did the

-log(R) - 0.5 * Z' * solve(R) * Z

part. You need both parts to obtain

-log(R) - 0.5 * (Z' * (solve(R) - I) * Z)

Ben