Re: exposing derivatives and log probs in R?

[Bob Carpenter]

[back on stan-dev -- didn't realize we were off it]


On 2/28/13 12:33 PM, Jiqiang Guo wrote:
> My code for log_prob and its gradient works. I just happened to use simplex as an example to test.
>
> As you have told me how to fix the problem with simplex using simplex_free, I have fixed that and will let you have a
> look of my fix after I check in the code.
>
> I saw a typo in the manual regarding the simplex transformation. I will double check if I am right and fix it.
>
> I will let you know when I checked in all my code and revision.

Great news. I didn't get to it yesterday because I got
distracted with a couple of other priorities.

The transforms in io/reader.hpp and io/writer.hpp
should match those in prob/transform.hpp. Either io or
prob could be changed as long as they're consistent.
The doc should of course match, but I can believe it's
not up to date and that it contains typos.
I'm not sure we would've

I believe the transform code is tested to round trip properly.
Could you check that it is and add some tests if it's not?
I could possibly put one of the student volunteers to work
on this, but given the bug you already found, I think we
should do it sooner rather than later.

Once the round-trip tests are solid for prob/transform, we can
just check consistency between the io/reader.hpp and io/writer.hpp
transforms and the prob/transform.hpp transforms.

In the near term, I want to vectorize these transforms to
use specialized auto-diff implementations. So it'll
also be good if we have tests in place before that.

- Bob

[Jiqiang Guo]

I have checked in the code for exposing grad_log and grad_log_prob and the function for transforming parameters between its support and the unconstrained space to R.  The log_prob and grad_log_prob only takes parameter values on the unconstrained space. 

 

An example of using them:

mcode <- '

  transformed data {

    vector[5] v; 

    v[1] <- 1;

    v[2] <- 2;

    v[3] <- 3;

    v[4] <- 4;

    v[5] <- 5;

  }

  parameters {

    simplex[5] y;

  }

  model {

    y ~ dirichlet(v);

  }

'

library(rstan)

K <- 5

fit <- stan(model_code = mcode)

lp <- log_prob(fit, rep(0, K - 1))

gr <- grad_log_prob(fit, rep(0, K - 1))

y <- constrain_pars(fit, rep(0, K- 1))

uy <- transform_pars(fit, y)

Fix a typo in the manual regarding simplex transform:

https://github.com/stan-dev/stan/commit/845f62fcbc02f8d2c17af0bcb81d3797921b6274

Fix io/writer for unconstrain_simplex:

https://github.com/stan-dev/stan/commit/f718dc9d004580c34d8d33d5e050e565bf47a439

There is roundtrip test for simplex transformation for stan/prob/transform.hpp.  But the tests for io/writer does not include for the correctness of transformation. 

--

Jiqiang

- 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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Bob Carpenter]

On 2/28/13 2:16 PM, Jiqiang Guo wrote:
> I have checked in the code for exposing grad_log and grad_log_prob and the function for transforming parameters between
> its support and the unconstrained space to R. The log_prob and grad_log_prob only takes parameter values on the
> unconstrained space.

Absolutely -- that's a positive for what we want to
do with it, which is run optimization code.

More below the example.

> An example of using them:
>
> mcode <- '
> transformed data {
> vector[5] v;
> v[1] <- 1;
> v[2] <- 2;
> v[3] <- 3;
> v[4] <- 4;
> v[5] <- 5;
> }
> parameters {
> simplex[5] y;
> }
> model {
> y ~ dirichlet(v);
> }
> '
>
> library(rstan)
> K <- 5
> fit <- stan(model_code = mcode)
> lp <- log_prob(fit, rep(0, K - 1))
> gr <- grad_log_prob(fit, rep(0, K - 1))
> y <- constrain_pars(fit, rep(0, K- 1))
> uy <- transform_pars(fit, y)

This looks fantastic -- it's everything we need to
get going with it in R applications like optimization.

Some suggestions

1. I think we need to add a method to the model that
lets us get the numbers of constrained and unconstrained
parameters. That should simplify error checking in
the interface. From the R side, it'd be something like

K_unc <- num_params(fit)

We can't do this until we get in and modify the model to
return it.


2. Can we give constrain_pars and transform_pars
complementary names? I'm thinking

theta <- constrain_pars(fit, theta_unc);

theta_unc <- unconstrain_pars(fit, theta);

