======= Just so we are sure that we speak about the same thing:
There are a few things that people mean when they say tensors (my explanations and examples will include much hand-waving for the sake of brevity): 1. multidimensional array supporting Einstein index notation (without distinction between covariant and contravariant indices). This is implemented (well I think) in the `Indexed` class in `tensors`. However it is not of much use for anything other than code generation for summation loops. 2. explicitly represented tensors in some basis. This is just a multidimensional `Matrix` class. I have an ugly frankensteinian implementation for such an object that I needed for a school project. This is very close to the previous notion, however it supports covariant/contravariant indices. Check http://www.xact.es/xCoba/index.html for a very serious implementation of this and more. 3. abstract tensors based on the index notation formalism (but with Penrose abstract indices). This is what the core of xAct does, and this is what Mario proposes (I think, correct me if I am wrong) 4. abstract tensors based on products of form fields and vector fields (what my GSoC Differential Geometry project may provide (however it is a secondary goal that may get finished after the end of the project)) An analogy to make things clearer: 1 relates to 2 relates to 3 relates to 4 as numpy to matrix algebra to linear algebra to differential geometry numpy - just arrays matrix algebra - notions for certain high level operations linear algebra - work independent of the choice of basis differential geometry - vectors become vector fields, etc. ======= I have also cc-ed this to prof. Comer Duncan as he has expressed interest in using sympy for tensor-heavy workflow. ======= My comments on the proposal: One thing seems unclear to me: how will tensors be implemented. At the moment this problem is apparent in other sympy modules: - quantum mechanics - the need to represent kets and bras - subclassing Expr and dealing with the need to implement the new logic for handling the expression trees. - matrix expression - the need to represent abstract_matrix_symbol*matrix_that_actually_contains_elements, etc - subclassing Expr and creating stuff like MatAdd, MatMul, etc and again dealing with the need to implement new logic for handling the expression trees. A few times I have said that I do not think that this is sustainable. What happens when I want to work with object from different submodules... Instead I would prefer just to build the expression trees using simple Add and Mul nodes and use crawlers that do what they have to do. It would be much easier to add new logic to these crawlers, like knowing what certain matrices can not be multiplied with each other for instance. I am doing this for my Differential Geometry project and this is also what the xAct project have done for their tensor representation. So I urge that when work starts on this project the author does not create anything else than a simple Tensor class. He can then design all the rest as functions that expect expressions trees containing Tensor instances and other stuff in some canonical form. The canonicalizer is separate. The function that verifies that the input is not nonsense (Dividing scalar by a vector) is separate. ======= One more thing: > For the last two steps probably one has to develop a module on Young > tableaux; > I saw there is one in cadabra [3] @Aleksandar Makelov, is this part of you GSoC project? How much of this will depend on new functionality in the group theory module? More generally, how can the work on canonicalization be done so it does not interfere with the Aleksandar's work on group theory? It would be a pity if you both implement the same stuff instead of separating the work. -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
