Symbolic computation in Python via CL-Python or something like that
Robert Dodier
I like Python as a programming language and enabling symbolic
computation in Python is a worthy goal. However in the interest
of getting something working it seems like it might be better to
reimplement Python in Lisp and then import an existing package
for the symbolic stuff. There is a project called CL-Python which
is an implementation of Python for Allegro Lisp. It seems like it
would be less work to finish that and port it to other Lisp
implementations than to reimplement all of the functionality of
an established algebra system, e.g. Maxima.
I don't mean to rain on anyone's parade but since I would like
to see symbolic computation in Python as much as anybody,
I am thinking of the best way to achieve that. Maxima has the
accumulated investment of decades of development, and it
covers a very wide range of topics. Reimplementing all that
would be extremely time consuming. Aside from that, I'd like
to see the talented people of the Sympy project creating new
functionality instead of just reimplementing stuff that other
projects (e.g. Maxima) have already.
Plus there is a LOT of Lisp code out there that could be
useful to import into Python.
Disclaimer: I am a developer and administrator of the Maxima project.
All the best,
Robert Dodier
Ondrej Certik
thanks for your email. I have thought about this issue quite a lot
when I decided to start SymPy, so here is what I think:
1) I think the way to use maxima in Python is just to call it and
that's what SAGE is doing and I think it's doing it pretty well.
2) I am not sure the CL-Python is the way to go. The project is here:
http://trac.common-lisp.net/clpython/wiki
However, it seems just one person is developing it, and that's exactly
the languge trap as with Aldor in Axiom - that there are virtually no
users of the language implementation that the CAS wants to use. Also,
we can write a new CAS, but I will not write any new computer
language, or a new language implementation - because (and that's just
my opinion) that's by an order of magnitude more work than just
reimplement a few basic algorithms in a widespread language with a
well tested implementation. And also I don't know how to develop
languages. But I know at least a little how to write some symbolic
algorithms.
Is it possible to call all the libraries that exist for the current
Python from CLPython? It's crucial to use a widespread platform - and
that doesn't mean just the language, but also the implementation and
other things, so that you can reuse the work of other people. If I
understand it (correct me if I am wrong), the CLPython can be started
on top of LISP, but in order to reuse all the code that other people
write in Python, you would have to fully support another python
implementation. Well, in my opinion, that cannot succeed. However,
there is a PyPy's LISP backend:
http://codespeak.net/pypy/dist/pypy/doc/translation.html#gencl
But until PyPy goes mainstream, I would very, very hesitate to depend
on it. And the same for CLPython. The PyPy is promising and that is
also the way to go - to just write a translation from RPython (a
subset of python) to the other languages (LISP, C, .NET, java,
javascript) and when the new version of python goes out, they just
implement the feature using RPython exactly once and it will start
working on all the platforms. I really hope PyPy will get widespread,
because that I think will be a boom for Python, but until it does, I
don't want to depend on it.
3) I also have doubts about a serious reusability of other CAS
systems. For example, I implemented the Gruntz algorithm for limits. I
think, currently, the only other opensource CAS, that has this
algorithm, is Giac. And the other modules for SymPy - well, they are
very small and simple and there really is no problem of writing them
again. The only thing, where SymPy is actually reinventing the whell
is the Sympy.core. However, that's currently just 2000 lines of code
with extensive comments (btw does anyone have a tool for counting
lines excluding comments? I use py.countloc). And it's not going to
grow much, as the basic things are already implemented. And what most
people want from a symbolic system is just a calculus and a linear
algebra and that SymPy already can do, or will do soon.
If you want to just glue existing packages, that's the way SAGE took.
However, it's a huge package, and also, at this very moment, I think
SymPy is better in the calculus usage. However, this can change of
course, SAGE is working on it. But, SymPy's approach is also
promising. I think it will be clear at the end of this summer, if the
approach we took is really the way to go, or the way to go is to glue
everything that exists, like SAGE is doing, and then possibly make it
more and more usable. I myself have doubts that the hybrid
python-maxima (in SAGE currently), or python-axiom (or any other
hybrid) can be gradually improved, without just reinventing SymPy.
And last but not least, I want sympy to run on a pure python (and all
the basic things should be working, at least slowly, without any
external dependecies). And I want to keep it simple, so that it is not
difficult to learn how it works.
So I am not saying that SymPy is the only way to go, but I think it is
definitely one of the ways.
Ondrej