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

[Benoît Jacob <jacob@xxxxxxxxxxxxxxx>]

On Thursday 23 October 2008 04:01:06 Patrick Mihelich wrote:
> Oh... yes, that would be the problem, thanks. Now I see that this is noted
> at various places in the Doxygen docs. But, as you noticed, <Eigen/Array>
> is not mentioned at all in the tutorial - that could have saved me some
> confusion. Probably that #include should appear in the initialization and
> reduction sections, and a more general note (or even table) explaining that
> certain member functions of MatrixBase require modules other than Core
> would be nice.

Sure, I agree.

> Btw, I think there is a typo in the "Basis vectors" code box: UnixX()
> instead of UnitX(), etc.

Gael: with that, you get the trophy of the most l33t l4p5u5 :)

> Otherwise I am impressed with the documentation so far, which is already
> much better than some projects I've seen. More is always better, of course!

Thanks -- and we know we must expand it further a lot.

Note how CMake helps there: it was very easy to script it so that code 
snippets are completed into compilable programs, built, run, and their input 
captured (and then incorporated by Doxygen).

The equivalent with Autotools would have been very cumbersome to write...

> Well, this design makes me uncomfortable - it seems like it's asking for
> this sort of trouble. Normally a module named Core would have no
> dependencies on other modules, which isn't strictly true here. I'm not sure
> why Array can't just be merged into Core,

Separating Array from Core makes compilation noticeably faster for people who 
don't need Array. For example, besides Core, many people need only Geometry, 
others need only LU.

We put in Core only:
- really basic stuff
- stuff that at least 2 other modules need to implement algorithms

Having separate modules means that we can expand them without having to 
discuss everytime: "is this feature worth the longer compile times" because 
you only pay for the modules that you use.

> Still, I thought of a cute trick you could use to get friendlier error
> messages. According to the standard, "The default arguments in a member
> function definition that appears outside of the class definition are added
> to the set of default arguments provided by the member function declaration
> in the class definition." We can abuse this to make nicer error messages,
> like so:

> [...]

> Then when the user includes <Eigen/Array>, he effectively gets the expected
> zero-arg version of rowwise. If he forgets to include it, no zero-arg
> version exists, so mat.rowwise() should produce a compiler error along the
> lines of:

Thanks for the trick... the first thing to notice is that it is only suitable 
for functions that are always inlined. For a non-inlined function, this 
incurs a (very small) overhead and more importantly this affects the 
function's signature.

How about this other solution: we let people enable modules by #defining a 
symbol before #including Eigen, so 

#include <Eigen/Array>
#include <Eigen/Geometry>

becomes

#define EIGEN_USING_ARRAY_MODULE
#define EIGEN_USING_GEOMETRY_MODULE
#include <Eigen/Eigen>

you read it well: only one public header. The old public headers stay until 
the next beta to let us time to port existing code. If you need only Core, no 
need to define anything.

I mean to use these symbols to do something like

class MatrixBase
{
   void someCoreModuleFunc();

   ...

#ifdef EIGEN_USING_ARRAY_MODULE
   void someArrayModuleFunc();
    ...
#endif

};

I know that's very unusual, so I don't feel 100% comfortable. What do you guys 
think?

This means that in a single project, different .cpp files may see different 
definitions of the MatrixBase class (if they use different modules). Can this 
be a problem?

> You would probably want to coerce Doxygen into hiding this bit of trickery,
> though.

Good point, and this is not going to be easy.

> I did a straightforward reimplementation of some of the pose estimation
> code using Eigen2 - it's about half the lines of code, far more readable,
> and almost twice as fast. Very impressive work you've done; I will be
> playing with this library more.

Thank you; on the x86 platform be sure to tell your compiler to enable SSE2 
instructions (-msse2 with GCC) so Eigen uses its vectorized paths (default on 
x86-64).

Cheers,
Benoit

---