Re: [Axiom-mail] how to calculate Ricci tensor from a metric tensor?

[Ondrej Certik]

I finally found some time to reply to this email, sorry about that. :)

> I am not against you having fun. As an end in itself and as a
> by-product of something else, that is fine. But even if you do get
> some novel results after building a new tool, I would argue that
> in almost every case you would be further ahead if you had
> invested the same amount of time in learning to properly use
> (and perhaps extend) some existing system.

I think if there is any system to extend with similar goals as SymPy
has, then it's SAGE. And I am definitely going to integrate SymPy into
it at some point. SAGE goal is to have something usable now. SymPy's
goal is to have something simple in python.

> Such open source alternatives already exist, e.g. Axiom and Maxima.
> They are both written in Lisp and modern Lisp implementations are
> certainly "reasonably fast", arguably perhaps as fast as C++. And
> the Sage project demonstrates that these can be made callable from
> python:
>
> http://www.sagemath.org

Yes, SAGE is getting there. I actually didn't beleive that Maxima
could be made callable from python (I mean more deeply integrated than
just passing strings around), but aparently, as the newest sage 2.5
shows, it is possible.

> >> One important problem with Maple (and any other CAS) is the
> >> lack of a standardized up-to-date language. For instance, the
> >> concept of Object Oriented design is not present. Quite
> >> generally, facilities for encapsulation are poorly developed.
>
> That is simply not true. Most standardization in programming
> languages occurs by de facto adoption despite efforts by various
> standards organizations. Maple has permitted coding in an
> object oriented manner since release 9 (see Maple modules). It
> could be easily argued that Axiom (alias ScratchPad) applied
> the concepts of object-oriented design and polymorphic type
> systems almost two decades before these were even recognized
> as interesting programming paradigms by the rest of the
> computer science and mathematics communities. So up-to-date
> is largely a matter of perspective or else Axiom was and
> still remains ahead of it's time.

As I understand it what they wanted to say and also what I think is
that Maple's language is a mess if I say it directly. But I don't want
to go into any flamewars about languages. It's just my opinion, that
it's so much easier to program in Python (or even in C++) than in
Maple.

> >> Rather than pointing out a number of Maple's linguistical
> >> and structural weaknesses let us ponder about one simple
> >> fact. The purpose of symbolic computation is to "simplify"
> >> mathematical expressions so that we can more easily understand
> >> their structure or code them more efficiently for numerical
> >> evaluation by a computing machine.
>
> I *very* strongly disagree with this statement as the main
> purpose of symbolic computation. At best it is only one possible

Yes, I also don't agree with them in this. For me the purpose of the
CAS is to do the same things that I would do by hand, but faster, thus
allowing me to be more productive.

> > What is not trivial is how to actually represent everything, and
> > that is an area, where no one actually knows how to do it.
>
> In fact that is exactly the point that is being addressed by Axiom.
> Axiom does provide (at least in principle) the means to represent
> everything. I disagree that no one knows how to do it. I think the
> Axiom designers showed very clearly how many areas of advanced and
> abstract mathematics could be coded and represented in a computer
> in addition to the more pedestrian concerns of data structures and
> algorithms.

That is remarkable, there is no question about that. I was meaning
just a simple calculus for "masses". As every code on the web that I
know of took a little different approach.

> > 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.
>
> What do you think is novel about the way that SymPy implements
> computer algebra?

I am aware of only the codes that are listed in the links on the
SymPy's webpage:

http://code.google.com/p/sympy/

And when I last measured the number of lines of code (with ginac,
giac, axiom and some others), SymPy was by far the smallest. So I
think novel is that the calculus for masses doesn't have to be
thousands of lines of code and many years of development in many
people. Also that 7 classes are enough to represent everything (in
calculus for masses) also I think shows, that (at least the calculus)
can be done quite simply.

> > 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).
>
> I think the concept of better and worse are too vague and subjective.
> You need to state clearly the objectives and find a way to quantify
> the differences between languages. I think this is a very difficult
> problem.

I know that my judgement about this can be wrong. But for me
personally the criteria are - number of developers of the language,
number of people using the language, number of different fields, where
the language is applied to (like web, physics, system administration,
etc.), how difficult it is to learn the language to fully understand
all it's syntax, how many libraries are written for that language. So
according to my criteria, the winners are (unordered), C, C++, Python,
Java, maybe also C#, Ruby. But I understand that there are other
criteria as well.

> > Your argument is, that it is not important the language is not
> > widespread, but rather that it is the best option for a CAS.
>
> I think SPAD and Aldor are much better suited to describing
> mathematics for the purposes of computer algebra than any other
> programming language now in common use. Since the accurate
> representation of mathematical objects and the efficient coding
> of mathematical algorithms is central to the goals of computer
> algebra, I do think they are the best option for a CAS.

I am not in argument here. For SymPy's goals and my criteria for
languages however, the Python is better.

> That is true. But one thing to note that at least in general
> form, i.e. syntax and data structures, SPAD and Aldor and the
> Axiom library are actually very similar to Python and were
> implemented as much as 20 years earlier than Python and similar
> languages.

Yes, that is remarkable.

> > SymPy is going to be a library in a standard widespread language.
> > We chose Python. So I think we are not reinventing a wheel.
>
> What "wheel" are we talking about? The programming language or
> the computer algebra system? Much of what you are trying to do
> with SymPy does indeed look like re-invention to me.

By reinventing the wheel I mean doing something again, when I could
instead take a working peace of code for my problem. I don't think
there is any other way of achieving SymPy's goal (except the SAGE's
way).

> > We are just trying to bring the CAS to masses, if I can use
> > this expression. :)
> >
>
> No, I doubt very much if this is possible, at least not any
> more than it is possible to bring advanced abstract mathematics
> to the masses. It takes years to appreciate the value of doing
> certain things certain ways and at least part of this is based
> on often unstated cultural and historical biases.

I think it is possible. I believe that the most important part of
mathematics, that is used in physics, that is needed to understand any
graduate book on general relativity, quantum field theory or
statistical physics can indeed be learned by anyone (I am not talking
about understanding the physics, just the formulas - what they mean
and how to calculate with them). And I think the CASes now are
becoming a standard tool present on any system, like the programs for
solving large sparse/dense matrices.

Ondrej