Hi, On Mon, May 2, 2011 at 2:02 PM, Aaron S. Meurer <asmeu...@gmail.com> wrote: > So there has been some discussion recently, both on and off list, as to what > SymPy is and what it should be. That is why I think that we need to have a > mission statement, which clearly outlines what SymPy is and where it should > go. > > Fortunately, I think we have really had one all along. I think the standard > description of SymPy at the top of our website, the Google Code page, and a > bunch of other places is a perfect mission statement. This is it, except I > have added "open source," because I think that's important to have in there. > > "SymPy is an open source Python library for symbolic mathematics. It aims to > become a full-featured computer algebra system (CAS) while keeping the code > as simple as possible in order to be comprehensible and easily extensible. > SymPy is written entirely in Python and does not require any external > libraries." > > To break this up into its component parts: > > "SymPy is an open source…" > > SymPy is BSD licensed, which means that people can incorporate the code in > non-open source projects. This is a good thing, because it lets people use > SymPy who otherwise wouldn't be able to. BSD is a good choice for libraries > like SymPy. But the core library code should always be open source. I don't > think anyone would disagree with this, but it's important to have it in the > statement. > > … Python library…" > > SymPy should be written in Python. See below. > > "… for symbolic mathematics. It aims to become a full-featured computer > algebra system (CAS)…"" > > This is one of the places where we have had disagreements recently. The core > goal of SymPy is to become a full-featured CAS. This means that we should > try to become just as powerful as any of the great CASs out there, like > Maple, Mathematica, Axiom, etc. So if you could see something being > implemented in one of those, then it can be implemented in SymPy to. Just > take a look at the diversity of our GSoC projects this year. Some of them > are very core CAS, like the Groebner bases project or the Meijer G-Function > integration project. Others are a little more external, like the quantum > projects or the PyDy project. But these all belong on SymPy because they are > things that you could easily see being part of a CAS like Maple, and they all > relate to symbolic manipulation. > > We have things that are not directly related to symbolic manipulation, like > the mpmath numerical library and plotting. But of course, these things > belong in a CAS (it's hard to imagine Maple or Mathematica being unable to do > plotting, for example). > > "… while keeping the code as simple as possible in order to be comprehensible > and easily extensible." > > I don't think there is much to elaborate on here, and I doubt many people > will disagree with this. One thing that I want to mention is that the fact > that SymPy is written in Python, which is a very clean language, means that > the algorithms will be very easy to read. Python also makes the source code > very accessible. So it is very easy for someone to dig in and learn how > something works. > > "SymPy is written entirely in Python and does not require any external > libraries." > > This is important. You should be able to use SymPy with nothing but Python > installed. Sure, some features might require some external library or > further dependencies (like plotting for example), but you should be able to > use the core functionality of SymPy with nothing but Python. > > The lack of any required external dependencies is also important. It makes > it very easy to use SymPy anywhere. For example, a high school student could > use SymPy on his personal account on the school computers, so long as those > computer have Python installed, even if he doesn't have any administrative > privileges on those computers, simply by downloading the tarball and running > isympy out of the bin directory. I'm sure others will have some examples > of why this is a good idea.
I 100% agree with this mission statement. I would add, that the most obvious addition to sympy is numpy, scipy, ipython, matplotlib. Those are old, well known and tested libraries, with large community around them. So these 4 libraries + sympy should create much of what most people use Mathematica for, as far as the engine is concerned (e.g. sympy being a library). Modules like pydy, quantum and geometric algebra add a lot of added value to SymPy, that Mathematica doesn't have (at least not yet). Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
