Hi, Just to better understand the goal, is the goal to do the symbolic derivative faster, to have a faster execution of the final function? Both?
thanks Fred On Tue, Sep 17, 2013 at 11:07 PM, Matthew Rocklin <[email protected]>wrote: > Awesome. I look forward to hearing more about it. > > What is your vision for SymPy/CSymPy interoperation? > > > On Tue, Sep 17, 2013 at 3:09 PM, Ondřej Čertík <[email protected]>wrote: > >> Hi, >> >> I'd like to announce CSymPy: >> >> https://github.com/certik/csympy >> >> a fast symbolic manipulation library written in C++. >> The goal is to eventually be the fastest symbolic manipulation library. >> So far it can only do basic arithmetic, arbitrary size integer/rational >> numbers, expansion, basic substitution and differentiation, basic >> implementation >> of sin/cos. It's written in >> C++ as a standalone library, with the goal of being usable from >> multiple languages and environments. It has optional very thin Python >> wrappers and conversion to/from SymPy. The license is MIT. >> >> There are some synthetic benchmarks in the benchmarks directory, >> you can run them against GiNaC, Sage and Mathematica. One has >> to understand that these synthetic benchmarks don't necessarily show >> that one software is faster than other, but it's some indicator. >> On these benchmarks, CSymPy seems to be faster than GiNaC >> (on some of them maybe by 50% or so). It seems faster than current Sage >> (e.g. sometimes 7x or more). On some it is a bit faster than Mathematica, >> but on some other ones not yet. >> >> Another issue of course is to use specialized datastructures and >> algorithms, for example for expansion of polynomials with integer >> coefficients ---- Sage uses Singular for that, CSymPy currently my own >> implementation of sparse polynomial multiplication (which does seem to >> be a bit faster than Singular for one specific benchmark), see >> benchmarks/expand2b* ---- but neither Sage nor Mathematica currently >> use these specialized algorithms by default. And of course many times >> you have symbolic exponents, so you can't use sparse polynomial >> representation. >> >> There is high value in using just one language. For example, SymPy has >> benefited greatly from only using Python (so that one does not have to >> worry >> about multiple languages like C, Cython, ...). Similarly, CSymPy is only >> using >> C++. In order to use it from Python, there are optional Cython wrappers: >> >> https://github.com/certik/csympy/blob/master/csympy/lib/csympy_wrapper.pyx >> >> as you can see, they are very thin and simple --- pretty much they just >> provide >> a better, more natural syntax to the C++ library. I expect that later >> people will >> provide interfaces to other languages/environments as well (like Julia, >> Ruby, >> Mathematica, ...). >> >> Compared to Python, C++ is a complex language. However, it is currently >> the >> only tool, that allows to have bare metal speed, yet reasonably high >> level syntax. >> For example, the implementation of expansion of things like >> (x+y+z+...)*(a+b+c) >> is between these two lines (e.g. less than 30 lines): >> >> >> https://github.com/certik/csympy/blob/5a4d1aabdb565b427ab8585d3737cb4901001e57/src/mul.cpp#L285 >> >> https://github.com/certik/csympy/blob/5a4d1aabdb565b427ab8585d3737cb4901001e57/src/mul.cpp#L313 >> >> you need to loop over the two parentheses, multiply things out and >> construct the final >> Add instance. In SymPy, the implementation starts here: >> >> >> https://github.com/sympy/sympy/blob/8f56ea59ec4737b35166dd8fb799782664905709/sympy/core/mul.py#L691 >> >> it is implemented by the _expandsums() and _eval_expand_mul() methods. >> >> Overall compared to Python, it is slower to implement things in C++, >> but the speed is great, and one can tweak low level details like >> memory allocators (essential for small objects like in CSymPy), have >> automatic reference counted pointers, tweak hash functions and >> hashmaps (dictionaries) implementation, implement your own high level >> types/classes that are easy to use yet as fast as C, etc. >> >> The idea is that if speed is not very important (most applications of >> SymPy), then SymPy is the answer. However, if speed is important, for >> things like handling long expressions (sympy.mechanics, quantum field >> theory, various perturbation methods, ...), maybe some finite element >> applications (that use symbolic mathematics on the fly) or having a >> public server powered by sympy (depending on application), etc., then >> it is essential to squeeze every bit of performance. Then CSymPy is >> the answer. >> >> I am now looking for people who suffer because SymPy is too slow, who >> would be interested in collaboration. I've been in touch with the >> sympy mechanics guys and I've also written to some of you to test it >> out. And I know there are many more people. I am happy to concentrate >> on implementing whatever needs to be done. Some things on my todo list >> is to speedup the implementation of differentiation/substitution and >> also implement fast pattern matching. But if somebody needs something >> else, I'll be happy to work with you. At the moment, I don't plan to >> implement the whole sympy, only things which people need to be as fast >> as possible --- let me know. >> >> If you discover any bugs, please report it to github issues at >> https://github.com/certik/csympy. >> >> 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. >> For more options, visit https://groups.google.com/groups/opt_out. >> > > -- > 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. > For more options, visit https://groups.google.com/groups/opt_out. > -- 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. For more options, visit https://groups.google.com/groups/opt_out.
