13 views

Skip to first unread message

Mar 6, 2008, 5:44:18 PM3/6/08

to sy...@googlegroups.com, sage-...@googlegroups.com

Hi,

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

Mar 6, 2008, 6:20:04 PM3/6/08

to sy...@googlegroups.com

Hi Ondrej,

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

Reply all

Reply to author

Forward

0 new messages

Search

Clear search

Close search

Google apps

Main menu