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 sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to