Hello, I have used Eigen for some time but I now need to have tensor support. Eigen provides a Tensor module whose current features are described on this wiki page: "http://eigen.tuxfamily.org/index.php?title=Tensor_support", and it seems that we are far from a full feature set. And I have found an old discussion about this module here "http://comments.gmane.org/gmane.comp.lib.eigen/4273", but it seems a bit out-dated.

So, does anyone knows if this wiki page is up-to-date?
Is someone currently maintaining or even improving the tensor module ?
How can I help to improve this module (if help is needed) ?

There is a much more complete tensor module documented there: https://bitbucket.org/eigen/eigen/src/a ... en-tensors

We should update this wiki page to reference the above new Tensor module.

Ok, thank you. This is indeed much better.

However I would strongly prefer a different API for slicing and contractions:
- chipping syntax is quite confusing to me

Code: Select all

a.chip(2, 0) ; //can't remember which one is offset and which one is index


- contractions seems way too verbose, espacially if one needs to combine several of them

Code: Select all

array<IndexPair<int>, 1> product_dims = { IndexPair(1, 0) };
Eigen::Tensor<int, 2> AB = a.contract(b, product_dims);


Implicit indices summation would be much nicer I think :

Code: Select all

a(i,j)*b(j,k); //this contraction is the matrix product
a(0,i)*b(i,1) // dot product of 0th row of a with 1th column of b, using slicing and contraction
a(i,j)*b(k,l) // tensor product resulting in a 4th order tensor

V(i,w,z)*(XX(w,j,1)-XX(w,j,0))*(XX(z,k,2)-XX(z,k,0)) // real life tensor operation combining contraction and slicing

I guess i,j,k,... could have some Eigen type and operator() could be overloaded for this new type, returning an adequate tensor expression.
Are there reasons for not using this notation except that the implementation would be more tricky ?

Yes, at some point the Tensor module will have to support a more powerful API similar to the one you described, but as you noticed, it is much more tricky to implement.

I see. In my use case, I have screen wide formulas even with the API I have described, so that using the current Eigen API is not really an option.

However I still want to use Eigen, so I think I will try to implement this API myself. If I can make a satisfactory implementation, I will use it for my own project and provide it somewhere.

Excellent. Also feel free to discuss this API extension on the ML [1] to reach other developer and in particular the author of this Tensor module which is still actively developed.

[1] - http://eigen.tuxfamily.org/index.php?ti ... iling_list

just a comment: Implicit indices summation is done for example in FTensor
http://www.wlandry.net/Projects/FTensor

Yes, I have found this tensor library too, and it seems quite well implemented with expression templates as well. Also, the notation I have suggested is indeed a commonly used one and an efficient one.

As a comparison with Eigen, I didn't like FTensor so much though because it isn't one tensor class which can have an arbitrary rank, each rank has its own class. Moreover, having tensors as a part of a wider linear algebra libriry is more convenient.

You're are right. A tensor module with Einstein summation convention in Eigen would
be great. FTensor is from 2003. But still a nice library.

Did somebody think about

"Up" and "Down" indexes?
Meaning is there a notion of dual and primal indices so far when using this library or has the user to know what he is contracting =)?

I think it would be awesome, to have such a thing as a dual or primal index. such that the user gets a static compile error when he is contracting primal with primal or vice versa
which might be nonsense .
but i think that is too restrictive, and the user should make sure him self either by giving the indexes a name (comments or what ever =)

i am just curious, this is no critic or something , its cool that tensors are support in eigen3

br