Stan meeting: agenda item -- discuss RStan 3

[Daniel Lee]

This is just a reminder.

We're going to be taking some (or most?) of the meeting talking about the  RStan 3 proposal. If you're around and want to help with the discussion, please review the proposal which can be found here:
https://github.com/stan-dev/rstan/wiki/Interfaces-3.0-Spec

Daniel

[Bob Carpenter]

Ideally, I'd like Ben, Jiqiang, Andrew, Michael, and Daniel around for that
discussion. It ties into what we'll be implementing for the C++
part of Stan 3, which is why I'd like to discuss it up front.

Other issues:

* C++11 plans: I also thought we were a long ways away, so I'd like to discuss

* error handling: Daniel and Peter are trying to rationalize the error handling
on the C++ side of Stan for functions --- there are a couple of options going
forward with efficiency vs. early reporting of errors tradeoffs.

- 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.

[Allen Riddell]

I just have three comments. I'm a little pressed for time today and I'm not sure
I'll be able to make it for long.

1. I think it would be helpful to make the separation between model and fit
explicit. For example, while it's convenient to pass the *fit* object to
stan() when one wants to rerun a model, it really is the model that one is
reusing. Perhaps one could pass fit@model or mark the reuse of the fit
object as a kind of convenience macro.
2. I'd like to see serialization of the fit object (and all results) separated
from any kind of serialization of the model. Fit objects, serialized, should
be cross-platform, whereas model instances need not be. (One should, of
course, store a copy of the model_code, random seed, etc in the fit object.)
3. I feel like stan_optimize or stan_optimizing is clearer than stan_mle. I'd
even prefer stan_maximize_likelihood() (well, maybe)

Best wishes,

-a

[Andrew Gelman]

1. I agree, and I think this separation between model and fit is implicit in the way I defined the codes for the rstan3 plan.

[Bob Carpenter]

I also think (2) is critical. I'd like to have a way to
separate out our coda-like computations from that of our
model fitting.

As to (3), once we get to naming, the hard work's done. I think
the term "optimize" is more popular in engineering and in some branches
of machine learning, whereas "mle" is more popular in statistics. MLE
is a pretty common abbreviation, so it doesn't bother me. If we
choose "maximize_likelihood" --- I think we'll get a rash of typos
because it's not a common collocation, compared to "maximum_likelihood".
The problem with the latter is that it's not a verb. The problem with
"optimize" is that it's already a built-in function in R, so just using
that causes conflicts, hence the rather suboptimal choice
of "optimizing" the first time around.

- Bob

[Michael Betancourt]

I vote for the explicit maximize_likelihood which makes it clear what
the optimization criterion is (recall that much of ML is dedicated to
criteria outside of maximizing likelihood). Actually, it should be
maximize_posterior_density. maximize_likelihood should just trigger
a “No-Frequentists Club” warning.

[Andrew Gelman]

stan_optimize() is ok. Nobody will think it’s the same as optimize().

[Bob Carpenter]

Then we can shorten maximize_posterior_density() to just map() and
be done with it.

The real question, though, is whether we want to have a single callfor
all of our sampling:

mcmc_sample(algorithm="hmc", ... hmc config ...);
mcmc_sample(algorithm="stretch", ... stretch config ...);

or whether we'd want to do something that calls the top-level functionality
out at the top, like

hmc_sample(...hmc config...);
stretch_sample(...stretch config...);
metropolis_sample(...metrop config...);

The second issue is whether the config is one monolothic object in R
that produces a C++ config object that can be passed to Stan, as opposed
to making the config more R-like and flat. The advantage of the latter
function calls, like hmc_sample, is that it's easier to document and test
the requirements for the config itself because there aren't so many interdepdencies
such as "parameter alpha only applies to sampler X".

- Bob

[Andrew Gelman]

We’re not calling it map(), that’s for sure.

[Ben Goodrich]

On Thursday, August 14, 2014 2:12:31 PM UTC-4, Bob Carpenter wrote:

The second issue is whether the config is one monolothic object in R
that produces a C++ config object that can be passed to Stan, as opposed
to making the config more R-like and flat.  

That should actually be the first issue and is essentially the same question as whether the internals should be function-oriented or object-oriented? If you have an R object with methods, then you don't need to worry about name clashes or name proliferation or a bunch of other stuff

object$sample(n = 1000)

because the object knows its own configuration, including whether it is HMC or Metropolis or whatever, and knows the options for each.

If you are function-oriented, then the typical R syntax would be like optim() where you call it on a model and pass a list of configuration stuff to it

stan_sample(model, n = 1000, config = list(algorithm = "HMC"))

The former is much closer to the C++ and to PyStan. Also, you can validate objects when they are instantiated and utilize Python-style documentation conventions for the methods. The latter is what old R code has been stuck doing since the 1990s.

Ben