Re: [eigen] refactoring fork: some news

[Benjamin Schindler <bschindler@xxxxxxxxxxx>]

Hi

On 18.12.2009 09:53, Gael Guennebaud wrote:
>
> 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
Pretty graphs - and it makes a lot of sense to me!
>
> 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?

May be It's a misunderstanding from my side, but isn't the array class
mainly for component-wise operations? Is it so I can have a method
..matrix() which returns a matrix with correct dimensions? If not, why do
we even care about 2d arrays ArrayXf, Array2f etc would then suffice..

>
> 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

Cheers
Benjamin