I too feel that csympy should implement the absolute minimum possible for it to be fast. All actual mathematical algorithms should remain in sympy. Trying to pull lots of algorithms into csympy will fail - not that many people want to write complex mathematical algorithms in C++.
On Tue, Apr 22, 2014 at 5:06 PM, Aaron Meurer <[email protected]> wrote: > On Tue, Apr 22, 2014 at 12:05 PM, Ondřej Čertík <[email protected]> > wrote: >> 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. > > I think that's already too much. Why is the series expansion slow in > SymPy? Is it because the algorithms are slow? If so, then implementing > the same inefficient algorithms in CSymPy won't help. They will be > faster, but for large enough expressions they will still slow down. Is > it because the expression manipulation is slow? In that case, if > CSymPy has faster expression manipulation, then just use those > expressions, but use the SymPy series algorithms. > > My points are: > > - I think CSymPy should focus on making expression manipulation fast > (i.e., the things that are the inner loop of any symbolic algorithm). > It should not reimplement the symbolic algorithms themselves. Those > are implemented in SymPy. If they use the CSymPy objects instead of > the SymPy objects, they will be faster. > > - I would focus more on making CSymPy interoperate with SymPy and less > on reimplementing things that are in SymPy in CSymPy. Once there is > interoperation, we can see what is still slow, and then (and only > then) implement it in C++. > >> >>> >>> - 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. > > Why do you need to implement those in C++? If the expression > manipulation is fast, then won't it be fine to have the actual > formulas/algorithms in SymPy? > >> 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. > > It's more than just args. Every SymPy object is expected to have all > the methods of Basic. > > Aaron Meurer > >> >> 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. > > -- > 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/CAKgW%3D6%2BoyvxqYS-cj8vcrr%3DukBYZRssXJ6WEFOxfhd%2BKGm0aMg%40mail.gmail.com. > For more options, visit https://groups.google.com/d/optout. -- Brian E. Granger Cal Poly State University, San Luis Obispo [email protected] and [email protected] -- 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/CAH4pYpQUF5fj9HyHKPR%3DG_TnSOhxdKTpXbn1HGyWtbyvBqVgmA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
