Re: Eigen Maps

363 views
Skip to first unread message

Bob Carpenter

unread,
Mar 20, 2013, 7:29:18 PM3/20/13
to stan...@googlegroups.com
The problem is that there's no way to create a std::vector<double>
out of a double* without copying the data. At least not without
a custom allocator. The underlying issue is that std::vector
wants to manage its own memory. Here are the constructors:

http://www.cplusplus.com/reference/vector/vector/vector/

You could use the .data() from a Matrix as an iterator.
With Eigen vectors, you know you'll get the data out in the
proper order.

An Eigen::Map just gives you a view into the data
array.

std::vector<double> v = ...;
double* dbl_ptr = &v[0];
Map<Matrix<double,Dynamic,1> > map_m(dbl_ptr);
m[1] = 2.0; // changes v

But as soon as you assign it, you lose the connection:

Matrix<double,Dynamic,1> m = map_m; // Copy!
map_m[1] = 3.0; // does not change v

You can even customize the stride in the Map in case
you have a 2D array laid out C++ style and you need
to use it in Eigen. Here's an overview:

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

- Bob

On 3/20/13 7:06 PM, Yuanjun Gao wrote:
> I don't know how to go the other way using map, but I know there is a member function of Eigen matrix called data() which convert matrix into an array(you can check http://stackoverflow.com/questions/12849327/what-is-the-performance-efficient-way-to-convert-eigens-matrix-to-c-array-so-th).
>
> However, I remember (maybe wrongly) that Bob once told me that we can't use this function for some compatibility reason?
>
> Best,
> Yuanjun
> On Mar 20, 2013, at 5:55 PM, Michael Betancourt <betan...@gmail.com> wrote:
>
>> I've got a question about maps in Eigen. I see how you go from an STL vector to an Eigen vector by binding them together with the map, but how do you go the other way? Can I cast an Eigen vector into an STL vector for input into prob_grad_ad::grad_log_prob or do I have to create an auxiliary STL vector, bind it to the Eigen vector, and then pass that? Thanks.
>>
>> -Mike
>
>

Michael Betancourt

unread,
Mar 20, 2013, 8:46:52 PM3/20/13
to stan...@googlegroups.com
Gah, I was hoping to use Eigen exclusively for all of the internals and just wrap the calls to prob_grad with maps. I guess I have to rethink some code.

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

unread,
Mar 20, 2013, 11:18:18 PM3/20/13
to stan...@googlegroups.com
n 3/20/13 8:46 PM, Michael Betancourt wrote:
> Gah, I was hoping to use Eigen exclusively for all of the internals and just wrap the calls to prob_grad with maps. I guess I have to rethink some code.

I don't see the problem -- just map the input std::vector
into the appropriate Eigen vector, use that, then copy
the output into another std::vector for output.

We should've made the arguments to log_prob_grad const.
The obstacle to refactoring now is the io::reader, which should
be modified to read from a const reference.

We should just refactor the whole framework to take an Eigen
vector as input and produce sample objects with Eigen
vectors. I do not think these should be mutable.

- Bob

Michael Betancourt

unread,
Mar 21, 2013, 9:10:34 PM3/21/13
to stan...@googlegroups.com
> I don't see the problem -- just map the input std::vector
> into the appropriate Eigen vector, use that, then copy
> the output into another std::vector for output.

Sure, that's what I was planning to do for each call to generate a sample, but what do you do when you have to compute the potential and it's gradient? Won't you have to copy into an STL vector for the appropriate argument and then map the output back into an Eigen vector every time you want to call one of the model methods?

> We should just refactor the whole framework to take an Eigen
> vector as input and produce sample objects with Eigen
> vectors. I do not think these should be mutable.

Agreed.
Reply all
Reply to author
Forward
0 new messages