Moving From std::vector to Eigen::Vector

[Michael Betancourt]

There are two ways to proceed:

Change the samplers and autodiff to use Eigen::Vector but leave the internal model storage as std::vector

or

Convert everything to Eigen::Vector

Given how the model is abstracted through the autodiff functors both should be equally feasible. Does anyone have any preferences?

[Bob Carpenter]

On 12/6/13, 7:09 PM, Michael Betancourt wrote:
> There are two ways to proceed:
>
> Change the samplers and autodiff to use Eigen::Vector but leave the internal model storage as std::vector

Do you mean the signature of the log probability method
in a model class?

Changing it will require changing the transform methods from constrained
to unconstrained and back.

This will in turn affect RStan and PyStan, though it
should be an easy change.

> Convert everything to Eigen::Vector
>
> Given how the model is abstracted through the autodiff functors both should be equally feasible. Does anyone have any preferences?

We need Eigen::Matrix in order to return results like Jacobians
efficiently. So the autodiff functors pretty much have to be
done in terms of Eigen outputs.

I think the functional passed to the autodiff functors should
operate on the same type of parameter sequence as is used for
the model's log probability function.

- Bob

P.S. Extra credit for removing the detritus from assuming there might
eventually be integer parameters --- eve if we do add them some day,
they may not be like what are stubbed out.

[Michael Betancourt]

Yes, the signature of the log prob method would change in both cases. I'm not even sure
where the internal model parameters are used as log prob (and all the templated autodiff)
just uses the arguments and not the internal values.

Perhaps we should punt until Monday? Unless you (Bob) want to chat tomorrow? I'll be
in the Columbia area.

> --
> 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/groups/opt_out.

[Bob Carpenter]

Just to reiterate, my original goal for using std::vector
was for portability and modularity. I didn't want to introduce
dependencies on any Eigen classes if we could avoid it in
our core constructs. Now that we're going to RHMC it seems
inevitable as we need to actually manipulate the parameter vector
like a vector.

On 12/6/13, 7:25 PM, Michael Betancourt wrote:
> Yes, the signature of the log prob method would change in both cases. I'm not even sure
> where the internal model parameters are used as log prob (and all the templated autodiff)
> just uses the arguments and not the internal values.

I'm not sure what you mean by "internal" here. A model
instance should only be storing its data, not anything
related to parameters. This makes the model class itself
stateless, which is a highly desirable property given how
it's used.

> Perhaps we should punt until Monday? Unless you (Bob) want to chat tomorrow? I'll be
> in the Columbia area.

OK. We should get Daniel involved in this discussion, too.

We need to run things by Jiqiang to see if there's some
fundamental impediment to Rcpp using Eigen vectors. I'm
afraid it may require pulling in a dependency on RcppEigen,
which I'd rather not do unless we absolutely have to.

- Bob

[Daniel Lee]

Let's talk Monday. I'm going to try to do other stuff this weekend. And I need some time to think.

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

[Ben Goodrich]

Um, what is the problem that these two proposals are a solution to? Maybe using an Eigen::Map is a third possibility?

I'm pretty sure I would be in favor of converting everything to Eigen types regardless. It is one thing to say that we should limit the number of libraries that we depend on (although I am not totally convinced of that). But given that Stan fundamentally depends on a library such as Eigen (and it would be non-trivial to even swap in another matrix library like Armadillo), then we should use Eigen as much as possible because it is awesome.

Ben

[Bob Carpenter]

On 12/6/13, 9:16 PM, Ben Goodrich wrote:
> On Friday, December 6, 2013 7:09:04 PM UTC-5, Michael Betancourt wrote:
>
> There are two ways to proceed:
>
> Change the samplers and autodiff to use Eigen::Vector but leave the internal model storage as std::vector
>
> or
>
> Convert everything to Eigen::Vector
>
> Given how the model is abstracted through the autodiff functors both should be equally feasible. Does anyone have
> any preferences?
>
>
> Um, what is the problem that these two proposals are a solution to? Maybe using an Eigen::Map is a third possibility?

The underlying use is now as an Eigen vector and we wind up
either wrapping or copying the std::vector coming in.

I don't think we want Eigen::Map as the input type --- it's just
one of many expression template-like types that Eigen uses.
Ben's pointed us before to Eigen's advice on how to do these
arguments more generally so as to accept references to expression
templates:

http://eigen.tuxfamily.org/dox/TopicFunctionTakingEigenTypes.html

We could start following this advice, but it may be more trouble
than it's worth in this case. And it will, of course, introduce
more deeply nested template parameter fiddling at compile time.

> I'm pretty sure I would be in favor of converting everything to Eigen types regardless. It is one thing to say that we
> should limit the number of libraries that we depend on (although I am not totally convinced of that). But given that
> Stan fundamentally depends on a library such as Eigen (and it would be non-trivial to even swap in another matrix

> library like Armadillo), then we should use Eigen as much as possible because it is awesome.'

Stan's samplers did not in the past fundamentally depend on Eigen.
Michael's refactor of the samplers in 2.0 introduced the dependency.
Adding the dependency makes sense when you start manipulating the
parameter vector as a mathematical vector, as Michael's doing.

Stan's model base class still (v2.0.1) does not depend on Eigen,
so this proposed change would be introducing a dependency.

Of course, all of our generated models depend on everything. This
is not good, but it'd be a big programming project to trim everything
and would require the code generator to keep track of dependencies on
every function it generates, which means a dependency of the code generator
on every specific function we introduce to ensure its dependencies are included.
Not having this dependency makes it easier to introduce new functions.

- Bob