GSoC 2014 Ideas

Frédéric Bastien edited this page Mar 6, 2014 · 42 revisions

GSoC 2014 Project Ideas

Note: This page has not yet been updated to remove those ideas that have already been implemented. Please ask on our mailing list if you are unsure.

This is the list of ideas for students wishing to apply for Google Summer of Code 2014. For more information on how to apply, see GSoC-2014-Application-Template.

This is for inspiration, you can apply with something completely different if you like. The best project for you is one you are interested in, and are knowledgeable about. That way, you will be the most successful in your project and have the most fun doing it, while we will be the most confident in your commitment and your ability to complete it.

If you do want to suggest your own idea, please discuss it with us first, so we can determine if it is already been implemented, if it is enough work to constitute a Summer's worth of coding, if it is not too much work, and if it is within the scope of our project.

Even if you want to do an idea listed here, you should still contact us on our mailing list and discuss it with us. Also take a look at our application template.

Please always ask on our mailing list about these ideas to get the latest information about what is implemented and what exactly has to be done.

The list is organized as follows:

  1. "High Priority" - projects that are considered important in our roadmap.
  2. "Detailed Projects: Mathematics" - well developed ideas of interest for us, however they do not block the release of the next major version of SymPy. These require deep understanding of the mathematics in question.
  3. "Detailed Projects: Physics" - well developed ideas of interest for us, however they do not block the release of the next major version of SymPy. A number of well developed modules dealing with classical and quantum physics are being developed as part of SymPy.
  4. "Detailed Projects: Computer Science, GUIs, Graphics, Infrastructure" - well developed ideas of interest for us, however they do not block the release of the next major version of SymPy. These projects do not necessitate deep understanding of math. Nonetheless they are just as challenging.
  5. "Ideas" - list in a "brainstorming" style that has many nice project ideas. Each "Detailed Projects" entry was born in this list. Read it carefully as the most interesting projects may come from there.

The order of ideas in this list has no bearing to the chances of an idea to be accepted. All of them are equally good and your chances depend on the quality of your application. As already said, you can very well submit your own idea not listed here.

Table of Contents

  • High Priority
    • Assumptions
  • Detailed Projects: Mathematics
    • Solvers
    • Group theory
    • Risch algorithm for symbolic integration
    • Ordinary Differential Equations
    • Series expansions
    • Cylindrical algebraic decomposition
    • Polynomials module
      • Efficient Groebner bases and their applications
      • Multivariate polynomials and factorization
      • Univariate polynomials over algebraic domains
    • Concrete module: Implement Karr algorithm, a decision procedure for symbolic summation
    • Linear Algebra: Tensor core
    • Stepbystep Expression Manipulation
  • Detailed subprojects in Physics
    • Symbolic quantum mechanics (sympy.physics.quantum)
      • Abstract Dirac notation
      • Implement All Known Analytical Solutions to Quantum Mechanical Systems
      • Position and momentum basis functions
      • Symbolic quantum computing
      • Second quantization capabilities
    • Symbolic classical mechanics in SymPy (sympy.physics.mechanics)
  • Detailed subprojects in Computer Science, Infrastructure, GUIs and Graphics
    • SymPy subprojects related to GUIs and user interaction
      • SymPy Live and SymPy Gamma (on Google App Engine)
    • Parsing
    • Improve the plotting module
    • Benchmarks
  • Other Related Projets
  • Ideas

High Priority

Assumptions

Possible mentors: Aaron Meurer, Ondřej Čertík.

The project is to completely remove our old assumptions system, replacing it with the new one.

The difference between the two systems is outlined in the first two sections of this blog post. A list of detailed issues can be found at this issue.

This project is challenging. It requires deep understanding of the core of SymPy, basic logical inference, excellent code organization, and attention to performance. It is also very important and of high value to the SymPy community.

You should take a look at the work started at https://github.com/sympy/sympy/pull/2508.

Numerous related tasks are mentioned in the "Ideas" section.

Detailed Projects: Mathematics

Solvers

