About Me

Basic Information :

Name : Isuru Fernando

Email : [email protected]

Github : isuruf

Timezone : UTC + 0530

University : University of Moratuwa, Sri Lanka

Personal Background :

I am a 3rd year undergraduate of Department of Computer Science and Engineering at University of Moratuwa. I am currently doing a 6 month internship at WSO2 Inc, an open source organization also involved in this year's Google Summer of Code and will complete it in mid April.

I have been programming for about 3 years now. I started with C and have used Java and Mathematica for programming competitions and undergraduate courses. Thilina introduced me to CSymPy last July, and I have been contributing to CSymPy ever since. I learned a lot from contributing to CSymPy including C++ and Python which I had used occasionally and learnt Cython as well. The operating system I use is Ubuntu 14.04 and use gedit as the editor to code for CSymPy and now use PyCharm to edit code for Sage. I have been using sage for 4 months now.

Patch Requirement

I have made 29 Pull Requests to CSymPy out of which 28 were merged. See here. Among them include Cwrappers, ntheory, cmake, expand, type_code, benchmarks, travis and python wrappers.

Project: CSymPy - Make Sage use CSymPy as a symbolic engine

Introduction

Sage uses Pynac as its main symbolic engine and also uses SymPy and Maxima for symbolic manipulation. The goal of this project is to integrate CSymPy into Sage. CSymPy is a fast symbolic manipulation library written in C++. It depends only on GMP library for integer arithmetic (Optionally Arb library for arbitrary precision evaluations) and uses cmake as its build tool.

The reason for including CSymPy in Sage is that it is much faster than what is already there at Sage. Several benchmarks from http://wiki.sagemath.org/symbench are run on CSymPy and compared against Sage and SymPy. See, here. As seen from the timings CSymPy is 6 times or more faster in all of the benchmarks tested.

A big long term goal for CSymPy is to become the default symbolic manipulation engine of Sage. Currently, CSymPy lacks some of the functionality of Pynac. With this project, when CSymPy is integrated into Sage, the functionality lacking in CSymPy can be identified and then those could be implemented in it.

An advantage of CSymPy is that it is actively developed by a number of developers and currently has wrappers for Python and C. Hopefully, by the end of the summer, Sage, Ruby and Julia. This will bring in a large number of users and developers.

Goals.

Make an optional spkg package for CSymPy

First, existing CMake experimental spkg package has to be updated. CSymPy requires CMake version >= 2.8. Current experimental package's version is 2.4. There was interest into getting CMake into Sage and some standard packages stopped moving in to CMake as it was in experimental packages and not building in supported platforms. Getting CMake into Sage can help a number of packages including CSymPy.

Next step would be to implement _sage_ methods in CSymPy Python wrappers. These methods would convert CSymPy objects into Sage/Pynac.

These steps can make CSymPy be used in Sage python shell (Sage integer wraps integer literals with Integer(), so conversion from Sage Integer to CSymPy Integer is needed) and then converted into Sage's objects for further processing. For full interoperability, a csympy_converter in Sage has to be implemented to convert from Sage/Pynac to CSymPy.

Make CSymPy accept arbitrary Python objects

Conversion to and from Sage is necessary for all types supported by CSymPy as it would benefit from the performance of the algorithms in CSymPy for symbolic manipulation. Sage types not supported by CSymPy has to interact with the CSymPy types. To do this, I will follow Pynac. A new Number class (PyNumber) will be introduced. PyNumber class would accept CommutativeRingElement objects and use Python/C API to call Python operators from within the C++ library and also convert CSymPy Number types to Python objects for automatic simplification.

Although not a goal of this project, PyNumber class will also be useful for SymPy as currently only supported types are converted into CSymPy from SymPy. This would open the path to use CSymPy as the core of SymPy and will benefit from CSymPy's speed.

I recently implemented a FunctionWrapper class take in any SymPy function Python object. This class needs to be improved to be used as a wrapper for Sage Function

Figure out how to make CSymPy interact with other packages without conversion and start work

Making CSymPy interact with other packages without conversion is a big long-term goal for the CSymPy project. A goal of this GSoC project would be to start having some basic functionality so that this work could be continued after the GSoC project. As a start Sage Function will be modified to use CSymPy optionally. (At the moment Sage Functions returns a Pynac object)

Implement missing methods in CSymPy

CSymPy is missing a lot of functions that needs to be included. Some functions that needs to be implemented are as_real_imag to get a tuple of real part and imaginary part, free_symbols to return the symbols that the expression depends on and Infinities classes.

TimeLine

• Week 1

  • Update cmake spkg package and implement _sage_ methods in CSymPy Python wrappers for conversion from CSymPy to Sage/Pynac

    Current version of CMake experimental package does not build on Ubuntu 14.04 and needs a patch to the source to make it work. Since CSymPy requires 2.8+, CMake will be updated and then try to move it into the optional packages after verifying it builds on all platforms.

    Pynac uses Sage's Integer class, Rational class etc. which uses GMP under the hood. Since CSymPy also uses GMP for CSymPy::Integers, CSymPy::Rationals, CSymPy::Complex etc, conversion would copy the GMP type from CSymPy's objects.

• Week 2

  • csympy_converter in Sage to convert from Sage/Pynac to CSymPy.

    Like in _sage_ methods in CSymPy, these would copy the GMP type from Sage objects to CSymPy objects. Expressions will be made from scratch using basic arithmetic operators as the internal representations may differ.

• Week 3

  • Make sure CSymPy builds on all fully supported operating systems.

    CSymPy is tested on Linux at the moment. There were printing test failures in OS X and these will be fixed. If possible, automated tests on Travis will be configured to run on OS X as well. Also any build failures for other supported operating systems will be fixed.

• Week 4, 5

  • Implement PyNumber class to handle python objects of type CommutativeRingElement

    This class would use the Python operators and convert CSymPy Integers, Rationals, Complex Numbers to Sage types and would result in a PyNumber class itself.

• Week 6, 7

  • Use MPFR for evaluations and handle conversions

    Currently CSymPy supports eval_double and eval_arb for evaluations. Since Arb is optional at the moment, eval_mpfr will be implemented for evaluations. Conversions would be added for MPFR as well.

• Week 8, 9

  • Improve the CSymPy::FunctionWrapper class to handle Sage's Functions.

    Currently the FunctionWrapper takes in a Function object and does operations. Disadvantage of this option is that subs results in a Subs object. Instead of this, a pointer to the function would be used. Also, an option will be given to Sage's Function to choose CSymPy or GiNaC.

• Week 10, 11, 12

  • Implement some missing methods in CSymPy.

    • as_real_imag - To separate the expression to real and imaginary parts

    • free_symbols - Get the symbols that the expression depends on and Infinities classes.

    • Infinity - Special constants to handle positive and negative infinity

    • Floor, Ceiling - Classes to keep the Floor and Ceiling symbolically

    • trig_expand - Expand trig expressions. (This is provided via Maxima at the moment in Sage)

    • Rebuild expression from args

    • evaluate=False for all classes and doit() - This would disable automatic simplifications and do it would do the automatic simplifications. (This is provided via Maxima at the moment in Sage)