|Re: [eigen] Bugs in Mat::Random, reductions|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
> Matrix3d P = Matrix3d::Random(); // for testing
First of all, your compiler errors are likely caused by forgetting to include
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
> 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
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
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?
> 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.