This is the list of ideas for students wishing to apply for Google Summer of Code 2013. For more information on how to apply, see GSoC-2013-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:
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.
The project is to completely remove our old assumptions system, replacing it with the new one.
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.
Numerous related tasks are mentioned in the "Ideas" section.
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:
Algorithms to think about implementing:
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.
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.
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(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.
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.
"Solving Differential Equations in Terms of Bessel Functions" by Ruben Debeerst.
Lie groups and symmetry related:
This includes numerous smaller subprojects.
Provide an interface for solving systems of polynomial inequalities
Rating: (very hard)
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.
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
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.
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. 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.
Please contact the SymPy list (or Brian E. Granger, Ondřej Čertík) for questions about the physics related topics.
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://gamma.sympy.org/), 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, making it produce plots, perhaps replacing the notebook with an IPython notebook. SymPy Live could use a lot of the same features.
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.
Write a mobile app for Android and/or iOS. Other app developers have already demonstrated that it's possible to run SymPy natively on both of these operating systems. The project would be to write an app that gives a nice interface to it. One thing that could be done would be to make a soft keyboard that is conducive to math input (similar to what WolframAlpha has for their mobile apps). If there are issues with running SymPy on the device itself, we could make the app to just be a nice interface to SymPy Live/Gamma. Perhaps it would be best to start doing this, and then once you have a nice interface, to work on running SymPy itself.
An idea relating to soft keyboards: let people design their own keyboards, with each key showing some Unicode text, and running Python code on the input. Then, create some site (on the App Engine for example) where we can let people submit their keyboards and review them, and download other people's keyboards.
NOTE: If you want to do this project, you MUST discuss it with us first, so that we can be sure that we have a mentor.
Some kind of equation editor. It could be considered part of a mobile app interface, part of a potential desktop app interface, or even a terminal curses interface. More users would be attracted to SymPy if it had some kind of 2d equation editing capabilities.
For example, a curses interface could be built on top of our current pretty-printing system. You would need to extend the printer to hold the printing information in such a way that it can be accessed by parts, then write a curses interface over it so that a user can select different parts of an equation and manipulate them.
Note: Please discuss this idea with us if you are interested, as as it currently presented, it is somewhat vague.
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.
See http://code.google.com/p/sympy/issues/detail?id=3445, and this discussion on the mailing list. Currently, our release process consists of everything at New-Release. This needs to be reduced to a single step, so that we can literally do a full release in a single day.
Note that as this currently stands, this is not enough work for a full GSoC project. Talk with us about things that could be added to it to fill up a summer's work.
A very approximate difficulty guesstimate is given.
Every year, people ask about implementing various things that we have already decided do not belong in SymPy. Among these are:
If you are willing to mentor, please add yourself here. In parentheses, put your link-id from http://www.google-melange.com.