Re: [stan-users] blending Stan with interfaces
46 views
Skip to first unread message
Bob Carpenter
Apr 16, 2015, 1:01:01 AM4/16/15
to stan...@googlegroups.com
[moved to stan-dev]
I don't want to burden the users with our design discussions.
The ones who care can subscribe to stan-dev.
> On Apr 16, 2015, at 5:55 AM, Sebastian Weber <sdw....@gmail.com> wrote:
>
> Hi!
>
> Following on the discussion on "testify"
I'd really like to change that nomenclature.
> which resulted in a planned delayed generated quantitiy block as far as I understood. Here is why I think you could reconsider this more in a direction of "testify":
The reason we don't want to push everything into the interfaces
is that we then have to implement everything we want five different
times or have the interfaces go without. I'm also concerned about
testing and stability, which is much easier to just do once with
lightweight interfaces.
> Quite a number of scientific software is written as a mix of languages, i.e. a very successfull model is to code most of data handling/fiddling/processing/whatever thing in something "light" like R or Python. Then the hard stuff should always be done in something like C++.
Absolutely. Even what people think of as pure R really
calls C++ or Fortran on the back end.
> At least this is how I have done much of my research. Following this approach means that Stan should opt to make possibly all those tremendous functionality in Stan not only available in those few blocks, but rather it should be the goal to bridge Stan space with the interface space.
I'm a bit confused by what you mean by bridging here. I want to
build those bridges rather than having Stan be minimal with a bunch
of duplicated effort across the interfaces.
>
> This is a bit contrary to the current approach "keep the interfaces lean and let the C++ Stan handle" - but only in some sense. What would be awesome to have at some point is to tie all those Stan function into the interfaces you have, i.e. I would find it extremely helpful to just straight be abel to call lkj densities from R.
The C++ for them is there for the taking.
> Of course, not all interfaces are as rich as others, but then languages like R are so powerful that not making use of this would be a pitty. Just an example, with the current testify stuff I can define a Stan functions, which, say, takes the two parameters a and b as argument. Then having the function in R space allows me to do stuff like
>
> testify("model.stan") which has "real calc_stuff(real a, real b) {}"
>
> # also assume we have a fit
>
> post <- extract(fit, c("a", "b"))
>
> do.call(Vectorize(calc_stuff), post)
>
> Now, the last call is likely awkward looking for anyone not programming R for a while, but it is a nice example of how easy some things are in R, i.e. I get almost for free a mechanism to do posterior simulations in a very straightforward way.
Despite Andrew saying he agrees, I think this is where he disagrees.
My understanding is that he explicitly doesn't want to fiddle with
indices, either implicitly or with this kind of functional programming
in R.
I was the one saying it wasn't such a pain just to post-process R!
Andrew wanted something like Jounni's RV package --- that is, the
ability to deal with the draws in a sample without having to worry
about indexing. So he wants to be able to take
fit <- stan(...);
and NOT have to do
theta <- extract(fit)$theta
and then have to do
theta_sq <- c();
for (n in 1:length(theta))
theta_sq[n] <- theta[n]^2.
But rather be able to do
fit <- stan(...)
... some magic happens ...
theta_sq <- theta^2
> And one more argument for blending Stan into the interfaces - each of us is best in commanding with the interfaces the objects we care about. Hence, fitting Stan tightly into the user environment is a huge step.
Agreed.
I think we want to do the heavy lifting in Stan, though.
For instance, split R-hat and n_eff calcs are being duplicated
in the interfaces (I think), but they should be defined and
thoroughly tested in the C++ core of Stan and then wrapped by
the interfaces.
> I am speaking here as a user, of course. Software wise, I think there are approaches as Swig which goes beyond R (for R we have the wonderful Rcpp) which may we worth to consider.
We couldn't figure out SWIG and it looks like much of its
functionality is still experimental. Rcpp can't deal with
templating, so it's rather limiting from the C++ point of view!
And we have to use inline for dynamic linking because it's purely
static. So it should perhaps better be called Rc!
Rcpp has also been the main bottleneck in installing RStan. Lots
of people have just given up because of the pain, or simply haven't
updated Stan in a year because it was so painful the first time.
- Bob
I don't want to burden the users with our design discussions.
The ones who care can subscribe to stan-dev.
> On Apr 16, 2015, at 5:55 AM, Sebastian Weber <sdw....@gmail.com> wrote:
>
> Hi!
>
> Following on the discussion on "testify"
I'd really like to change that nomenclature.
> which resulted in a planned delayed generated quantitiy block as far as I understood. Here is why I think you could reconsider this more in a direction of "testify":
The reason we don't want to push everything into the interfaces
is that we then have to implement everything we want five different
times or have the interfaces go without. I'm also concerned about
testing and stability, which is much easier to just do once with
lightweight interfaces.
> Quite a number of scientific software is written as a mix of languages, i.e. a very successfull model is to code most of data handling/fiddling/processing/whatever thing in something "light" like R or Python. Then the hard stuff should always be done in something like C++.
Absolutely. Even what people think of as pure R really
calls C++ or Fortran on the back end.
> At least this is how I have done much of my research. Following this approach means that Stan should opt to make possibly all those tremendous functionality in Stan not only available in those few blocks, but rather it should be the goal to bridge Stan space with the interface space.
I'm a bit confused by what you mean by bridging here. I want to
build those bridges rather than having Stan be minimal with a bunch
of duplicated effort across the interfaces.
>
> This is a bit contrary to the current approach "keep the interfaces lean and let the C++ Stan handle" - but only in some sense. What would be awesome to have at some point is to tie all those Stan function into the interfaces you have, i.e. I would find it extremely helpful to just straight be abel to call lkj densities from R.
The C++ for them is there for the taking.
> Of course, not all interfaces are as rich as others, but then languages like R are so powerful that not making use of this would be a pitty. Just an example, with the current testify stuff I can define a Stan functions, which, say, takes the two parameters a and b as argument. Then having the function in R space allows me to do stuff like
>
> testify("model.stan") which has "real calc_stuff(real a, real b) {}"
>
> # also assume we have a fit
>
> post <- extract(fit, c("a", "b"))
>
> do.call(Vectorize(calc_stuff), post)
>
> Now, the last call is likely awkward looking for anyone not programming R for a while, but it is a nice example of how easy some things are in R, i.e. I get almost for free a mechanism to do posterior simulations in a very straightforward way.
Despite Andrew saying he agrees, I think this is where he disagrees.
My understanding is that he explicitly doesn't want to fiddle with
indices, either implicitly or with this kind of functional programming
in R.
I was the one saying it wasn't such a pain just to post-process R!
Andrew wanted something like Jounni's RV package --- that is, the
ability to deal with the draws in a sample without having to worry
about indexing. So he wants to be able to take
fit <- stan(...);
and NOT have to do
theta <- extract(fit)$theta
and then have to do
theta_sq <- c();
for (n in 1:length(theta))
theta_sq[n] <- theta[n]^2.
But rather be able to do
fit <- stan(...)
... some magic happens ...
theta_sq <- theta^2
> And one more argument for blending Stan into the interfaces - each of us is best in commanding with the interfaces the objects we care about. Hence, fitting Stan tightly into the user environment is a huge step.
Agreed.
I think we want to do the heavy lifting in Stan, though.
For instance, split R-hat and n_eff calcs are being duplicated
in the interfaces (I think), but they should be defined and
thoroughly tested in the C++ core of Stan and then wrapped by
the interfaces.
> I am speaking here as a user, of course. Software wise, I think there are approaches as Swig which goes beyond R (for R we have the wonderful Rcpp) which may we worth to consider.
We couldn't figure out SWIG and it looks like much of its
functionality is still experimental. Rcpp can't deal with
templating, so it's rather limiting from the C++ point of view!
And we have to use inline for dynamic linking because it's purely
static. So it should perhaps better be called Rc!
Rcpp has also been the main bottleneck in installing RStan. Lots
of people have just given up because of the pain, or simply haven't
updated Stan in a year because it was so painful the first time.
- Bob
Sebastian Weber
Apr 16, 2015, 7:10:14 AM4/16/15
to stan...@googlegroups.com
Hi!
Yes, I was not sure where to place this mail - users or dev. Since I wrote as a user, I choose user.
I see your point about the difficulty of blending Stan into language with maybe SWIG or whatever else. But how about interface specific plugins into stanc? That way stanc could create possibly multiple versions of the stan model which serve different purposes. In short, instead of having the current testify function have to mess around with the C++ code, why not extend stanc interface specific to R such that it can output a special C++ model which is easy to Rcpp it into R?
The same can likely be done for Python, I suppose. This would be an intermediate solution, I think, and it should be maintainable. The big win here is that you are then free to make use of more feature rich interfaces like R and Python in comparison to, for example, the command line.
Best,
Sebastian
On Thursday, April 16, 2015 at 7:01:01 AM UTC+2, Bob Carpenter wrote:
> [moved to stan-dev]
>
> I don't want to burden the users with our design discussions.
> The ones who care can subscribe to stan-dev.
>
Yes, I was not sure where to place this mail - users or dev. Since I wrote as a user, I choose user.
I see your point about the difficulty of blending Stan into language with maybe SWIG or whatever else. But how about interface specific plugins into stanc? That way stanc could create possibly multiple versions of the stan model which serve different purposes. In short, instead of having the current testify function have to mess around with the C++ code, why not extend stanc interface specific to R such that it can output a special C++ model which is easy to Rcpp it into R?
The same can likely be done for Python, I suppose. This would be an intermediate solution, I think, and it should be maintainable. The big win here is that you are then free to make use of more feature rich interfaces like R and Python in comparison to, for example, the command line.
Best,
Sebastian
On Thursday, April 16, 2015 at 7:01:01 AM UTC+2, Bob Carpenter wrote:
> [moved to stan-dev]
>
> I don't want to burden the users with our design discussions.
> The ones who care can subscribe to stan-dev.
>
Bob Carpenter
Apr 16, 2015, 7:22:01 AM4/16/15
to stan...@googlegroups.com
Ben --- could you create the feature request for what stanc
would need to generate?
If it's just an instantiation where all template
params are replaced with double, that'd be trivial to do and
I can knock it out easily before the next release.
That way, it won't need anything specific to R.
I'd rather avoid doing anything too R-specific. And we don't
want to have anything in Stan C++ depend on R.
- 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.
would need to generate?
If it's just an instantiation where all template
params are replaced with double, that'd be trivial to do and
I can knock it out easily before the next release.
That way, it won't need anything specific to R.
I'd rather avoid doing anything too R-specific. And we don't
want to have anything in Stan C++ depend on R.
- 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
Apr 16, 2015, 7:47:56 AM4/16/15
to stan...@googlegroups.com
> To unsubscribe from this group and stop receiving emails from it, send an email to stan-dev+unsubscribe@googlegroups.com.
Sebastian Weber
Apr 16, 2015, 7:57:13 AM4/16/15
to stan...@googlegroups.com
Awesome!
If there is a way which avoids the use of "sourceCpp" that would even be better. The trouble with sourceCpp is that the compiled objects cannot be serialized which forces me to recompile each time I restart R. No idea what else is easily doable, but I just would like to serialize and reload instead of recompiling.
... but if a sourceCpp is the quick solution, I live with it happily and maybe this can be changed later...
Sebastian
> > To unsubscribe from this group and stop receiving emails from it, send an email to stan-dev+u...@googlegroups.com.
If there is a way which avoids the use of "sourceCpp" that would even be better. The trouble with sourceCpp is that the compiled objects cannot be serialized which forces me to recompile each time I restart R. No idea what else is easily doable, but I just would like to serialize and reload instead of recompiling.
... but if a sourceCpp is the quick solution, I live with it happily and maybe this can be changed later...
Sebastian
Krzysztof Sakrejda
Apr 16, 2015, 7:12:59 PM4/16/15
to stan...@googlegroups.com
Compilation has to happen somewhere but with the kind of generated code Ben's issue describes it would be straightforward to autogenerate/install/reload an r package from a set of Stan functions with rcpp.skeleton and maybe Eddelbuettel's drat package.
Sebastian Weber
Apr 17, 2015, 2:49:37 AM4/17/15
to stan...@googlegroups.com
On Friday, April 17, 2015 at 1:12:59 AM UTC+2, Krzysztof Sakrejda wrote:
> Compilation has to happen somewhere but with the kind of generated code Ben's issue describes it would be straightforward to autogenerate/install/reload an r package from a set of Stan functions with rcpp.skeleton and maybe Eddelbuettel's drat package.
Hi!
> Compilation has to happen somewhere but with the kind of generated code Ben's issue describes it would be straightforward to autogenerate/install/reload an r package from a set of Stan functions with rcpp.skeleton and maybe Eddelbuettel's drat package.
Yep, I read about this, i.e. package building is supposed to be easy. For reference, could you point to some material on this? I have never done this. Is there an easy follow recipe somewhere?
Thanks!
Best,
Sebastian
... finally my Stan models become R packages - cool!
Krzysztof Sakrejda
Apr 17, 2015, 12:01:17 PM4/17/15
to stan...@googlegroups.com
Recipe for building r packages or for drat?
Sebastian Weber
Apr 17, 2015, 12:25:13 PM4/17/15
to stan...@googlegroups.com
On Friday, April 17, 2015 at 6:01:17 PM UTC+2, Krzysztof Sakrejda wrote:
> Recipe for building r packages or for drat?
More building with the sourceCpp approach a package, but I guess I just need to follow pointers given in Rcpp.
> Recipe for building r packages or for drat?
Thanks for the drat package. Looks useful.
Krzysztof Sakrejda
Apr 17, 2015, 1:08:43 PM4/17/15
to stan...@googlegroups.com
Krzysztof
Reply all
Reply to author
Forward
0 new messages