[Date Index]
[Thread Index]
[Author Index]
Re: Re: Grassmann Calculus / Indexed Objects / Simplify
*To*: mathgroup at smc.vnet.net
*Subject*: [mg60870] Re: [mg60860] Re: [mg60763] Grassmann Calculus / Indexed Objects / Simplify
*From*: "David Park" <djmp at earthlink.net>
*Date*: Sat, 1 Oct 2005 02:55:45 -0400 (EDT)
*Sender*: owner-wri-mathgroup at wolfram.com
Robert,
I responded to you privately and sent a .pdf file showing the kind of
manipulation that you want, but apparently you never received it.
I believe the manipulations you want can be done with the Tensorial tensor
calculus package on the Mathematica page of my web site below.
David Park
djmp at earthlink.net
http://home.earthlink.net/~djmp/
From: Robert Schoefbeck [mailto:schoefbeck at hep.itp.tuwien.ac.at]
To: mathgroup at smc.vnet.net
thank you for your answer, i already get the feeling that this is going to
be involved.
On Thu, 29 Sep 2005, Carl K. Woll wrote:
> Robert Schoefbeck wrote:
> > Hello all,
> >
> > I want to implement superspace calculations in a mathematica package.
> > I define (code below) grassmannian theta-variables with upper and lower,
> > dotted and undotted indices. Having declared (anti)- commutativity
> > with DeclareOdd i use myTimes to handle multiplications of Superfields.
> >
> > Dummy indices are generated by use of Unique[]. All this multiplication
> > stuff works pretty well but looking at the one but last output i have
> > the problem that contractions with different dummies are not recognized
> > as equal.
> >
> > My questions are: Is there a way to tell mathematica to keep the
> > information that indices are equal but forgetting about the name of the
> > dummy?
> >
>
> The usual approach to your problem is to define a canonicalization
function
> which takes a monomial and rewrites the indices in the monomial in a
> standard form. Unfortunately, there is no good quick algorithm to compute
> this standard form. Your problem is complicated by the fact that indices
can
> be both upper or lower, so not only the names of the indices but there
> position will also need to be put in canonical form. If you have
> (anti-)symmetries in your indices, even more complexities occur.
>
> Ignoring the upper/lower indices and symmetries, one simple but slow
> algorithm to convert a monomial into a canonical form is:
>
> 1. Isolate the tensor quantities in the monomial.
> 2. Extract the indices.
> 3. Rename the indices (e.g., if there are 5 indices, call them i_1, i_2,
> ..., i_5).
> 4. Generate a monomial for each of the possible permutations of the
indices.
> 5. Sort these monomials, and pick the first one.
oh dear. i looked for this forum to find a way preventing this :)
> > I'd also like to pull indices with metrics, something like
> >
> > e[a,b]theta[b]=theta[a]
> >
> > How should i implement the defining relations for index pulling
> > (i have vector, and chiral/antichiral spinor indices, color indices and
> > so on) such that 1) Simplify can handle them?
> >
>
> Instead of using Simplify, why not just use replacement rules?
>
> e[a,b]theta[b] /. e[a_,b_] g_?(!FreeQ[#,a|b]) :> If[FreeQ[g,b], g/.a->b,
> g/.b->a]
some expressions are equal but look different (i posted an example in a
message that has not yet appeared in the forum)
and therefore i need a routine which flexibly substitutes up- and down
values for the symbols involved. (my example involves a minus sign
produced by index flipping of the symplectic spinor indices)
> > any help is welcome, does maybe someone have a sample application of how
> > to handle indices?
> > i'd also appreciate any comment on the code.
> >
> > robert schoefbeck
> >
> >
> >
> >
> > short description:
> >
> > OddPQ tests whether an object has odd parity or not
> >
> > mytimes handles ,multiplications
> >
>
> Instead of mytimes, why not use ** or one of the other Infix symbols with
no
> definitions like CircleTimes? It will look prettier, which should enhance
> comprehensibility.
i will do that.
thank you very much.
Robert Schoefbeck
Prev by Date:
**Re: Re: Re: Multicore Calculations**
Next by Date:
**VectorHeads much too big**
Previous by thread:
**Re: Multicore Calculations**
Next by thread:
**VectorHeads much too big**
| |