or

theta_trans <- transform_params(fit, theta);

theta <- inv_transform_params(fit, theta_trans);


I was rather inconsistent in our API and used "free"
in the transform code instead of "unconstrain". Daniel and
I keep meaning to set aside some time to clean up the naming
throughout.


3. I find the use of R constructs in examples confusing.
The R doc does it everywhere, but for us novices, simpler
is better. So I'd suggest an example along the lines of

theta_trans <- rep(0,K-1); # unconstrained parameters

theta <- inv_transform_pars(fit, theta_trans);


4. The doc needs to point people to the transform doc so
they can figure out how many unconstrained parameters correspond
to their model. But for the most part, if they work on the
constrained space as we have users do in Stan, the transforms will
all be under the hood.


5. It'd be really great if we could read unconstrained
variables to transform out of an environment or list as inits
are handled now. I think that'd make the R interface cleaner
from an R point of view.

> Fix a typo in the manual regarding simplex transform:
> https://github.com/stan-dev/stan/commit/845f62fcbc02f8d2c17af0bcb81d3797921b6274
>
> Fix io/writer for unconstrain_simplex:
> https://github.com/stan-dev/stan/commit/f718dc9d004580c34d8d33d5e050e565bf47a439
>
> There is roundtrip test for simplex transformation for stan/prob/transform.hpp. But the tests for io/writer does not
> include for the correctness of transformation.

Thanks! I'll add some round-trip tests to writer.

- Bob

[Jiqiang Guo]

Please see comments below. 

--

Jiqiang

On Thu, Feb 28, 2013 at 3:42 PM, Bob Carpenter <ca...@alias-i.com> wrote:

Some suggestions

1.  I think we need to add a method to the model that
lets us get the numbers of constrained and unconstrained
parameters.  That should simplify error checking in
the interface.  From the R side, it'd be something like

     K_unc <- num_params(fit)

We can't do this until we get in and modify the model to
return it.

Totally agree.  I had a function called get_num_upars now, which I did not mention last time.  

2.  Can we give constrain_pars and transform_pars
complementary names?  I'm thinking

     theta <- constrain_pars(fit, theta_unc);

     theta_unc <- unconstrain_pars(fit, theta);

or

     theta_trans <- transform_params(fit, theta);

     theta <- inv_transform_params(fit, theta_trans);

Agree.  Better names are good.  I will change to constrain_pars and unconstrain_pars.  

I was rather inconsistent in our API and used "free"
in the transform code instead of "unconstrain".  Daniel and
I keep meaning to set aside some time to clean up the naming
throughout.


3.  I find the use of R constructs in examples confusing.
The R doc does it everywhere, but for us novices, simpler
is better.  So I'd suggest an example along the lines of

 theta_trans <- rep(0,K-1);  # unconstrained parameters

 theta <- inv_transform_pars(fit, theta_trans);

Sure.  

4.  The doc needs to point people to the transform doc so
they can figure out how many unconstrained parameters correspond
to their model.  But for the most part, if they work on the
constrained space as we have users do in Stan, the transforms will
all be under the hood.

Sure.  

5.  It'd be really great if we could read unconstrained
variables to transform out of an environment or list as inits
are handled now.  I think that'd make the R interface cleaner
from an R point of view.

Now transform_pars (unconstrain_pars) only take arguments in the form of a list, exactly as specifying inits. 

[Bob Carpenter]

On 2/28/13 5:49 PM, Jiqiang Guo wrote:
> Please see comments below.

...

Glad the rest of it's easy to deal with.

> 5. It'd be really great if we could read unconstrained
> variables to transform out of an environment or list as inits
> are handled now. I think that'd make the R interface cleaner
> from an R point of view.
>
> Now transform_pars (unconstrain_pars) only take arguments in the form of a list, exactly as specifying inits.

Good idea -- I think that'll be easier to document and for
the users to understand.

- Bob

[Bob Carpenter]

On 3/5/13 11:12 AM, David Blei wrote:
> bob & dev,
>
> i installed rstan with the directions here:
>
> https://code.google.com/p/stan/wiki/RStanGettingStarted
>
> but log_prob and grad_log_prob don't seem to be part of the package.
> i'm sure i did something silly wrong. can you help?

That functionality will be in version 1.2, which we hope to release
later tonight or tomorrow.

- Bob