Hi Aaron, Those are good questions. Here are the answers:
On Tue, Apr 22, 2014 at 10:13 AM, Aaron Meurer <[email protected]> wrote: > I have some high level questions about CSymPy. > > - What are the goals of the project? The goals of the project are: * Fastest symbolic manipulation library, compared to other codes, commercial or opensource (Sage, GiNaC, Mathematica, ...). * Extension/complement to SymPy * If the above two goals allow, be able to also call it from other languages easily and efficiently (Julia, Ruby, Mathematica, ...) As to technical solution: the core should be a C++ library, which can depend on other compiled libraries if needed. The core should not depend on Python or Ruby or Julia, but rather be just one language, C++. That lowers the barrier of entry significantly, compared to a big mix of C++, Cython and Python, makes it easier to make things fast (you don't need to worry about Python at all). The Python (and other languages) wrappers should be just a thin wrappers around the C++ core (=just better syntax). There might be other technical solutions to this, but I know that I can deliver the above goals with this solution (and I failed to deliver with other solutions, like writing the core in Cython). So that's why we do it this way. Also, by being "just a C++ library", other people can use it in their projects. I hope to get interest of much broader community that way, who can contribute back (somebody will need fast symbolic manipulation in Julia, so they can just use CSymPy with Julia wrappers, and contribute improvements back). > > - What are the things that should definitely go in CSymPy? At the moment: all things to make specific applications fast, in particular PyDy. For that, it needs basic manipulation, differentiation, series expansion (I think) and matrices. That's all roughly either done, or on the way. Of course, lots of polishing is needed. > > - What are the things that should definitely not go in CSymPy? Things that don't need to be fast. Things like limits. Also things that are in SymPy, where CSymPy can be used as a drop in replacement for the engine: PyDy, some stuff in physics, and so on. There is no need to rewrite PyDy in C++. Also most user's code would stay in Python. They can just optionally change to CSymPy for some intensive calculation, then finish the thing with SymPy. > > - How will CSymPy be architectured to allow things to happen in CSymPy > when they can but fallback to SymPy when they cannot. Currently you can simply mix and match SymPy and CSymPy expressions. So you simply convert an expression to SymPy to do some advanced manipulation, and convert to CSymPy to do some fast manipulation. I am open to suggestions how to improve this. > > My main concern here is that CSymPy has not clear separation from > SymPy, and as a result it will end up growing larger and larger, until > it becomes an independent CAS (which is fine if that's the goal, but > my understanding was that it was supposed to be just a small fast > core). The goals are written above. I am myself concentrating on speed, that's what I really want to nail down. And then enough features so that it's useful for all the people who found SymPy slow. However, let's say somebody comes and reimplements the Gruntz algorithm in CSymPy. Should we reject such a PR? My answer is that if the code is nice, maintainable, much faster than SymPy and has the same or similar features, I am ok with merging it. If the code is a mess, then not. But as I said, I am spending my own time on things which people need, and faster limits don't seem to be it. > > In particular, if there is some feature of SymPy functions, how will > CSymPy be architectured so that it can take advantage of it without > having to completely reimplement that function in C++? You can convert any expression back and forth, so you keep it in SymPy if you want to have some particular feature. See also the conversation and specific examples here: https://github.com/sympy/csympy/issues/153 > > For instance, a current goal of CSymPy is to implement trig functions. > But this can be quite complicated if you consider all the different > things you can do with trig functions. Without even thinking about > trig simplification, there are complicated evaluation issues (e.g., > consider sin(pi/7).rewrite(sqrt) in SymPy). It would be a shame to > reimplement all this logic twice, especially it is not needed for > performance. Agreed. On the other hand, we really need very fast trig functions. The functionality that we need is simplifications like sin(2*pi) -> 0, differentiation and series expansion. This is needed for applications like PyDy. Those are not difficult to implement. Things which get tricky are then the advanced simplifications and rewriting. But those I would do in SymPy, because as you said, those are typically not needed for performance. > > Finally, I noticed that the CSymPy Python API doesn't adhere to SymPy > standards, e.g., it doesn't use .args. I think a first step in this > direction would be to make all CSymPy objects completely compatible > with SymPy. Probably a good idea would be to mixin Basic to all CSymPy > classes (is this possible?). The .args are not implemented yet in the Python wrappers, so I just created an issue for it: https://github.com/sympy/csympy/issues/162 I don't know if it's possible to mix Basic, but either way the wrappers should be compatible. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CADDwiVD_RBVi6GnAHd59OgcuQ4eJUPYK1jqASmFoosUG2uc3wQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
