issues with Stan

16 views
Skip to first unread message

Jiqiang Guo

unread,
Jul 13, 2013, 11:07:03 PM7/13/13
to stan...@googlegroups.com
While working on a BUG's example model with current develop branch,
I came across an issue, which might be reported before.  
While reproducing the issue with a simpler example, I came across other issues. 

First,  I have the following simple model:

transformed data {
  vector[3] y;
  vector[3] x;
  y[1] <- 1;
  y[2] <- 3;
  y[3] <- 2;
  x <- rep_vector(1.0, 3);
}
parameters {
  real beta;
}
transformed parameters {
  vector[2] mu;
  mu <- x * beta;
}

model {
  y ~ normal(mu, 1);
}

Obviously, here mu is wrongly declared, but it runs without a problem.  
So I guess it is an issue. 


Second, for the following wrong model (again mu is not correctly specified):

transformed data {
  matrix[3, 2] x;
  vector[2] beta;
  for (i in 1:3) for (j in 1:2)  x[i,j] <-  100 * i + j;
  for (i in 1:2) beta[i] <- i;
}
parameters {
  vector[3] y;
}

model {
  vector[2] mu;
  mu <- x * beta;
  y ~ normal(mu, 1);
}

I have the error message below (the tail part), which says it is non-fatal, but really it is. 

Informational Message: The parameter state is about to be Metropolis rejected due to the following underlying, non-fatal (really) issue (and please ignore that what comes next might say 'error'): error in call to assign_to_var; require matching sizes, but found arg1(rows=2,cols=1,size=2); arg2(rows=3,cols=1,size=3)
If the problem persists across multiple draws, you might have a problem with an initial state or a gradient somewhere.
 If the problem does not persist, the resulting samples will still be drawn from the posterior.
Rejecting proposed initial value with zero density.


Initialization failed after 100 attempts. 
 Try specifying initial values, reducing ranges of constrained values, or reparameterizing the model.


Last, is the following usage in the transformed data block not allowed?  Currently in the generated code, 
x would be matrix of 0 * 0 and beta is a vector of length 0. 

transformed data {
  int<lower=0> N;
  int<lower=0> p;
  matrix[N, p] x;
  vector[p] beta;
  N <- 3;
  p <- 2;
  for (i in 1:N) for (j in 1:p)  x[i,j] <-  100 * i + j;
  for (i in 1:p) beta[i] <- i;
}
parameters {
  vector[N] y;
}

model {
  vector[p] mu;
  mu <- 1 + x * beta;
  y ~ normal(mu, 1);
}

--
Jiqiang

Bob Carpenter

unread,
Jul 13, 2013, 11:56:29 PM7/13/13
to stan...@googlegroups.com
For #1, it looks like we need better tests on dimensionality
match under assignment. I created an issue and assigned it
to myself.

I'm in the middle of something else, but will get to
it before 2.0.

For #2, I'm not sure what to do. It's throwing the right
exception, but the behavior of the samplers is to treat
exceptions (and NaN returns) as -infinity log probability. This
argues for separating the -infinity/NaN case from the truly
exceptional case that Jiqiang provided. Maybe we could throw a
different type of exception? Or just go back to returning -infinity or NaN?

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

Michael Betancourt

unread,
Jul 14, 2013, 3:24:28 PM7/14/13
to stan...@googlegroups.com
Really the fatal message is the second, "Initialization failed" message -- the sampler warning is incidental. I think it's easier to just not print out the sampler warning during initialization, and maintain the same functionality elsewhere (otherwise it would be too hard trying to teach the sampler the difference between NaN and infinity).

Any objections?
Reply all
Reply to author
Forward
0 new messages