Re: [stan-users] rstan request

[Jiqiang Guo]

On Wed, Dec 10, 2014 at 5:20 PM, Bob Carpenter <ca...@alias-i.com> wrote:

So what I'd propose (if we do this) is to add a new code-generated
method to the generated model class

   std::vector<std::string> data_variable_names();

that returns a vector of data variable names.  This should only take
me a day or so, including testing.

If you are gonna add a function like that, is it a bad idea to make it static?  If it is not static, you cannot use it without constructing a model object without data. If being static is not bad, how about change all the others such as get_param_names?  

Also, how about adding arguments to get_param_names returns so you can exclude transformed parameters and/or generated quantities?

Jiqiang

[Bob Carpenter]

Excellent point about making it static. Yes, it could be static
because it's just the names which are known statically. In fact, the
param names should also be static if they aren't.

I agree adding args to get_param_names to filter out
out transformed or generated quantities makes sense. Do you
need that for efficient random inits?

I created an issue:

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

and assigned it 3.0 priority. If you need it by 2.6.0,
just bump the priority on the issue and I'll prioritize
adding it.

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

[Ben Goodrich]

If we are filtering, it would also be good I think to be able to figure out (if it is not already possible) what are the variables that are declared in the parameters block, as opposed to transformed parameters or generated quantities. I am evolving into the opinion that I should be focusing on parameters for convergence monitoring.

Ben

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

[Bob Carpenter]

> On Dec 11, 2014, at 11:08 AM, Ben Goodrich <goodri...@gmail.com> wrote:
>
> If we are filtering, it would also be good I think to be able to figure out (if it is not already possible) what are the variables that are declared in the parameters block, as opposed to transformed parameters or generated quantities.

Agreed. Jiqiang already brought that up and I put it into the issue:

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

> I am evolving into the opinion that I should be focusing on parameters for convergence monitoring.

As Michael pointed out, every function of the parameters should also converge.
I don't know if there's some way to estimate a total "n_eff". I now don't know
what to make of runs where one parameter gets n_eff=100 and another n_eff=1000.

- Bob

[Ben Goodrich]

On Thursday, December 11, 2014 12:29:48 PM UTC-5, Bob Carpenter wrote:

> I am evolving into the opinion that I should be focusing on parameters for convergence monitoring.

As Michael pointed out, every function of the parameters should also converge.
I don't know if there's some way to estimate a total "n_eff".  I now don't know
what to make of runs where one parameter gets n_eff=100 and another n_eff=1000.  

This is true (marginally), but if the chain has converged (jointly), then every function of the things in the parameters block will converge (marginally). The difficulty for multivariate convergence monitoring is that if some unknown has a much bigger scale, then it tends to dominate any distance-based calculation. If it were merely a rescaling, then we would be okay, but if something in generated quantities is like the exp() of something in parameters, then it becomes overly sensitive to the less important thing. Since we are telling people that they need to have reasonable scales on the things in the parameters block, then I think we should at least have the option to do the joint convergence monitoring on the parameters only.

Ben

[Jiqiang Guo]

On Thu, Dec 11, 2014 at 2:40 AM, Bob Carpenter <ca...@alias-i.com> wrote:

I agree adding args to get_param_names to filter out
out transformed or generated quantities makes sense.  Do you
need that for efficient random inits?

Yes and no.  I cannot make it more efficient if there is a function returning only the parameters.  But I need to know if the inits for all parameters are given, so it would help.  Currently, I have to use function constrained_param_names, which return names in forms of say alpha, beta.1, beta.2.  Then I remove stuff after dots and make a unique out of them.  Having a function that does this directly would be nice.

Jiqiang