Running:
fit <- cmdstanr_example("logistic")
rstanfit <- rstan::read_stan_csv(fit$output_files())
rstanfit@model_pars
rstanfit@par_dims
prints
> rstanfit@model_pars
[1] "alpha" "beta" "lp__"
> rstanfit@par_dims
$alpha
integer(0)
$beta
[1] 3
$lp__
integer(0)
Should we implement the equivalent of this? If yes, any name suggestions?
Or are there any plans to add this to posterior (like posterior::variables()). Retrieving dimensions and names of parameters/variables isn't Stan specific. I can also add this to posterior if it would be better to live there.
I agree this is useful information. I think some version of this could go in posterior but it's a little bit Stan-specific in that the dimension of alpha is integer(0) instead of 1 (to indicate a scalar instead of a 1-element vector or array). But that's a choice that RStan made to in some way match the Stan program. For posterior my first instinct is that alpha should have dimension 1 (but we should think about that and check with @paul-buerkner).
And maybe we can combine model_pars and par_dims into a single function variable_structure() (or something like that) which takes a draws object as input and just returns the named list?
# assume the draws object has variables
# alpha, beta[1], beta[2], beta[3], Sigma[1,1], Sigma[1,2], Sigma[2,1], Sigma[2,1], lp__
> variable_structure(draws)
$alpha
[1] 1
$beta
[1] 3
$Sigma
[1] 2 2
$lp__
[1] 1
Paul will also probably have suggestions if you open an issue over at posterior.
Although maybe we should also add the equivalent of model_pars to fit$metadata(). Right now fit$metadata()$model_pars gives all element names, so we could add fit$metadata()$model_pars_named or something that only lists the unique non-element names.
Although maybe we should also add the equivalent of
model_parstofit$metadata(). Right nowfit$metadata()$model_parsgives all element names, so we could addfit$metadata()$model_pars_namedor something that only lists the unique non-element names.
Agree. That also makes read_cmdstan_csv a more complete function standalone.
I think our current way forward in posterior is to implement those dimensional draws arrays (https://github.com/stan-dev/posterior/issues/13) via rvars (https://github.com/stan-dev/posterior/issues/8). On these decisions it will likely depend on how we represent the dims in posterior best.
@rok-cesnovar This is currently listed under the beta release milestone, but this could probably wait for 1.0 right? That way we could go forward with the beta release sooner.
Agreed, can move to 1.0. I was expecting I would have time to work on this in July, that is why I put the milestone on beta. But then other stuff got in the way.