Expose `log_prob` and `grad_log_prob` methods

[andrjohns]

I'm opening this as a reference issue/reminder to myself to add a log_prob method to CmdStanFit once the PR has been merged.

As for the implementation/design, I'm thinking of simply mirroring the method arguments:

mod <- cmdstan_model(...)
samp <- mod$sample(...)

log_prob_output <- samp$log_prob(constrained_pars=..., unconstrained_pars=..., jacobian_adjust=TRUE)

Where the method would simply write the constrained_pars/unconstrained_pars to a .json file and call the exe_file.

The return (log_prob_output) would the data.frame/tibble from reading in the generated csv (i.e., no formatting changes).

How does that sound? Is there any other functionality that would be needed for feature parity with rstan in this case?

[rok-cesnovar]

I think that sounds great! Not sure if there is anything else needed. I have seen users doing the constrained -> unconstrained conversion, but not sure if that is needed. That was typically needed in connection with log_prob and your implementation supports both so I think that is not needed.

[andrjohns]

Oh that's right! I just found the rstan log_prob doc as well, and it looks like that also exposed the methods get_num_upars, constrain_pars, and unconstrain_pars.

Nothing for cmdstanr right now, but it's easy enough to add those as methods to cmdstan now that I have a handle on the system, so something for the future

[bob-carpenter]

There's no way to do this efficiently through CmdStan because data has to be loaded each time. So @roualdes, @WardBrian and I put together the BridgeStan package:

https://github.com/roualdes/bridgestan

This is a light C++ foreign function interface that keeps the model and data in memory and is thus performant.

My suggestion is to close this issue and just suggest people use BridgeStan if they want log densities, gradients, Hessians, and transforms. It only supports JSON data format, though---not the R dump format.

[WardBrian]

We discussed this a bit last weekly Stan meeting, there are a few things in packages like brms that need log probabilities on the order of a few dozen calls I think it was, which is probably fine to use something like this for.

The problem of course is if you expose it, someone will inevitably use that to also write their own sampler or something where the efficiently absolutely would bite them

[bob-carpenter]

need log probabilities on the order of a few dozen calls I think it was, which is probably fine to use something like this for.

If an application doesn't care about efficiency, I think it may be possible to get all this information now out of cmdstan using standalone generated quantities and diagnostics. You just have to extract unconstrained draws (in general, unconstraining would be necessary if you only have constrained draws) from the sampler diagnostics the first time around, then feed them back in and extract lp__. You can also extract the gradients through diagnostics.

[andrjohns]

Closed by #701