On Wednesday, September 4, 2013 5:34:32 AM UTC+2, Ondřej Čertík wrote: > > Here is another idea, but maybe it does not work for some reason. > Why cannot we represent the gamma matrices as 4x4 symbolic matrices? > Then the whole expression is just matrix multiplication and at the end > you end up with a 4x4 symbolic matrix (with possibly complicated entries). > > This means that intermediate expressions will necessarily be > complex/unreadable. > But the end expression which typically involves a trace might be ok. > Though > I am aware that many times you end up with contracted vectors like > momentum, > and we might get a messy formula instead. > > Well, why? The first part in abstract handling of spinors (gamma matrix reduction) has been done.
I tried some months ago to implement matrix-based implementation of spinors, following Schroeder's textbook, but it was a complete mess, *simplify( )* was unable to simplify expressions (they were too complex :( ). Abstract gamma matrices can be easily traced-out to Minkowski products (just a recursion relation). What we need is to solve the bugs in the tensor module, consider that *0*A(i0) == 0* returns False instead of True. There are serious issues in the tensor module. > > 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. > > It sounds good to me. Do you know how to get it done, or did you get > stuck at some issue in your PR? I have a clear plan in my mind, but Krastanov (who was following my PRs), is temporarily not available, so I am not able to merge them to the master branch. Basically, what I did: 1. I wrote a first PR to make the tensor module *test_args* compliant, it succeeded, but the code was a real mess. Here is the link: https://github.com/sympy/sympy/pull/2177 The problem is that there are two kinds of tensor representations, external representation (which should be in *args) and internal (which is just a useful representation for internal algorithms, it is not human readable). All code is messed up, sometimes it uses the internal repr, sometimes the external. 2. To solve this issue, I created a new object: *TIDS. *This object has to store all algorithms concerning tensor indices (contraction, sorting and so on). *TIDS* uses the internal repr, while the already-existing * TensExpr* will use the external repr, with a link to a *TIDS* instance. Here the PR: https://github.com/sympy/sympy/pull/2338 This should is partial work, I was waiting for some project admin to review/merge. I stopped working because there was no one following, in any case if you can assist me, I can easily complete this PR. Unfortunately issues are not solved by this PR, it should be followed by another PR based on #2177, shortly after merging. I think it is urgent to fix issues on the tensor module, otherwise it blocks all my projects to go on with QFT. Just consider that *.subs( )* does not correctly work on tensors... > Btw, I am thinking of contributing my code generation / contraction of > scalar diagrams. I was hesitant, > because it doesn't use much of sympy and there is danger of having > bunch of non-interoperable modules. > But the advantage is that at least we can have something, while > necessarily specialized, it can still be used > later for this specialized case. > > I also have code for generating diagrams/expressions for > non-relativistic perturbation theory (e.g. just > Schroedinger equation). It's much simpler than QFT. It might be useful > to provide nice interface to the ipython > notebook. > > Ondrej > -- 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.
