Re: [eigen] Bugs in Mat::Random, reductions

[Benoît Jacob <jacob@xxxxxxxxxxxxxxx>]

Hi,

> Matrix3d P = Matrix3d::Random(); // for testing

First of all, your compiler errors are likely caused by forgetting to include
#include<Eigen/Array>
which is where the random matrices stuff is defined.

I know that the compilation errors are very ugly, the root of the problem is 
that the Random() method has to be declared in Core because it is a member of 
MatrixBase, so you don't get the simple "undefined Random() method" error 
message that you expect. Any suggestion towards getting friendlier error 
messages are welcome.

Also, we normally mention it in the docs when some method or class requires 
#including some particular header. If you found a place in the docs where we 
forgot to say #include<Eigen/Array>, please point us to it.

> typedef Matrix<double, 3, Dynamic> Matrix3xN;
> Matrix3xN P = Matrix3xN::Constant(3, 10, 1);
> Vector3d C = P.rowwise().sum() / P.cols();

same thing, all the rowwise() / colwise() / cwise() stuff requires 
#include<Eigen/Array>.

> Am I doing something wrong, and if not, surely these sorts of errors should
> be caught by unit tests? I notice there is a test/ directory, but I am
> unfamiliar with CMake and do not see instructions for running the tests
> anywhere.

mkdir build
cd build
cmake /path/to/eigen2
make test (takes a long time and a ton of memory)
now the tests are built, you can run them manually or all at once by 
doing "ctest" in the test/ dir.

> It's a little disconcerting when code more or less straight out
> of the tutorial doesn't work...

We'll make sure to make it clearer in the tutorial if some #include is needed, 
then. Indeed I can see that it doesn't mention #include<Eigen/Array> once.

> Btw, am I right in surmising that Dynamic is defined as 10000? This seems a
> little odd to me. Why not use 0, -1 or even INT_MAX as a placeholder value?

Initially it was -1. I changed to a large positive value because it allowed to 
shorten many logical expressions, e.g. the test RowsAtCompileTime <= 4 
implicitly excludes dynamic-size matrices, which is what we wanted at many 
places.

INT_MAX has the big problem that INT_MAX*INT_MAX is beyond the range of 
integers. We do products all the time.

> I'm also curious about Eigen2's policy on allocating memory. I don't see a
> completely explicit statement in the documentation, but I take it that
> fixed-size matrices are always stack-allocated?

Yes, always.

> I could imagine it being 
> useful to specify the dimensions of a large, dynamically-allocated matrix
> at compile time; e.g. if you know the inner dimension is a multiple of the
> level of loop unrolling, you can avoid some unnecessary code.

Eigen can already handle that very well. You can do Matrix<double, 8, 
Dynamic>. Eigen will then allocate dynamically, which is what you want since 
you said the matrix is large, and at the same time Eigen will make use of the 
information that one dimension is fixed to unroll inner loop. In this respect 
it can greatly help if you manually specify the storage orders (using the 
optional template parameter Flags of Matrix) so that the fixed size is the 
inner size. Eigen will not by itself take the decision to switch to row-major 
order, as that could easily break the user's assumptions.

Cheers,
Benoit


---