[eigen] refactoring fork: some news

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]



Hi,

some news from my fork: http://bitbucket.org/ggael/eigen2-et-refactoring/.

Let me first recall that the initial goal of this fork was to refactor our _expression_ template tree so that is becomes easier to add and use new matrix types. In the same time I've added a true support for "Array" and started to clean the sparse module thanks the new possibilities offered by the new design. So in order to achieve this goal while minimizing code redundancy as much as possible, I've employed a couple of different mechanisms which are summarized on the following self explanatory scheme:

http://eigen.tuxfamily.org/misc/eigen_new_design.xml  (requires umbrello)
http://eigen.tuxfamily.org/misc/eigen_new_design.png

Note that's not at all an UML diagram, I just tried to quickly picture all the major aspect of this new design on a single diagram. I hope it is clear enough, otherwise feel free to ask for precisions.

In this fork I also moved all deprecated features to a new Eigen2Support module (i.e., lazy(), marked(),  .cwise(), etc.) In order to enable Eigen2 compatibility you can either do:

- #include <Eigen2Support> before any other Eigen header
- #define EIGEN_EIGEN2_SUPPORT before any other Eigen header (in this case you don't have to #include Eigen2Support)

Feel free to propose another solution.

Currently the fork is good enough to pass all the unit tests, but it still requires a lot of work regarding cleaning, documentation, and the unit tests have to be extended to check for Array objects. But before going further I'd like to hear your opinion about this new design.

Another question: how to name the predefined typedef for Array ? The problem is to distinguish 1D and 2D array. So for I've use the following convention:

Array33f => 2D 3x3 Array of float
ArrayXXf => 2D dynamic Array of float
Array3f => 1D Array of float of size 3
ArrayXf => 1D dynamic Array of float

but that's not consistent with Matrix's typedefs. Any idea?

Still about Array, let me recall that we agreed upon removing .cwise() in favor of a few cwiseXXX function for Matrix objects (e.g., mat.cwiseProduct(mat), mat.abs()), plus a MatrixBase::array() function allowing to see a matrix as an Array, e.g.:

(mat.array().abs()>10).select(A,B);

instead of

(mat.cwise().abs().cwise()>10).select(A,B);

For the other way round, i.e., to see an Array as a Matrix I used the function asMatrix() because some expressions already defined a .matrix() function, that is not consistent.  So do you prefer to stick with .array()/.matrix() (in which case we have to rename the matrix() function of some expressions), or finallydo you prefer the more explicit but more verbose .asArray()/.asMatrix() names ? or perhaps toArray()/toMatrix() or .arrayView()/.matrixView() ??



Cheers,
gael


Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/