Maybe we should ask these people to do a Maxima port of grtensor?

I guess I better answer that, since I signed up as a Maxima developer
specifically because of the tensor packages!

Short answer: I'm busy looking at it.

Long answer: Much of the functionality of GRTensorII already exists in
Maxima as part of the ctensr/itensor packages. And, at least this is my
personal opinion, in some ways the itensor "indexed object" formalism is
superior (i.e., easier to use) than GRTensorII's tensorial objects, or the
tensor objects in Maple's built-in tensor package.

So what I am looking at is not a port of GRTensorII, but improving
ctensr/itensor and adding as much of the missing functionality as possible.

But first, making ctensr/itensor work again was my first priority. I am
proud to report that both itensor and ctensr are now fully functional
(notwithstanding any bugs that escaped my attention of course.) Actually, a
fair share of the credit should go to Valery Pipin, who not only supplied
new code that implements the calculus of differential forms, but also gave
invaluable help with the debugging of my changes/fixes to itensor. Thanks,
Valery! (The stuff in share/tensor in CVS is also backwards compatible with
Maxima 5.9.0, should anyone wish to use it with the current "production"
version.)

I am also looking at improving the integration between ctensr/itensor. It is
already possible to define components for an itensor "indexed object",
either using index patterns, or by supplying a user-defined function.
(Indeed, the latter method was used by people as a means to work around the
previously broken functionality in the COMPONENTS command.) This should make
it easy to link a ctensr list of tensor components to an itensor indexed
object, creating something that, in effect, encodes both index and component
information, like Maple's packages do.

With respect to new features, I already have a working test program, based
in part on new code, in part on code fragments that were present in
share/tensor, that can compute the Kerr metric and derive its
Petrov-classification. My intent is to perform an overhaul of ctensr to a)
rationalize its somewhat haphazard implementation of existing functions, and
b) implement new functions especially in the area of tetrad and spinor
representations so that computations like this would become standard stuff.

Hmmm, just in case my comments made anyone worry, I am a firm believer in
the idea that things that aren't broken don't need to be fixed. And, should
I plan a change in ctensr/itensor that would likely break existing code,
I'll definitely announce my plans in advance!


Viktor




-----Original Message-----
From: maxima-admin@math.utexas.edu [mailto:maxima-admin at math] On
Behalf Of Richard Fateman
Sent: Friday, May 14, 2004 11:01 AM
To: maxima
Subject: Maybe we should ask these people to do a Maxima port of
grtensor?

(from sci.math.symbolic ...)
For Maple and MMA we have GRTensor and it's free

http://grtensor.phy.queensu.ca/

Or maybe this is something someone here wants to look at
(I assume related to tensor computation already implemented...)

RJF

_______________________________________________
Maxima mailing list
Maxima@www.math.utexas.edu
http://www.math.utexas.edu/mailman/listinfo/maxima