GSoC Idea: Make Sage use CSymPy as the symbolic engine

[Ondřej Čertík]

Hi,

Thanks Harald for inviting us (in SymPy) to participate under Sage
this year. One big goal is to make Sage use CSymPy
(https://github.com/sympy/csympy) as the main symbolic engine instead
of Pynac. CSymPy is written in C++ with optional Python wrappers. The
motivation is simple, it is much faster, e.g.:

certik@redhawk:~/repos/csympy/benchmarks(master)$ sage legendre1_sage.py
import...
done.
0 1
1 x
2 3/2*x^2 - 1/2
3 5/2*x^3 - 3/2*x
4 35/8*x^4 - 15/4*x^2 + 3/8
5 63/8*x^5 - 35/4*x^3 + 15/8*x
6 231/16*x^6 - 315/16*x^4 + 105/16*x^2 - 5/16
7 429/16*x^7 - 693/16*x^5 + 315/16*x^3 - 35/16*x
8 6435/128*x^8 - 3003/32*x^6 + 3465/64*x^4 - 315/32*x^2 + 35/128
9 12155/128*x^9 - 6435/32*x^7 + 9009/64*x^5 - 1155/32*x^3 + 315/128*x
Total time for legendre(500, x): 7.2570168972 s
certik@redhawk:~/repos/csympy/benchmarks(master)$ python legendre1.py
0 1
1 x
2 -1/2 + 3/2*x**2
3 5/2*x**3 + -3/2*x
4 3/8 + -15/4*x**2 + 35/8*x**4
5 63/8*x**5 + 15/8*x + -35/4*x**3
6 -5/16 + 105/16*x**2 + 231/16*x**6 + -315/16*x**4
7 -693/16*x**5 + 429/16*x**7 + 315/16*x**3 + -35/16*x
8 35/128 + -315/32*x**2 + -3003/32*x**6 + 3465/64*x**4 + 6435/128*x**8
9 12155/128*x**9 + -6435/32*x**7 + 315/128*x + -1155/32*x**3 + 9009/64*x**5
Total time for legendre(500, x): 0.983409166336 s

You can check that the symbolic code is equivalent, it just evaluates
the Rodrigues' formula (obviously this is not the fastest way to get
Legendre polynomials, it's just for benchmarking general symbolic
code).