SymPy already has a pretty powerful solve function, but the interface is a bit of a mess (see https://code.google.com/p/sympy/issues/detail?id=3560).

There are some things that could be done in the solvers:

  • Refactor the code to use a hints system similar to the ODE module.

  • Try to clean up the public API. The functions for solving linear systems in particular are messy.

  • Try to make the output of solve() more consistent. Right now you have to pass dict=True if you want the same output type regardless of the input.

  • Related to the previous point, support infinite solutions.

  • Create an unevaluated Solve object, for solutions that cannot be found exactly. How could you unambiguously represent a specific solution (and not any others)? This would be similar to RootOf, except for a more general set of equations.

  • solve needs some way to say that it knows that it has found all the solutions to an equation or system of equations. Right now, there are no guarantees whatsoever about how many solutions solve has found, only that the ones that it does find are correct. But in many cases it can know that it has found all of them (univariate polynomials are a simple example of this). This sort of thing would be useful for many other things. For instance, a function that tries to find the maximum or minimum of a function via critical points would require this because it would need to be sure that it hasn't missed any solutions.

  • You could also implement more solvers for equations that can't be solved along the way. The ability to represent infinitely many solutions in particular will open many possibilities for new solvers.

This project is difficult because it requires a good deal of thought in the application period. You should have a clear plan of most of what you plan to do in your application: waiting until the Summer to do the designing will not work.

Group theory

Implement a module to work with groups. You should take a look at the GAP library, as this is the canonical group theory computation system right now. Some things to think about:

  • How do you represent a group?
  • How do you represent the elements of a group?
  • Can we support both finite and infinite groups?
  • Can we support defining groups by generators?

Algorithms to think about implementing:

  • Computation of subgroups of various types (e.g., normal subgroups).
  • Computation of Galois groups for a given polynomial.

Also take a look at the Permutation class already implemented in SymPy.

Some work is already done on discrete groups. Nonetheless there is still much that can be done both for discrete groups and for Lie groups.

Risch algorithm for symbolic integration

  • The project is to continue where Aaron Meurer left off in his 2010 GSoC project, implementing the algorithm from Manuel Bronstein's book, Symbolic Integration I: Transcendental Functions. If you want to do this project, be sure to ask on the mailing list or our IRC channel to get the status of the current project.

  • Status The algorithm has already been partially implemented, but there is plenty of work remaining to do. Contact Aaron Meurer for more information. There was also work done in 2013, which hasn't been completely merged yet. A good place to start would be to look at finishing this work: https://github.com/sympy/sympy/pulls/cheatiiit.

  • Idea The Risch algorithm is a complete algorithm to integrate any elementary function. Given an elementary function, it will either produce an antiderivative, or prove that none exists. The algorithm described in Bronstein's book deals with transcendental functions (functions that do not have algebraic functions, so log(x) is transcendental, but sqrt(x) and sqrt(log(x)) are not).

  • Prerequisites You should have at least a semester's worth of knowledge in abstract algebra. Knowing more, especially about differential algebra, will be beneficial, as you will be starting from the middle of a project. Take a look at the first chapter of Bronstein's book (you should be able to read it for free via Google Books) and see how much of that you already know. If you are unsure, discuss this with Aaron Meurer.

Ordinary Differential Equations

Currently, SymPy only supports many basic types of differential equations, but there are plenty of methods that are not implemented. Maybe support for using Lie groups to help solve ODEs. See the ODE docs and the current source for information on what methods are currently implemented. Also, there is no support currently for solving systems of ODEs. You also might want to look at Manuel Bronstein's sumit.

  • Separation ansatz:

    • "A simple method to find out when an ordinary differential equation is separable" by José ́Ángel Cid
  • "Solving Differential Equations in Terms of Bessel Functions" by Ruben Debeerst.

  • Lie groups and symmetry related:

    • An implementation of these methods was done for first order ODEs during gsoc13. But we can do the same tricks for second order ODEs too.
    • "Computer Algebra Solving of First Order ODEs Using Symmetry Methods" by E.S. Cheb-Terrab, L.G.S. Duarte and L.A.C.P. da Mota. There is a short (15 pages) and an updated (24 pages) version of this paper.
    • "Computer Algebra Solving of Second Order ODEs Using Symmetry Methods" by E.S. Cheb-Terrab, L.G.S. Duarte, L.A.C.P. da Mota
    • "Integrating factors for second order ODEs" by E.S. Cheb-Terrab and A.D. Roche
    • "Symmetries and First Order ODE Patterns" by E.S. Cheb-Terrab and A.D. Roche
    • "Abel ODEs: Equivalence and Integrable Classes" by E.S. Cheb-Terrab and A.D. Roche Note: Original version (12 pages): July 1999. Revised version (31 pages): January 2000
    • "First order ODEs, Symmetries and Linear Transformations" by E.S. Cheb-Terrab and T. Kolokolnikov
    • "Non-Liouvillian solutions for second order linear ODEs" by L. Chan, E.S. Cheb-Terrab
    • And probably some more by these authors ...

Series expansions

This includes numerous smaller subprojects.

  • improve series expansions

  • formal power series

  • improve limits - make sure all basic limits work

    • limit of series
  • asymptotic series

  • Better support for Order term arithmetic (for example, expression of the order term of the series around a point that is not 0, like O((x - a)**3)).

  • All other problems, which are described in wiki page about series and current situation

  • Some references:

    • "Formal Power Series" by Dominik Gruntz and Wolfram Koepf
    • "A New Algorithm Computing for Asymptotic Series" by Dominik Gruntz
    • "Computing limits of Sequences" by Manuel Kauers
    • "Symbolic Asymptotics: Functions of Two Variables, Implicit Functions" by Bruno Savly and John Shackell
    • "Symbolic Asymptotics: Multiseries of Inverse Functions" by Bruno Savly and John Shackell

Cylindrical algebraic decomposition

  • Implement the Cylindrical algebraic decomposition algorithm

  • Use CAD to do quantifier elimination

  • Provide an interface for solving systems of polynomial inequalities

  • Some references:

Polynomials module

Efficient Groebner bases and their applications

  • Status: Groebner bases computation is one of the most important tools in computer algebra, which can be used for computing multivariate polynomial LCM and GCD, solving systems of polynomial equations, symbolic integration, simplification of rational expressions, etc. Currently there is an efficient version of Buchberger algorithm implemented and of the F5B algorithm, along with naive multivariate polynomial arithmetic in monomial form. There is also the FGLM algorithm converting reduced Groebner bases of zero-dimensional ideals from one ordering to another.
  • Idea: Improve efficiency of Groebner basis algorithm by using better selection strategy (e.g. sugar method) and implement Faugere F4 algorithm and analyze which approach is better in what contexts. Implement the generic Groebner walk converting between Groebner basis of finite-dimensional ideals; there are efficient algorithms for it, by Tran (2000) and Fukuda et al. (2005). Apply Groebner bases in integration of rational and transcendental functions and simplification of rational expressions modulo a polynomial ideal (e.g. trigonometric functions). Note: There was a project last year relating to Groebner bases. Please take a look a the source and discuss things with us to see what remains to be done. Second Note: Some Groebner bases algorithms, in particular F4, require strong linear algebra. Thus, if you want to do that, you may have to first improve our matrices (see the ideas relating to this above).
  • Rating: (very hard)

Multivariate polynomials and factorization

  • Status: Factorization of multivariate polynomials is an important tool in algebra systems, very useful by its own, also used in symbolic integration algorithms, simplification of expressions, partial fractions, etc. Currently multivariate factorization algorithm is based on Kronecker's method, which is impractical for real life problems. Undergo there is implementation of Wang's algorithm, the most widely used method for the task.
  • Idea: Start with implementing efficient multivariate polynomial arithmetic and GCD algorithm. You do this by improving existing code, which is based on recursive dense representation or implement new methods based on your research in the field. There are many interesting methods, like Yan's geobuckets or heap based algorithms (Monagan & Pearce). Having this, implement efficient GCD algorithm over integers, which is not a heuristic, e.g. Zippel's SPMOD, Musser's EZ-GCD, Wang's EEZ-GCD. Help with implementing Wang's EEZ factorization algorithm or implement your favorite method, e.g. Gao's partial differential equations approach. You can go further and extend all this to polynomials with coefficients in algebraic domains or implement efficient multivariate factorization over finite fields. Note: Some work on this may already be done. Take a look at sympy/polys/factortools.py in the SymPy source code.
  • Rating: (quite hard)

Univariate polynomials over algebraic domains

  • Status: Currently SymPy features efficient univariate polynomial arithmetic, GCD and factorization over Galois fields and integers (rationals). This is, however, insufficient in solving real life problems, and has limited use for symbolic integration and simplification algorithms.
  • Idea: Choose a univariate polynomial representation in which elements of algebraic domains will be efficiently encoded. By algebraic domains we mean algebraic numbers and algebraic function fields. Having a good representation, implement efficient arithmetic and GCD algorithm. You should refer to work due to Monagan, Pearce, van Hoeij et. al. Having this, implement your favorite algorithm for factorization over discussed domains. This will require algorithms for computing minimal polynomials (this can be done by using LLL or Groebner bases). You can also go ahead and do all this in multivariate case.
  • Rating: (quite hard)

Concrete module: Implement Karr algorithm, a decision procedure for symbolic summation

  • Status: SymPy currently features Gosper algorithm and some heuristics for computing sums of expressions. Special preference is for summations of hypergeometric type. It would be very convenient to support more classes of expressions, like (generalized) harmonic numbers etc. There is already an complete algorithm rational expression summation.

  • Idea: Algorithm due to Karr is the most powerful tool in the field of symbolic summation, which you will implement in SymPy. There are strong similarities between this method and Risch algorithm for the integration problem. You will start with implementing the indefinite case and later can extend it to support definite summation (see work due to Schneider and Kauers). Possibly you will also need to work on solving difference equations.

  • Rating: (very hard)

  • Some references:

    • "A=B" by Marko Petkovsek, Herbert S. Wilf, Doron Zeilberger
    • "Symbolic Summation with Radical Expressions" by Manuel Kauers and Carsten Schneider
    • "An Implementation of Karr's Summation Algorithm in Mathematica" by Carsten Schneider
    • Manuel Kauers, webpage: http://www.risc.jku.at/home/mkauers
    • Carsten Schneider, webpage: http://www.risc.jku.at/people/cschneid
    • "Algorithmen für mehrfache Summen", by Torsten Sprenger

Linear Algebra: Tensor core

  • Status: SymPy has a number of disconnected projects related to Tensor/Linear algebra. These include Matrices, Sparse Matrices, Matrix Expressions, Indexed (for code generation), Geometric Algebra, Differential Geometry, Tensor Canonicalization, and various projects in Physics.

  • Idea: Build a Tensor core that can serve as a base to connect these projects and others. This core should be able to seamlessly support a broad range of applications ranging from very abstract (vector spaces, geometry, multi-linear operators) to very numerical (explicit matrices, NumPy integration, code generation). This project should include both a general Tensor Expression class and a general refactoring of the existing code-base. See Linear-Algebra-Vision. This project requires experience both in abstract linear algebra and in good code organization.

Step-by-step Expression Visualization

Many times, people ask how they can tell what some functions are doing. For example, they want to know step by step how something like diff(x*sin(x**2), x) or integrate(x*sin(x**2), x) works. For the former, the best you can do is to follow the code; for the latter, the algorithm doesn't work at all like you would do it by hand, so there's really no way.

The idea is to implement a way to do this. It would be along the lines of WolframAlpha, where if you do certain operations (including the above two), there is a button "Show steps," which shows everything step by step.

Some questions:

  • What would be a good interface for this? For the most part, it would probably mean reimplementing the basic "by hand" algorithms, so that you can determine exactly what steps are used. Check out the "rewrite rules and strategies" submodule in SymPy.

  • What should the output look like, so that it is both readable and usable (e.g., maybe some kind of annotated objects representing operations that you can literally apply to an expression to do those things)?

  • For those operations where what SymPy does is pretty close to what you'd do by hand (e.g., differentiation), what is a good way to avoid code duplication and make things extensible?

Note, not all of these questions are unanswered. For instance, sympy.integrals.manualintegrate already implements some of these ideas. It's probably a good idea to discuss this with us (as always) if you are interested, as we will probably have some ideas ourselves on how to answer these questions.

A Strategy for step-by-step

The logic behind many SymPy operations is separated into several small methods. For example objects like sin or exp have _eval_derivative methods that are called as SymPy evaluates the derivative of a complex expression like sin(exp(x)). By capturing the inputs and outputs of all of these small methods we can collect a great quantity of information about the steps that SymPy takes. We can see that exp._eval_derivative took in exp(x) and returned exp(x) and that sin._eval_derivative took in sin(exp(x)) and returned cos(exp(x))*exp(x). These input-output pairs for each method are probably sufficient to illustrate how SymPy solves problems in many domains.

This approach of capturing the inputs of many internal functions is similar to logging systems traditionally used to analyze large codebases. We should investigate how they work and if they cause any problems with normal operation.

Once this source of information is available we can then think about interesting ways to visualize and to interact with it. A good solution will not irrevocably tie the data stream to a particular visualization technique.

This approach is straightforward intellectually but may require the student to interact with a lot of the codebase. Approaches like _eval_derivative are ubiquitous throughout SymPy but often have small variations in different modules.

Detailed subprojects in Physics

Symbolic quantum mechanics (sympy.physics.quantum)

Please contact the SymPy list (or Brian E. Granger, Ondřej Čertík) for questions about the physics related topics.

Abstract Dirac notation

  • Status: In sympy.physics.quantum we have code for symbolic Dirac notation. There is a lot there, but much more could be done on this.
  • Idea: Continue to improve this code by adding any number of features. The sky is the limit on this one. You could basically pick anything from quantum mechanics and implement it (a physical system, scattering theory, perturbation theory, etc.). A student interested in working on this should minimally have already taken an upper division (undergrad) quantum course and have a solid understanding of quantum mechanics. You would need to dig into the code and figure out what the next steps are.

Implement All Known Analytical Solutions to Quantum Mechanical Systems

  • Status: Currently, we have Hydrogen Schroedinger/Dirac energies and nonrelativistic wave functions implemented in sympy.physics.hydrogen and 1-dimensional infinite square well wave functions in sympy.physics.quantum.piab. Before this can be done, we have to finish implementing basic position/momentum bases in SymPy (see pull 573). There is still a ton of work left to do on that, so this project may be premature.
  • Idea: Implement all known analytical formulas for energies and wave functions for all QM systems that can be solved analytically (there are not too many, see http://en.wikipedia.org/wiki/List_of_quantum-mechanical_systems_with_analytical_solutions). In particular, 1d: finite/infinite well, oscillator, Coulombic field, 1d radial equation: Coulombic field, oscillator, finite/infinite well, Dirac wave functions, 2d: Coulombic field, oscillator, finite/infinite well, 3D: finite/infinite well. Then there are systems in cylindrical coordinates and other things. There will be a submodule in the quantum, that would contain as much analytical knowledge about these systems as possible, and one would retrieve the knowledge using physical parameters (e.g. (Z, n) for Hydrogen states, (n1, n2, n3) for 3D oscillator, and so on). When this is done, more things can be added --- there are many systems, whose energies can be obtained with a simple numerical procedure (like zeros of Bessel functions), and systems whose solution is given as a series. The devil is in little details, and there is high value in having all these systems implemented and tested to ensure correctness. Usage of this is for testing numerical codes, that they can reproduce analytical results, as well as when playing with and learning about QM. This project should be quite easy in terms of Python/SymPy programming, but it requires knowledge about QM.

Position and momentum basis functions

  • Status: The position and momentum basis functions in quantum mechanics are somewhat pathological because the basis functions are not square integrable. In spite of this, these representations are immensely useful and are introduced to students early on. We would like to be able to handle position and momentum wave functions on arbitrary domains in 1D, 2D and 3D. NOTE: This was the topic of a GSoC project in 2012, and this description has not been updated to reflect the work that has been done and what could still be implemented. There is a pull open from this work here. Anyone interested in this topic should consult the list.
  • Idea: Implement full machinery for position and momentum wave functions, including modified Hilbert spaces, various coordinate systems, Dirac delta functions, basis transformations in 1D, 2D and 3D. This should use the base layer of quantum states and operators in sympy.physics.quantum. The test suite/code should include classic examples from quantum mechanics, such as particle in box, H atom, simple harmonic oscillator, scattering, etc. There are some real subtle issues in this work in how operators, states and general quantum expressions are represented in the position and momentum bases.
  • Rating: (moderate-hard)

Symbolic quantum computing

  • Status: Quantum computing refers to the usage of quantum states, operators, time-evolution and measurement to perform non-trivial computations. SymPy already has a quite sophisticated symbolic quantum computing library and work continues on this.
  • Idea: Quantum error correction, Solovay-Kitaev algorithm, gate+circuit simplification using genetic algorithms, etc.
  • Rating: (hard)

Second quantization capabilities

  • Status: SymPy currently a solid module for second quantization implemented, but it needs to be updated to take advantage of the new stuff in sympy.physics.quantum. Interesting, but challenging work.
  • Idea: Work on sympy.physics.secondquant in the following areas:
    1. Refactor to use the new assumptions system.
    2. Refactor to use the stuff in sympy.physics.quantum.
    3. Implement Wick's theorem for Bosons, including the macroscopic population of the ground states.
    4. Density matrices.
    5. Time evolution.
    6. Various approximations, such as perturbation theory, Hartree-Fock, time-dependent Hartree-Fock, Hartree-Fock-Bogoliubov, etc.
    7. Implement new functions for simplifying products of second quantized operators in different ways (such as moving an annihilation operator R).
  • Rating: (hard)

Symbolic vector calculus and classical mechanics in SymPy (sympy.physics.vector and sympy.physics.mechanics)

Detailed subprojects in CSymPy

CSymPy is a standalone fast C++ symbolic manipulation library. Optional thin Python wrappers allow easy usage from Python and integration with SymPy.

Please contact the SymPy list (or Ondřej Čertík) for questions about the CSymPy related topics.

Implement More Elementary Functions

  • Status: There are currently a few functions implemented in functions.h.
  • Idea: Implement more elementary functions. See the SymPy's implementation for ideas.
  • Difficulty: medium

Implement Fast Series Expansion

  • Status: There are currently a few functions implemented in functions.h. They can differentiate themselves, but series expansion is not implemented yet.
  • Idea: Implement fast series expansion by following the similar design in SymPy. Add the .taylor_term() method that efficiently returns the n-th Taylor term. Then implement general machinery that uses this to return a series expansion
  • Difficulty: medium

Improve Python wrappers

  • Status: Currently the basic Python wrappers provide seamless integration with SymPy.
  • Idea: Make CSymPy work with Sage. This requires implementing the _sage_ methods as well as converting from Sage. This would be tested in a similar way as in SymPy, see e.g. the sympy/external/tests/test_sage.py and .travis.yml as well as bin/test_travis.sh for this. This project is not particularly difficult, but one needs to carefully check all corner cases and make sure that CSymPy works out of the box in both SymPy and Sage (for example making sure that we can use the plotting facilities in SymPy with CSymPy). As part of it would be to create an SPKG package for Sage and get it into the optional packages section of Sage. Part of the project would also be improving the documentation of the Python wrappers in form of docstrings. The general idea is that after this project is implemented, we can use SymPy for all the functionality (like plots, conversions etc.), and CSymPy only implements very fast symbolic manipulation.
  • Difficulty: easy/medium

Detailed subprojects in Computer Science, Infrastructure, GUIs and Graphics

SymPy subprojects related to GUIs and user interaction

SymPy Live and SymPy Gamma (on Google App Engine)

WolframAlpha recently released a big update. You can now pay them and get a bunch of features. They also do things like save your search history.

Right now, our competition to WolframAlpha is SymPy Live (http://live.sympy.org/), but this works a little differently. SymPy Live is an exact duplicate of the console version of SymPy, running on the App Engine, but WolframAlpha tries to be smart about what the user wants. A while back, Ondřej whipped up a thing called SymPy Gamma (http://sympygamma.com/), which is a little closer to WolframAlpha.

The GSoC project would be to improve one or both of these projects. SymPy Gamma could be improved a lot, by making it more intelligent about what output it produces for different inputs, making it parse expressions that aren't given in exact SymPy syntax (e.g. natural language queries like Wolfram|Alpha allows), making it produce plots, perhaps replacing the notebook with an IPython notebook. SymPy Live could use a lot of the same features. Furthermore, SymPy Live has bugs with pickling, which could be fixed or eliminated by converting Live to use dill instead of pickle and/or by improving the pickling support in SymPy itself.

Many of these things should be implemented in SymPy and simply called from the web applications, for example, improved parsing for SymPy Gamma. Look at Mathics (http://www.mathics.org/) for inspiration.

Parsing

  • Status: Currently SymPy has the ability to generate Python, C, and Fortran code from SymPy expressions.

  • Idea: It would be very interesting to go the other way. Can we parse Python, C, and Fortran code and produce SymPy expressions? This would allow SymPy to easily read in, alter, and write out computational code. This project would enable many other projects in the future. As a first step take a look at the current code generation and autowrap functionality. Ideally this project would create a general framework for parsers and then use this system to implement parsers for a few of the languages listed above. See the other parsing ideas on this page, as well as Parsing.

Improve the plotting module

A very approximate difficulty guesstimate is given.

  • medium-hard: Manipulate parameters in graphs (needs some kind of GUI (matplotlib provides widgets)) (IPython's notebook?)
  • medium: Animations (in matplotlib and IPython's notebook)
  • easy-medium: Write/fix/extend/port backends: matplotlib, Google Chart API link, pyglet, asciart, d3.js
  • easy: The old pyglet module does not work with the new module. Simplify the old module and write a backend for it.
  • medium-hard: Write an openGL backend for matplotlib (that should be discussed with the matplotlib team) (you may start with our pyglet module)
  • hard: Implement an intelligent routine that decides on the sampling rate so that sharp edges are better plotted (it is done for 2D however it would be nice to have it for 3D). An "asymptote detector" would be nice.
  • easy /medium: Implement a intelligent routine that automatically determines the regions of interest for plotting.
  • easy: Plot:
    • objects from the geometry module
    • 2D and 3D linear operators (the effect of a matrix on a plane/3D space)
    • the effect of complex maps
    • vector fields
    • contours
  • easy / medium: Implement a backend for Mayavi for 3D plotting.
  • Fix related things/bugs in SymPy
  • Implement high level features, so that it works akin to Mathematica (http://reference.wolfram.com/mathematica/ref/Plot.html)
  • Improve textplot so that it can support all kinds of plots using ASCII/Unicode characters right in the terminal (with no dependencies).

Benchmarks

Speed is important for SymPy. One issue is that it's difficult to tell what is too slow, and, more importantly, if a given change makes things faster or slower.

SymPy needs more benchmarks. It also needs an automated system to run them (similar to PyPy, you should look at what they are using). That way, when someone adds some code that slows things down in an unexpected way, we will know about it.

Other Related Projets

Their is 2 ideas in the Theano GSoC ideas list that are of interest to SymPy user's. 1) Lower Theano overhead (significant for scalars) and 2) generate dynamic libraries. They are interesting to SymPy user's via the SymPy -> Theano bridge that allow to compile a SymPy graph for faster execution. If you are interested in them, contact them.

Ideas

  • Linear algebra
    • Rewrite the Matrices module to be more like the polys module, i.e., allow Matrix to use the polys ground types, and separate the internal data (sparse vs. dense) from the Matrix interface. The goal is to make the matrices in SymPy much faster and more modular than they are now.
    • Refactor the matrices module to have a cleaner orthogonal organization
  • improve the integration algorithm
    • integration of functions on domains of maximum extent, etc.
    • Interesting idea: "SYMBOLIC COMPUTATION OF INTEGRALS BY RECURRENCE" by MICHAEL P. BARNETT
  • definite integration & integration on complex plane using residues. Note that we already have a strong algorithm that uses Meijer G-Functions implemented. So we need to first determine if such an algorithm would be worthwhile, or if it would be better to extend the current algorithm. Note that there are many integrals that are easy to compute using residues that cannot be computed by the current engine. Other possibilities: the ability to closed path integrals in the complex plane, which is not possible with the Meijer G algorithm.
  • Groebner bases and their applications in geometry, simplification and integration
    • improve Buchberger's algorithm and implement Faugere F4 (compare their speed) Note: This has already been implemented by a previous GSoC student. Please check with us to see the current state of Groebner bases in SymPy
  • improve polynomial algorithms (gcd, factorization) by allowing coefficients in algebraic extensions of the ground domain
  • implement efficient multivariate polynomials (arithmetic, gcd, factorization)
    • Implement a sparse representation for polynomials (see the dummy files in sympy/polys/ starting with "sparse" in the SymPy source code for a start to this project).
    • Figure out which representations to use where (sparse vs. dense).
    • implement efficient arithmetic (e.g. using geobuckets (Yan) or heaps (Monagan & Pearce))
  • improve SymPy's pattern matching abilities (efficiency and generality)
    • implement similarity measure between expression trees
    • expression complexity measures (e.g. Kolmogorov's complexity)
    • implement expressions signatures and heuristic equivalence testing
    • implement semantic matching (e.g. expression: cos(x), pattern: sin(a*x) + b)
      • e.g by using power series for this purpose (improve series speed)
    • Expand the capabilities of Wild() and match() to support regular expression-like quantifiers.
  • improve simplification and term rewriting algorithms
    • add (improve) verbatim and semi-verbatim modes (more control on expression rewriting)
    • implement more expression rewrite functions (to an exact form that user specifies). This may involve rewriting the rewrite framework to be more expressive. For example, should cos(x).rewrite(sin) return sqrt(1 - sin(x)**2) or sin(pi/2 - x)?
    • maybe put transformation rules in an external database (e.g. prolog), what about speed?
    • improve context (e.g. input) depended simplification steps in different algorithms
      • e.g. the integrator needs different sets of rules to return "better" output for different input
      • but there are more: recurrences, summations, solvers, polynomials with arbitrary coefficients
    • what about information carried by expressions?
      • what is simpler: chebyshevt(1, x) or x ?
      • what is simpler: chebyshevt(1000, x) or (...) ?
    • improve trigonometric simplification. See for example the paper by fu et. al.
  • implement symbolic (formal) logic and set theory
    • implement predicate (e.g. first-order), modal, temporal, description logic
    • implement multivalued logic; fuzzy and uncertain logic and variables
    • implement rewriting, minimization, normalization (e.g. Skolem) of expressions
    • implement set theory, cardinal numbers, relations etc.
    • This task is heavily tied to the assumptions system.
  • implement symbolic global optimization (value, argument) with/without constraints, use assumptions
  • continue work on objects with indices (tensors)
    • include the index simplification algorithms used in xAct and cadabra.
  • generalized functions -- Dirac delta, P(1/x), etc... Convolution, Fourier and Laplace transforms
    • Fourier and Laplace transforms are implemented but we can not do many cases involving distributions Is this enough alone for a project though? -Aaron
  • vector calculus, differential fields, maybe Lie algebras & groups
  • parametric integrals asymptotic expansion (integral series)
  • Integral equations. See for example the work started at http://code.google.com/p/sympy/issues/detail?id=2344. This could be part of a project on ODEs, for example.
  • partial differential equations. Currently, SymPy can't solve any PDEs, though a few tools related to separation of variables are implemented. The PDE module should be structured similarly to the ODE module (see the source code of sympy/solvers/ode.py).
  • improve SymPy's Common Subexpression Elimination (CSE) abilities.
  • Singular analysis and test continuous.
    • find singularities of the function and classify them.
    • test the function whether it is continuous at some point or not. And in the interval. Note: Please discuss this idea with us if you are interested, as as it currently presented, it is somewhat vague.
  • Control theory. systems for Maple and Mathematica might provide insight here. http://www.mcs.anl.gov/~wozniak/papers/wozniak_mmath.pdf might be useful.
  • Diophantine Equations: SymPy does have substantial support for solving these, never the less there is more work possible to improve the solver.

Non-Ideas

Every year, people ask about implementing various things that we have already decided do not belong in SymPy. Among these are:

  • Graph theory. The NetworkX package already does a great job of graph theory in Python. If you are interested in working in graph theory, you should contact them.
  • Numerical solvers. SymPy is a symbolic library, so the code should focus on solving things symbolically. There are already many libraries for solving problems numerically (NumPy, SciPy, ...).

Potential Mentors

If you are willing to mentor, please add yourself here. In parentheses, put your link-id from http://www.google-melange.com.

  • Aaron Meurer (asmeurer)

  • Matthew Rocklin (mrocklin) (Step-by-step expression manipulation)

  • Stefan Krastanov (Krastanov) (plotting module, maybe diffgeom module)

  • Sean Vig (seanv775)

  • Mateusz Paprocki (mattpap)

  • Jason Moore (moorepants) (sympy.physics.vector, sympy.physics.mechanics, vector calculus package, PyDy)

  • Ondřej Čertík (certik)

  • Chetna Gupta (chetna) (Risch Algorithm, Integration Module, Karr Algorithm)

  • Christopher Dembia (chrisdembia) (PyDy)

  • Oliver Lee (oliverlee) (PyDy)

  • Luke Peterson (luke) (PyDy)

Clone this wiki locally
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.