I've been asked by Certik to transfer the discussion about the possible tensor module improvements to this mailing list (instead of github's). The tensor module is, in my opinion, essential to Quantum Field Theory, especially if we want to implement an interface to represent any formula of a QFT textbook inside SymPy.
I continue this discussion, as I believe that most of its concepts should be implemented inside the tensor module. A brief overview of the tensor module: 1. *TensorIndexType* class, specifies a class of indices (like *spinor, lorentz, qcd_charge, ...*) 2. *TensorHead* class, to represent a tensor without its indices. 3. *TensMul, TensAdd* *(TensExpr) *to represent expressions of * TensorHead* with indices. 4. some other classes. The tensor module is wonderful code, but it has two main problems, as of now: 1. it uses two representations of tensor indices: the visual one (indices with a + or - sign according to their contravariantness/covariantness), and an internal representation as lists (this is useful in algorithms, but really bad to read for a human being). I suggested to split the aforementioned tensor classes, in order to avoid that code handling the visual index representation and the internal index representation gets messed up. Here is my PR: https://github.com/sympy/sympy/pull/2338 2. The tensor module does not pass the *test_args* test, so *TensExpr* may behave queerly upon ordinary SymPy actions like .*subs( ), .xreplace( ), srepr( ), .args* This is a serious problem, because if we are to write algorithms performing QFT tasks on tensors, we have to be able to extract subexpressions of specific types of tensors. For example, gamma matrix reduction algorithm should work only on gamma matrix objects inside a tensor expression, not on (say) light polarization vectors. To solve this point, I think it's better to first finish point (1), so the tensor code will be far more clear and readable. 3. Redundancy: *TensorHead* requires *TensorIndex* objects when costructing a *TensMul*, but *TensorIndex* objects are just a * TensorIndexType* and a string, and *TensorHead* already knows which types are supposed to be in which positions, so an ordinary *Symbol* could be used in step of a *TensorIndex*. 4. Find a way to represent numeric indices. *Gamma matrices* * * Gamma matrices are a (Lorentz, Spinor, Spinor) type tensor, usually the two-spinor indices are meant as a matrix multiplication, so they can be viewed as (Lorentz) tensors. In my opinion a possible gamma matrix object has to inherit *TensorHead* and allow both (Lorentz, Spinor, Spinor) and (Lorentz) representations. In the latter case, spinor indices should be automatically managed inside expressions containing more than one gamma matrix with (Lorentz) signature. I am still not very sure on how to proceed here, especially as there are more urgent issues, but over the time I'll think how exactly do this. Gamma matrices are very important objects in QFT, I have identified two efficient algorithms to simplify expressions of gamma matrices with contracted Lorentz-indices: 1. Kahane's algorithm, already merged into *master* (sympy/physics/hep/gamma_matrices.py), the fastest one, allows reducing expressions of gamma matrices in 4 dimensions. 2. Kennedy-Cvitanovic algorithm, slower than Kahane's, but acts independently of dimension (can be used with dimensional regularization and in 2^n dimensional gamma matrix Clifford algebra). It basically uses the Fierz identity to break internal Lorentz lines (i.e. index contractions) in gamma matrix expressions, then cleans everything up using the completeness relation of Dirac's Clifford algebra. Once both algorithms are implemented, a *simplify( )* and a *trace( )* call on the *TensExpr* should use Kahane's algorithm on 4 dimensions, otherwise drop on KC. It would be nice to be able to use *simplify( )* and *trace( )* and a * TensExpr*, and have these actions propagate on specific objects, so as to trigger the proper algorithms. *TensExpr* has therefore to implement *_eval_simplify( )* and *_eval_trace( )*, and create a mechanism to propagate this on subexpressions (remember: gamma matrices must stay in the physics module, the tensor module must not know anything about that, it is a deeper abstraction layer in this API, therefore its triggering mechanism has to be generic, not specific for gamma matrices). *Later work* * * Sorry for stressing much on gamma matrices, but it is a first step towards a more general API for QFT. I would start with them. In any case, some possibilities for a later work include: - mixed operators and tensors. - partial derivative of tensors, indexed derivatives. *What should be done now* * * Make the tensor module SymPy-compliant, and have the *test_args* work. If this step is not completed, it is hard to create algorithms to handle expressions of mixed tensor types. -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sympy. For more options, visit https://groups.google.com/groups/opt_out.