You can run more benchmarks yourself
(https://github.com/sympy/csympy/tree/master/benchmarks).

And CSymPy's community is much more active than GiNaC, e.g. compare
GiNaC and SymPy for the last year:

csympy$ git shortlog -ns --since="1 year ago"
336 Ondřej Čertík
271 Thilina Bandara Rathnayake
238 Sushant Hiray
109 Isuru Fernando
10 Peter Brady
9 Shivam Vats
4 Sumith
3 Thomas Hisch
1 Vinzent Steinberg

ginac$ git shortlog -ns --since="1 year ago"
6 Richard Kreckel
6 Vladimir V. Kisil
5 Alexei Sheplyakov
3 Stefan Weinzierl


and even all time (CSymPy from 2012, GiNaC from 1999) is really quite
comparable:

csympy$ git shortlog -ns
1039 Ondřej Čertík
338 Thilina Bandara Rathnayake
238 Sushant Hiray
109 Isuru Fernando
10 Peter Brady
9 Shivam Vats
5 Dale Lukas Peterson
4 Sumith
3 Thomas Hisch
1 Christopher Dembia
1 Julien Rioux
1 Vinzent Steinberg


ginac$ git shortlog -ns
669 Richard Kreckel
650 Christian Bauer
279 Jens Vollinga
201 Alexei Sheplyakov
66 Chris Dams
32 Alexander Frink
20 Vladimir V. Kisil
9 Stefan Weinzierl
7 Jan Rheinländer
7 Richard B. Kreckel
3 welzel
1 Matthias Dellweg
1 Paul Irofti



Pynac itself also doesn't seem to be very active:
http://hg.pynac.org/pynac/commits/all

Compared to GiNaC, CSymPy is missing specialized polynomial
manipulation and series expansion (we are working on both now) and
pattern matching (we also plan to do it soon), hopefully as other
GSoC projects.


I was thinking that a GSoC project could:

* Write Sage wrappers (the SymPy wrappers are already done and we can
have arbitrary sympy expression as an object in the C++ expression
tree), so most of this work is done --- then anybody in Sage can
easily try it out

* Figure out what needs to be done to hook it up just like Pynac is
(this might be quite a bit of work, hopefully it's manageable)

* Identify what features in CSymPy are still missing (and start
implementing those)

At the end of the summer I don't expect Sage to be switched, but I
think there could be a clear path forward, and it should be possible
to use it as an optional package in Sage, side by side, with good
interoperability. People can try it out, provide feedback, etc., which
would provide further motivation for us to finish it up and so on.

I was hoping to propose this project after we have all the features
already in there, but since SymPy didn't get accepted as an
organization this year, this GSoC project would really help us out,
and I think this is equally beneficial to both Sage and SymPy. We have
students that can apply for this. Let me know what you think, I'll be
happy to help them with the application and look at more details.

Ondrej

[William Stein]

Hi Ondrej,

For GSoC some important points are the following.

1. Regarding " One big goal is to make Sage use CSymPy

(https://github.com/sympy/csympy) as the main symbolic engine instead

of Pynac." I would be more comfortable if you rephrase this to "One
big *longterm* goal is to make it possible for Sage to use CSymPy

(https://github.com/sympy/csympy) as the main symbolic engine instead

of Pynac." In particular, this shouldn't be a goal for this GSoC,
since it's a fulltime 1-year project, at least.

2. Make another goal be to reduce the reliance of Sage on Maxima, with
a longterm goal to remove that reliance. (Simplification, Taylor
series, Symbolic integration, etc.)

3. Regarding: "At the end of the summer I don't expect Sage to be

switched, but I think there could be a clear path forward, and it
should be possible to use it as an optional package in Sage, side by

side, with good interoperability." I think this is realistic and
should be emphasized. Moreover, why not have CSymPy be in Sage by
default (not just an optional package)?


-- William

--
William (http://wstein.org)

[Ondřej Čertík]

Hi William,

On Wed, Mar 4, 2015 at 8:17 AM, William Stein <wst...@gmail.com> wrote:
> Hi Ondrej,
>
> For GSoC some important points are the following.
>
> 1. Regarding " One big goal is to make Sage use CSymPy
> (https://github.com/sympy/csympy) as the main symbolic engine instead
> of Pynac." I would be more comfortable if you rephrase this to "One
> big *longterm* goal is to make it possible for Sage to use CSymPy
> (https://github.com/sympy/csympy) as the main symbolic engine instead
> of Pynac." In particular, this shouldn't be a goal for this GSoC,
> since it's a fulltime 1-year project, at least.

100% agree.

>
> 2. Make another goal be to reduce the reliance of Sage on Maxima, with
> a longterm goal to remove that reliance. (Simplification, Taylor
> series, Symbolic integration, etc.)

Agree.

>
> 3. Regarding: "At the end of the summer I don't expect Sage to be
> switched, but I think there could be a clear path forward, and it
> should be possible to use it as an optional package in Sage, side by
> side, with good interoperability." I think this is realistic and
> should be emphasized. Moreover, why not have CSymPy be in Sage by
> default (not just an optional package)?

That would be great. I would start with an optional package, make sure
it works for people and there is interest in having it as default, and
then propose it as default.

I am going to put it here: http://wiki.sagemath.org/GSoC/2015#Project_Ideas

Ondrej

[Ondřej Čertík]

On Wed, Mar 4, 2015 at 9:36 AM, Ondřej Čertík <ondrej...@gmail.com> wrote:
> I am going to put it here: http://wiki.sagemath.org/GSoC/2015#Project_Ideas

Done:

http://wiki.sagemath.org/GSoC/2015#Make_Sage_use_CSymPy_as_the_symbolic_engine

Ondrej