GSoC 2015 - Community Bonding Period

I've been accepted to Google Summer of Code 2015 to integrate CSymPy into SageMath by the mentoring organization, Python Software Foundation.

Here's the abstract about the GSoC project

CSymPy is a fast symbolic manipulation library written in C++. Sage uses Pynac as its main symbolic engine. csympy is much faster than what is already there at Sage. Several benchmarks from http://wiki.sagemath.org/symbench run on csympy suggests that csympy is 6 times or more faster. A big long term goal would be to have csympy become the default symbolic manipulation engine of sage and this GSoC project proposes to have it as an alternative symbolic manipulation engine for sage

Full GSoC application with the timeline can be found here

Updates on the GSoC project will be posted in this blog under GSoC

CSymPy was renamed to SymEngine.

CSymPy started out as a experimental core for SymPy written in C++, hence the name CSymPy. Another GSoC project is setting up wrappers to use csympy from Ruby which has nothing to do with Python. A new name SymEngine was proposed and the C++ library was changed to it while keeping the name CSymPy for the Python wrappers.


Getting CMake into Sage

SymEngine uses cmake as its build tool, but unlike autotools, cmake needs to be there at configure time, not at packaging. Therefore Sage needs to contain cmake to build symengine. I made a ticket at http://trac.sagemath.org/ticket/18078 to get cmake into sage. cmake builds fine on Linux with only 3 tests failing (all of them about curl, which is not needed for symengine), but fails to build on Mac OS X. Ondrej has some experience on building cmake on OS X due to his work in Hashdist and we will try to get it working next week as GSoC starts.


Floating point support in SymEngine

SymEngine had support only for integers, rationals and gaussian rationals. I'm going to add support for floating point values with RealDouble as default (for double precision values) and RealMPFR as an optional class if MPFR library is installed for arbitrary precision floating point values. RealDouble was implemented two weeks ago and RealMPFR will be implemented soon. (There's also a plan to have a RealArb class to use arb library for floating point calculations). Link to PR

Automatic evaluations for functions when the argument is not an exact value (like RealDouble) was added last week. Now sin(pi/2 - 0.0) will return 1.00000000 automatically without the need to call eval_double to evaluate numerically. Link to PR

SymEngine keeps expressions as it is without losing the precision. For example, sqrt(2) is kept as it is without approximating it as a double. Therefore to get a numerical value, we need to evaluate it as a double. SymEngine had a function eval_double to evaluate and get the value as a double, but lacked the functionality evaluate complex numbers. This feature was added last week as well. Link to PR

In the coming weeks, to complete the floating point support in SymEngine,

• Add a ComplexDouble class to store std::complex<double>
• Add evaluate_mpfr method to evaluate using mpfr library
• Add a RealMPFR class to store a mpfr_t value
• Interface MPC library to support arbitrary precision complex floating point values.