Re: how to calculate Ricci tensor from a metric tensor?

> I have some doubts about that claim. But I guess this is not really
> the issue you want to discuss. :-)

Yeah, it wouldn't lead anywhere. :)

> If you could suppress your revulsion of the Maple language, then I
> could send you information about a package I wrote a few years ago
> called TensorLite. I used it to do symbolic manipulation of tensors
> in Maple V release 5 for calculations similar to that which you
> describe. If you have Maple, you should be able to read this:
>
> http://synthesis.anikast.ca/maple/mathematics/tensor5c.mws
>
> If you have any interest, just let me know. With a little effort
> I could probably remember what I was doing at that time...

It's nice. I tried that on maple 9.5 and after a while it says:

Execution stopped: Stack limit reached. Worksheet lost contact with
kernel. You should save this worksheet and restart Maple.

Well, this is exactly a reason, why I find Maple completely unusable...
But anyway, I'll try to learn from your sheet in order to implement it
nicely in SymPy. Thanks.

> Yes, isn't that the way things go in computer algebra - everyone
> seems to write their own? :-( That's a pity. If what you really
> want to do is physics, then it's a trap that many people have
> fallen into. It took me a long time to get over that stage.

Well, it depends. You cannot stay at that, you need to get some real
results, otherwise it's of course nonsense to create anything from
scratch. But SymPy, besides fun (which is very important) also allows
me to play with the differential geometry already. And I like it. I
like to play with ideas, so I think it was not a lost time.

> Actually I looked at SumPy a while back on Google Code. I think
> its pretty cool. Do you know anything about Sage? Sage is another

Sure. I corresponded with Bobby Moretti quite a lot about the symbolic
manipulation, because he is writting something almost identical to
SymPy in SAGE right now, but currently SymPy is much more mature than
his code.

> computer algebra system that is written in Python, but they
> incorporate a lot of other open source math software packages
> such as Maxima, Gap, gmp, mpfr, etc. to do things not implemented
> in native Python. Perhaps they would be interested in SymPy for
> it's symbolic capabilities.

They are. I guess we'll wait until the summer is over, as I expect
some really good students to take part in. As we have on our webpage:

To sum it up: It would be nice to have an opensource alternative to
Maple/Mathematica, that is reasonably fast (maybe written in C++),
could be easily extended with your own ideas, would be callable from
python and could be used in real world problems (as Maple/Mathematica
can). SAGE is also trying to achieve this goal, but from a different
side - SymPy aims to be lightweight, whereas SAGE aims to glue
together every useful open source mathematics software package and
provide a transparent interface to all of them.

> You will also need:
>
> section 1.13 Differential Equations  (introduction)
>
> and
>
> section 8.10 Solution of Differential Equations
>
> Using these two parts of Axiom in principle it should not be
> too difficult to do the calculations you want to do.

Thanks. I'll look at that. What surprises me, that there are not
already some examples of such usage of Axiom, as I think those are
things that everybody wants to play with at the beginning.

> But I do hope that it will be possible to build new
> systems based on past experience and previous investments rather
> than repeating past mistakes and re-inventing the wheel.

What I can say from my own experience - the time I spent implementing
some particular algorithms (limits, series expansion, gcd or square
free decomposition of polynomials) was completely negligible compared
to time spent inventing and designing the interface. I took GiNaC as a
starting point, but I improved things that I didn't like on it
(removed unnecessary classes etc). From Axiom I can just learn how to
do some particular symbolic algorithm, but as I said - this is not a
problem, as what SymPy does so far is very trivial from the
mathematical point of view.

What is not trivial is how to actually represent everything, and that
is an area, where noone actually knows how to do it. So even if the
only contribution of SymPy is that we actually showed that the CAS can
be done this way, it will be good.

I learned however how not to do things - I am in no way trying to
reinvent some new (better) language, even if that language was
actually better than Python. Actually, all the languages turned out to
be worse (Maple/Mathematica/Maxima). Maybe Aldor will turn out to be
better, but currently, from the technical point of view it isn't (many
bugs, almost nonexistent user base, not opensource, etc.). Your
argument is, that it is not important the language is not widespread,
but rather that it is the best option for a CAS. But then you are
immediately creating an obstacle for newcomers. It has it's
advantages, I understand that, but it also has a lot of disadvantages.

SymPy is going to be a library in a standard widespread language. We
chose Python. So I think we are not reinventing a wheel. We are just
trying to bring the CAS to masses, if I can use this expression. :)

Ondrej