Le lundi 02 mai 2011 à 15:02 -0600, Aaron S. Meurer a écrit : > 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." > I think there are things to clarify and discuss.
> "… for symbolic mathematics. It aims to become a full-featured computer > algebra system (CAS)…"" > Before discussing the intended interpretation of this, I'll note that "symbolic mathematics" seems too restrictive: I wouldn't say that code generation, quantum logic or statistics are part of this. "Symbolic computation" would be more fitting. Also, "CAS" is ambiguous. Does this mean something like Mathematica, like Maxima or like GiNaC? > 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. > I see a contradiction here. A library for symbolic manipulation and a CAS like Maple or Mathematica are very different things. It feels rather like saying "SymPy is a combustion engine. It aims to become a full-featured car." All the GSoC projects fit with the symbolic library idea, less so with the CAS idea - I wouldn't expect to find quantum mechanics inside Maple or Mathematica but rather in an extension module. Maybe a distinction needs to be made between sympy-the-library and SymPy-the-organisation. Something along the lines of: the core goal of Sympy-the-organisation is to build a full-featured CAS, its main project is sympy-the-library. > 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). Well, mpmath isn't part of sympy and you've said yourself that the plotting back-end should be unbundled. And we're not actively trying to build a CAS (besides the rather basic one that isympy is). If we were, we would be focusing on coding something like, say, Spyder. So our actions aren't really consistent with the stated goal. And the statement ignores the fact that a Python CAS can basically not exist without ipython, numpy, matplotlib, etc. , which contradicts the last point. > "… 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. Using Python doesn't guarantee that the code is readable. The question here is how much this should matter compared to other considerations such as speed in CPython or Cython. > "SymPy is written entirely in Python and does not require any external > libraries." This isn't a goal, just a statement of fact. I think the actual goal is something like "being usable everywhere a Python interpreter is available". > 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. Being pure Python is important, I agree. > > 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 think this is strategically wrong. It negates our only real advantage in the competition with Mathematica or Maple: the Python ecosystem. In the use case you mention, it would take a grand total of 3 commands to install sympy with however many dependencies it might have: ~$ python virtualenv.py myenv ~$ source myenv/bin/activate ~$ pip install sympy Having dependencies has drawbacks, but sparing some users from typing 3 commands shouldn't factor into the decision. -- 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.
