Hi all,

First of all, I would like to extend my congratulations for what appears to be a fine library with a bright future. I've been looking for something like this for about four years. Let's hope I must look no further
Secondly, since this is my first post in the list, I apologize if these subjects have been previously posted. I looked around in the archives and did not find anything similar.

I have a question that is very specific to our use case, and wanted to have some feedback on what the best practice should be:
We deal with a real-time robotics application that must perform heavy matrix operations (products, SVDs, etc.). The usual matrix sizes we're talking about have about 30 columns (a fixed value), and up to 30 rows (a value that may change at runtime). As a requirement, we are to avoid dynamic allocations during the real-time parts of our code, so the question would be:

a) Is there any way of preallocating memory for a matrix (something like std::vector's reserve method)?. This would guarantee no extra allocations as long as the matrix does not exceed its preallocated size, and preserve notational convenience when calling matrix operations (see point c) for more details)

b) If the answer is negative, is there any interest/previsions in supporting such a feature?

c) If the answer is still negative, what would be the recommended way of handling this scenario?. The straightforward solution that comes to my mind would be to create a matrix with the maximum expected size, keep a count of the used rows, and extract the used submatrix before every operation, but ease of use and notational convenience take a big hit.

Any ideas are welcome. Thanks in advance!


--
Adolfo Rodríguez Tsouroukdissian

Robotics engineer
PAL ROBOTICS S.L
http://www.pal-robotics.com
Tel. +34.93.414.53.47
Fax.+34.93.209.11.09

Re-reading the recent post titled How to resize properly big matrices I'm thinking that using EIGEN_MATRIX_PLUGIN might be the way to do it. Do you agree?

Thanks once again,

Adolfo

Adolfo Rodriguez wrote:Hi all,

First of all, I would like to extend my congratulations for what appears to be a fine library with a bright future. I've been looking for something like this for about four years. Let's hope I must look no further
Secondly, since this is my first post in the list, I apologize if these subjects have been previously posted. I looked around in the archives and did not find anything similar.

I have a question that is very specific to our use case, and wanted to have some feedback on what the best practice should be:
We deal with a real-time robotics application that must perform heavy matrix operations (products, SVDs, etc.). The usual matrix sizes we're talking about have about 30 columns (a fixed value), and up to 30 rows (a value that may change at runtime). As a requirement, we are to avoid dynamic allocations during the real-time parts of our code, so the question would be:

a) Is there any way of preallocating memory for a matrix (something like std::vector's reserve method)?. This would guarantee no extra allocations as long as the matrix does not exceed its preallocated size, and preserve notational convenience when calling matrix operations (see point c) for more details)

b) If the answer is negative, is there any interest/previsions in supporting such a feature?

c) If the answer is still negative, what would be the recommended way of handling this scenario?. The straightforward solution that comes to my mind would be to create a matrix with the maximum expected size, keep a count of the used rows, and extract the used submatrix before every operation, but ease of use and notational convenience take a big hit.

Any ideas are welcome. Thanks in advance!


--
Adolfo Rodríguez Tsouroukdissian

Robotics engineer
PAL ROBOTICS S.L
http://www.pal-robotics.com
Tel. +34.93.414.53.47
Fax.+34.93.209.11.09

I think that the easiest way is to use a Map object.

Code: Select all

float data[30*30];
Map m1(data,30,30);
.....
m1 = m1 * m1;
.....
int rows; // between 1 and 30
Map m2(data,rows,30);
.....
m2 = 10 * m2;
.....


Notice that when the Map object is a temporary and you don't need to name it, it can be more convenient to use the MatrixXf::Map() static methods.

If you really know at compile-time that the number of columns is 30, you can let Eigen know about that:

Code: Select all

Map > .......


Also notice that it can greatly help performance (vectorization) to use an aligned array and let Eigen know about that. Like this:

Code: Select all

typedef Map, ForceAligned > Map30Rows;
float *data = ei_aligned_new(30*30);
int rows; // between 1 and 30
Map30Rows m(data,rows,30);
.....
m = m * m;
.....


Gael: is this ForceAligned safe here? What I really want is to set the AlignedAccessBit on this xpr. The convenience methods MapAligned used to do just that, but now they're wrapping around ForceAligned. Is this really intended or a mistake?

Gael: when writing this answer, playing with RowMajor and ColMajor storage, I realized that 0 is DontAlign, so we have to specify AutoAlign explicitly when we specify storage order. My fault. That's stupid isn't it? 99% of people want AutoAlign.

Is it worth (or even possible) changing? This would break the ABI. KDE would be unaffected as no stable library exposes Eigen. But for example, for Avogadro, we would have to do such a change very quickly as they'll soon release their 1.0 library.

hm, if the max sizes are known at compile time, then the easiest way is to declare your matrix like this:

Code: Select all

Matrix


this will allocate on the stack 30x30 floats and let you dynamically change the number of rows without any reallocation.

bjacob wrote:Gael: when writing this answer, playing with RowMajor and ColMajor storage, I realized that 0 is DontAlign, so we have to specify AutoAlign explicitly when we specify storage order. My fault. That's stupid isn't it? 99% of people want AutoAlign.

Is it worth (or even possible) changing? This would break the ABI. KDE would be unaffected as no stable library exposes Eigen. But for example, for Avogadro, we would have to do such a change very quickly as they'll soon release their 1.0 library.

damn it! actually I thought we already did that change, but it seems we noticed that issue without fixing it. So yes I think that would nice to do that change if possible.

ggael wrote:hm, if the max sizes are known at compile time, then the easiest way is to declare your matrix like this:

Code: Select all

Matrix


this will allocate on the stack 30x30 floats and let you dynamically change the number of rows without any reallocation.

You're perfectly right! Goes to show i haven't been coding for a too long time....

Thanks for such a prompt answer!

Adolfo