MathGroup Archive 2005

[Date Index] [Thread Index] [Author Index]

Search the Archive

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