Sage Days 8 and SymPy
Ondrej Certik
I was at Sage Days 8 and I posted what we were doing in there to my blog:
http://ondrejcertik.blogspot.com/2008/03/sage-days-8.html
here I'd like to put some points related to SymPy and Sage.calculus.
We discussed quite a lot of it in Austin, but I'd like to have it in
the mailinglist as well. CCing sage-devel too. I am interested in any
comments, especially if you think that I am completely wrong. :)
1) The idea of SymPy is to have something that is easily extensible,
easy to use/install, pure Python by default (possibly later with some
optional parts in C), that together with numpy, scipy, ipython,
matplotlib and other projects will provide all the necessary tools
that one needs to do scientific (engineering) calculations. Most of
our users are imho people using these tools anyway.
We should adapt our page, that currently says "It aims to become a
full-featured computer algebra system (CAS)", because a CAS for me is
anything I may need in physics/engineering, but for mathematicians,
CAS means a lot of different things too. Also CAS probably implies all
the other things that go with it, like numerics (scipy+numpy),
notebook (Sage or ipython1) etc.
2) People, that want the bigger picture, all in one solution, should
use Sage, that includes all of these tools. Sage.calculus is currently
based on maxima and Gary is currently rewriting the core of it in
Cython, so that maxima is only called for difficult things, like
limits and integrals. When this is done, then it'd be quite easy to
slowly replace maxima part by part with cython+other parts of sage.
What I personally would like to have is something that is not
depending on the rest of Sage, because I like the tool doing one job
and doing it well. I don't like all in one solutions, but rather
separate libraries, leaving it on myself to assemble the final program
out of it. Sage mission is more to be a viable alternative to
Maple/Mathematica/Magma/Matlab, all of which are monolitic all in one
solutions (and much bigger than Sage actually). That said, I think
that in few years when Sage matures, I think people will be interested
in making the parts more independent. But currently to make
Sage.calculus work, you need to download either the binary (260MB), or
200MB of sources, do "make" and wait for couple of hours. With sympy,
you download 1MB of sources, do "import sympy" and you are up and
running. See also below for more arguments on this.
3) Other advantages of SymPy over Sage are:
* small and BSD licensed, so you can include it in your own project
without any restrictions (technical or political).
* being pure python and having a simple design, you can easily debug
it and fix it to make it work for your problems (please send your
patches back to us:)
* works natively on all platforms
As Michael Abshoff has pointed out, Sage will be working on windows
natively too, maybe even by the end of the year. Actually Microsoft
finances the port, which I find really cool that MS is financing a
truly opensource project (that among other things brings a lot of
people to Python). Another point that Michael made, is that Sage will
finally get to linux distributions too (Debian and others), thus being
easy to install and use. Which definitely makes a lot of things
easier. Nevertheless, when something has 1MB, it is a lot easier to
deal with, I must stand on my point here. :)
Ondrej
Gael Varoquaux
I'd like to pick up some of the points you make in your mail, especially
the ones about why sympy is relevant.
I admire sage a lot. It is an impressive project. However, it is a project
closed onto itself. It is hard for me to use part of sage (say the logics
to compute integrals) in for instance a scientific application doing
on-the-fly control of an experiment. On the contrary, sympy gives me this
option. Sympy integrates seamlessly with the rest of the Python
scientific stack and really feels like an easy-to-use library. The work
you have recently been doing to help integration with numpy is very
important in this regard (see also my post earlier todo about adding
numerical fallbacks to sympy functions, which are another part of
impedance matching between sympy and the other scientific Python
libraries).
I'd also like to insert here a small shameless plug: the reason I prefer
Mayavi2 to Paraview is also that it plugs into the stack I use (I am
actually focusing on improving this with the Mlab interface).
So keep the good work up, and keep making sympy not only a good CAS, but
also one that can easily be used as a library.
Cheers,
Gaël