Sample from prior

[Marcel Jonker]

I'm trying to draw random samples from several lognormal distributions, and even though my code compiles -and runs- I get different results for the mean of s and t (which should be very close in each iteration). Also the mean of u and v are unexpected - did I do something wrong?

parameters {
  vector<lower=0>[100000] s;
  vector<lower=0>[100000] t;
  vector<lower=0.015,upper=10>[100000] u;
  vector<lower=0.015,upper=10>[100000] v;
}
model {
  s ~ lognormal(-0.845   , 1.3);

  for (n in 1:10000){
    t[n] ~ lognormal(-0.845   , 1.3);
    u[n] ~ lognormal(-0.845   , 1.3)T[0.015,10];
    v[n] ~ lognormal(-0.68624 , 1.3)T[0.015,10];
  }

  print(mean(s));
  print(mean(t));
  print(mean(u));
  print(mean(v));
  print("");
}

Thanks,
Marcel

[Daniel Lee]

Hi Marcel,

The print statements aren't in the right place for you to monitor the means of the samples. The print statements are printing the means at each leapfrog step. From the manual (pg. 152):

Print Frequency

Printing for a print statement happens every time it is executed. The transformed data block is executed once per chain, the transformed parameter and model blocks once per leapfrog step, and the generated quantities block once per iteration.

Here's how to fix your code to get the behavior you want:

parameters {
  vector<lower=0>[100] s;
  vector<lower=0>[100] t;
  vector<lower=0.015,upper=10>[100] u;
  vector<lower=0.015,upper=10>[100] v;

}
model {
  s ~ lognormal(-0.845   , 1.3);

  for (n in 1:100){

    t[n] ~ lognormal(-0.845   , 1.3);
    u[n] ~ lognormal(-0.845   , 1.3)T[0.015,10];
    v[n] ~ lognormal(-0.68624 , 1.3)T[0.015,10];
  }
}

generated quantities {
  real mean_s;
  real mean_t;
  real mean_u;
  real mean_v;

  mean_s <- mean(s);
  mean_t <- mean(t);
  mean_u <- mean(u);
  mean_v <- mean(v);
}

I've dropped the number of samples down to 100 because it illustrates the behavior fine. There was an error in your original code: the loop over n is off by a factor of 10. This may have also messed with the mean. For u and v, these would have been bounded between the lower and upper, but for s and t, they could be sampled to be any positive number.

I would also change the statements for sampling u and v to not have the truncation points since it matches the support of the variables. This is just adding computation time.

Note: I think that the print statements aren't working in generated quantities block. I'll add an issue and hopefully we'll have that fixed soon.


Daniel

--
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.
 
 

[M.F. Jonker]

Hi Daniel,

Is there perhaps a way to suppress the output of certain parameters in the parameter block? The .csv output file contains hundreds/thousands of unnecessary variables..

Best,
Marcel

[Bob Carpenter]

On 2/21/13 12:03 PM, M.F. Jonker wrote:

> Is there perhaps a way to suppress the output of certain parameters in the parameter block? The .csv output file
> contains hundreds/thousands of unnecessary variables..

Not in the CSV output from the command. RStan lets
you select which variables to save/display.

If these are transformed parameters you don't want
to see you can redefine them as local variables
in the model and they won't get printed.

- Bob

[Ben Goodrich]

On Thursday, February 21, 2013 12:03:14 PM UTC-5, Marcel Jonker wrote:

Is there perhaps a way to suppress the output of certain parameters in the parameter block? The .csv output file contains hundreds/thousands of unnecessary variables.

It can be done from RStan if you specify the pars argument as a character vector of quantities to retain the samples of. This is somewhat dubious because technically you still need convergence of the parameters you don't care about, which you can't evaluate if you don't retain them.

Nevertheless, I too have wished that Stan would have a primitive parameters {} block that would go before parameters {} and have the same syntax, except that the primitive parameters wouldn't get stored.

Ben