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.
