[eigen] Tensor module - Einstein notation
• To: eigen@xxxxxxxxxxxxxxxxxxx
• Subject: [eigen] Tensor module - Einstein notation
• From: Godeffroy VALET <godeffroy.valet@xxxxxxxxxxxxxxxxx>
• Date: Sun, 21 Jun 2015 13:00:10 +0200
• Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=ZsbKHICI34RV7klOYKNoUHOiFyfQb7YMSm3Wq25/fXc=; b=BIhEjOEp982ERjFhd300c2rU41hUDp5mPtIOYV3KUs76w74Dn1uTErYhzmCnSpjnNq 2TK7nW5Xp8tRJeoFuccS/I+L4FwwLmGXcSH4GR02FA70ZLIbgzp3jJfNPhQVDfmiHAcJ wp1zKIqsJSa4ZCXCfr4UFAuKzPqDj9+PiG9ylBNwG8/0d+mkwJvBiVKLuJYA+7PcpJAB SnOSqt6Ip7E2fK72lWzJcnPNpKsh/fD8Fs6X7oAsnuDASBU8+kVRzUBZ+llrtdhfpvdf HIixjShhD3HUMFUS8ykRB4PfpfGuzO9MQvPHGuoU5yScrnAZAuOxvssw9600ZHYsdHsr 2RZw==

Hello,

As I have said some time ago on the forum (https://forum.kde.org/viewtopic.php?f=74&t=125958), it would be nice to have an "implicit summation" notation such as :

`r(i,k)=a(i,j)*b(j,k); //this contraction is the matrix productr     =a(0,i)*b(i,1); //dot product of 0th row of a with 1th                        column of b, using slicing and contractionr(i,j,k,l)=a(i,j)*b(k,l) // tensor product resulting in a 4th order tensor`
The motivation is simplicity, scalability of the notation and readability.

Now there are a few implementation decisions to make :
1) do we implement this feature over existing operations (chip, contraction, tensor product), or do we implement it on its own and rewrite existing operations over it ?

The first choice would seem more reasonable at first and is also easier. But this notation is actually much more general and code might be factored in a unified implementation. Is there specific optimisation for each operation that cannot be factored, etc ?
Besides, I haven't found the tensor product in the currently available operations yet.

2) do we allow general implicit summation or only Einstein notation ?

With Einstein notation, the indices are normally "up" or "down" so that at most two instances of the same index is allowed in an _expression_ on the right side of the equal sign (one "up" and one "down" in mathematical writing, in code they look the same) :
`r(i,k)  =a(i,j)*b(j,k);``        //ok, only 2 'j's`
`r(i,k,l)=a(i,j)*b(j,k)*c(j,l); //not ok``, more than 2 'j's`
The second _expression_ would be allowed with general implicit summation.
Therefore, general implicit summation is more powerful, but adds constraints to the implementation. In particular, if we allow it, we cannot reduce the subexpression `a(i,j)*b(j,k)` to a contraction operation.

I think that this choice depends on the decision for the first question. If the notation has its own implementation, it is natural to allow general implicit summation. If it relies on underlying operations, then it would be easier to stay with only Einstein summation for now.

What do you think ?

On the forum, I have said that I would try to implement this myself.. As it is only on my free time, I do not promise I will finish it any time soon. But if someone needs it or wants to do it quicker than me, you can contact me.

Best,
Godeffroy

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