Various keyword arguments could be added for whether to split rational
numbers, etc. With such options, split() could replace several existing
methods like as_coefficient, as_independent, as_base_exp, as_numer_denom,
etc. It is better to only have to remember a single method.

Using an operator symbol like '+' as argument instead of a class is my
preference as it would be more readable and more versatile ('/' can be used
even though we have no Div class).

I think there should soon be documentation in the code for most, if not
all, of the classes and functions, even if it is only a single line. This
can be useful for both the generated API documentation, and through
interactive help (i.e., the help() command in an interactive Python
session). If there is a need for this, I am fine going through all of the
code and documenting everything, or getting a good start on it.

Simplifying the answer by hand is straightforward (add up the real and
imaginary parts), but unfortunately, SymPy is unable to do this. (It also
fails to produce a numerical value: a.evalf() -> ValueError.) It seems that
currently re and as_real_imag don't know anything about logarithms.

it finds (among other things) that the Heaviside is imported but never
used, so it should be removed.

There is also pychecker, which shows a lot of things similar to this (I can't get pyflakes to work, so I can't say if it
does more or not). You can just install and run pychecker sympy --limit 1000 to see them all (it takes a few
minutes to run).

Note that there are lots of warnings coming from polys/densepolys.py, polys/densetools.py and polys/sparsepolys.py, but these modules are known not to work, cf. issue 2371.

Category: QualityAssurance

Labels: EasyToFix, Priority-Medium, Type-Defect

Time to complete: 96 hours

Pick a good sized module in SymPy (i.e., one of the subdirectories of the sympy/ directory, but not one of the ones that only has a few files in it).

Two things annoy me about ./setup.py test. First, if a regular test fails, then it does not run the
doctests. But this is supposed to be a shortcut to both the regular tests and the doctests in one.
Second, if you keyboard interrupt during the tests, it then proceeds to run the doctests. But when I
keyboard interrupt, I want it to stop the whole script.

I don't know how easy it would be to change the second item, but the first one should be fixable.

DeprecationWarning is turned off by default in Python 2.7, so all of our deprecated behavior that we deprecate with DeprecationWarning is not shown to the majority of our users (unless they are specifically looking for it, they won't find it). This was done because most users of Python programs can't do anything if the program uses deprecated behavior, so they don't care to see the warning. But I think most developers don't really do a good job of turning the warnings on, unfortunately.

I think we should create a SymPyDeprecationWarning that subclasses from DeprecationWarning, but is turned on by default in isympy. See issue 2142. That way, users of scripts that use sympy won't be bothered by them, but people who use isympy, who should be bothered by them in my opinion, will be. This will likely also include the developers of most of those scripts.

You can open the IPython qtconsole with a sympy session by typing IPython qtconsole --profile=sympy, but you should also be able to do it by typing isympy -c ipython-qtconsole. Unlike the former, the latter should perhaps not rely on IPython's built-in sympy profile to work.

This is related to issue 2026 and this thread on the mailing list. The subs mechanism should be refactored so that it is more flexible. Also, I believe it should be using the same thing internally as the pattern matching.

The (Code-In) task here is to study this problem and discuss optimal ways to solve it. You may also try implementing this (if we agree upon a good solution), perhaps as a separate task.

Additional Note(s): We only have one person available per language, so review may take a few days. Please contact us before starting a translation task, to make sure that someone is available to verify the translation.

The tutorial should be translated into various languages, e.g., Czech, Polish, French, German, etc.

Category: Translation

Labels: Priority-Medium, Type-Defect

Time to complete: 96 hours

We only have one person available per language, so review may take a few days. Please contact us before starting a translation task, to make sure that someone is available to verify the translation.

Examples/short tutorials should show how to use SymPy to solve illustrative problems in high school mathematics/physics. Notebooks must contain code split into logical blocks, text cells with problem description and references to other materials, books, videos, etc.

The method used by the 1st_exact solver is a nice one to use by hand, but it's kind of flaky. I didn't realize at the time of writing it that you can actually express the solution using integrals without introducing parameters or dummy integration limits. This solution is given in Table II of the paper "Symbolic Integration: The Stormy Decade" by Joel Moses. I was able to download this paper for free from Google Scholar. If you cannot access it and are interested in fixing this issue, contact me and I will send it to you.

Some of the Code-In tasks include translating our documentation to different languages. If this happens, we would need a way to manage all of these files (we might have many languages, after all). It's also important to know when and how much are these files out of date (as they eventually will be). Usually, GUI applications use gettext and have tons of .po files lying around, but I'm not sure that's the right approach for us. Marking this as a Code-In Research task.

Most distributions have old versions of SymPy packaged (or none at all, eg. openSUSE). These should be updated to the latest version of SymPy (0.7.1 as of now). Ideally, the scripts used to generate these packages should also be saved and uploaded somewhere, so it will be easier to update them to newer versions. I'm marking this for Code-In, but consider that each major distro could be a separate task.

This most likely means deleting the bundled mpmath/ and making SymPy play nice with the distro-provided version.

The issue tracker can provide some valuable statistics about the health of the project - it might be interesting to graph the number of open issues, number of issues per category, the average "age" of the (closed/open) issues, who closes the most issues, the number of issue reports by users (as opposed to developers of SymPy) etc. This likely involves interfacing somehow with the Google API.

lambdify() is one of most important functions in SymPy (for interoperability with numerical libraries the most important). However it's not mentioned anywhere, although it has a good docstring. The result of git grep stands for itself:

lambdify's docstring must be pulled into docs (there is already a generic issue for this), but we also need a good tutorial showing users how to cooperate with NumPy, SciPy etc. This issue (not the only one by the way) was pointed out to me by Fernando Perez during my stay at Berkeley this week, when trying to solve a practical symbolic-numeric problem. SymPy has already a lot of features, but unfortunately most of them are deeply buried in the internals of SymPy and known only to its developers. Also we have to check what does ufuncify() do, because it was reported to me that it's extremely slow.

Currently, the rewrite framework only allows expr.rewrite(function) (e.g., cos(x).rewrite(exp)), and it implements only one rule per function pair. This should be made more general. Sometimes, you can't express a rewrite rule with just a function. Other times, there is more than one way to rewrite one function in terms of another (for example cos(x) == sqrt(1 - sin(x)) == sin(pi/2 - x)).

The issue is to consider ways to make the rewrite framework stronger, but still modular like it is now (so it's easily extensible).

Also, in a recent commit (ebe8a7e) it is noted that Add and Mul's implementation was faulty:

The function used to return True if any factor was irrational.
This is nonsense: neither I*pi, nor sqrt(8)/sqrt(2) are irrational.
[One might argue about I*pi, but irrational implies real under the
current assumptions system.]
We now return True iff there is exactly one irrational factor and
all other factors are rational.

So the argument about sqrt(8)/sqrt(2) doesn't apply. But it does make sense that the only way you can know that something is irrational is to have only one irrational factor since something like sqrt(2+sqrt(3))*sqrt(2-sqrt(3)) might appear irrational with two irrational factors, but this is just a fancy 1:

Let's get inspired by ginac. This code should make it easy to compute for
example einstein equations from the (symbolic) metric tensor. We can do it
already now, but it would be nice to type in equations in the index form as
found in the general relativity books and then just plug in a symbolic
matrix for the metric tensor, and it would figure all the rest by itself.

I've written some code for determining the "class" of a formula. The
function classify(expr, x) walks the expression top-down and at each level
classifies it as a function of x. It distinguishes between various classes
of functions, including:

linear expressions

polynomials (degree > 1)

rational functions

algebraic roots

exponentials

logarithms

trigonometric functions

etc

It then recursively classifies all subexpressions and returns the path with
the "greatest" complexity. The following test outputs should hopefully make
it more clear:

I think there is a consensus about the requirements for inclusion of a (nontrivial) patch in sympy:

All tests have to pass. (Include new tests for new features.)

The patch has to be positively reviewed by someone else. (If there a objections, a consensus has to be reached.)

Wait at least 24 hours before pushing it in.

I think it should be easily accessible from the website 1, probably from the README too. It should be clear to newcomers that not only contribution is very welcome, but also reviewing patches. (The latter currently lacks somewhat imho.) People new to sympy should not be afraid to review patches.

We should include in the README, and probably in the docs somewhere too, a list of all the "dependencies" of SymPy. Now, obviously, SymPy's only dependency is Python, but there are several optional dependencies like IPython and gmpy that are not required but extent the capabilities of SymPy if they are installed.

dsolve() is way faster because it just computes the necessary form of the integral and solves for the undetermined coefficients. No complicated integration algorithm is needed.

So I think if the integral has the correct form, that internally integrate(expr, x, x, ...) should use dsolve's internal undetermined coefficient algorithms for solving f(x).diff(x, x, …) - expr. All the necessary stuff is already in ode.py, including the function that checks if expr is of the correct form.

If any code wants to know if there are variables that are free like x but not y in Integral(y, (y, 1, x)) then it should use expr.free_symbols, not .atoms(Symbol) (since that would have given x and y for the example given). The code should be checked for instances of .atoms(Symbol) to see what the author intended and corrected if necessary.

Now that we don't support Python 2.4, we can use with statement context managers. One of the best places to use this is when opening a file. You can do

withopen(file) as f:
do stuff

instead of

f =open(file)
do stuff
f.close()

And it's not only more readable, but also the with statement context manager will automatically close the file, even if an exception is raised.

There are a handful of places in the code where we open() stuff (do git grep "open("). Remember that to support the with statement in Python 2.5, you have to add "from future import with_statement" to the top of the file.

If you do git grep "except:" you will see that there are several places in the code with bare except statements that should be rewritten to catch explicit exceptions. To quote the Zen of Python:

Errors should never pass silently.
Unless explicitly silenced.

And to quite PEP 8:

- When catching exceptions, mention specific exceptions
whenever possible instead of using a bare 'except:' clause.
For example, use:
try:
import platform_specific_module
except ImportError:
platform_specific_module = None
A bare 'except:' clause will catch SystemExit and KeyboardInterrupt
exceptions, making it harder to interrupt a program with Control-C,
and can disguise other problems. If you want to catch all
exceptions that signal program errors, use 'except Exception:'.
A good rule of thumb is to limit use of bare 'except' clauses to two
cases:
1) If the exception handler will be printing out or logging
the traceback; at least the user will be aware that an
error has occurred.
2) If the code needs to do some cleanup work, but then lets
the exception propagate upwards with 'raise'.
'try...finally' is a better way to handle this case.

To be sure, some of the bare except cases in the code are correct by the above (like the ones in the test runner), but many are not.

Additional Note(s): This task is marked as easy because most of the public functions appear to already be imported.

There are some methods that do have docstrings, but are not shown in the documentation (docs.sympy.org).

For example, method norm in matrices.matrices.py has a docstring, but is not shown in http://docs.sympy.org/dev/modules/matrices.html. I thought that the bad formatting (there is no blank line after the first line of docstring) of the docstring might be the reason for this, but there are other methods with baddly formatted docstrings, that are properly shown in the documentation (e.g. method is_symmetric for matrices.matrices.py).

I've been looking into how to pretty print the Sigma using unicode. Here's what I've got so far:

This is what we do for ascii:

n
__
\ `
) 2⋅f(k)
/_,
k = 1

Here's the best unicode I have so far:

n
__
╲
) f(k)
╱
‾‾
k = 1

I couldn't find characters (yet) to replicate ` and , (the new horizontal lines are at a different height). I also haven't found a better replacement for ).

There are these unicode symbols

⎲
⎳

(\u23b2 and \u23b3, respectively) which take up more than one character of space in my terminal (both width and height) and would actually look kind of nice for summations of that size. So this is the issue from https://github.com/sympy/sympy/pull/389 again. How do we programmatically tell if a symbol takes up more than one character space, and if so, how many?

There are some .py files in doc/src/modules/galgebra/GA which have some strange indentation (and aren't valid Python source files either). Aaron also noticed this and they produce (harmless) errors when 2to3 is ran on them. I've finally had a chance to look at them and they seem to be included in the main GA module documentation, GAsympy.txt. In fact, they seem to be used like a doctest - the first part of the file (indented) are the comments that produce the second half of the file (not indented). These should be converted to be actual doctests.

Those files also haven't been touched since 2009 so it's not clear to me if anyone is even using this part of SymPy now, but fixing the docs shouldn't be too hard and can be a good introduction to SymPy for an interested developer (hence, I'm putting the EasyToFix tag here). Also, I don't think these files are ran as part of the doctest suite which means errors might be creeping in and we'd like to avoid this.

For the record, here are the errors produced when 2to3 is ran on these files:

The original logo is found at http://code.google.com/p/sympy/source/browse/#svn%2Fmaterials%2Flogo The problem is that the transparency is not done correctly on the tail, so that it does not look good unless the background is white. We need to fix it so that it uses the correct kind of alpha channel, so that it looks good everywhere. There is a svg image there, though I didn't have much luck with it.

Edit the doc-string to add list of other function that are closely related to the query.

Ex.

>>> prime?
Docstring:
Return the nth prime, with the primes indexed as prime(1) = 2,
prime(2) = 3, etc.... The nth prime is approximately n*log(n) and
can never be larger than 2**n.
Reference: http://primes.utm.edu/glossary/xpage/BertrandsPostulate.html

If you "git grep '# *assert'", you'll see a bunch of tests where the test line is commented out. These should be changed to be XFAIL tests, so that we can see if they start passing. Also, they should be double checked to see if they really would start passing (e.g., they don't have syntax errors).

Additional Note(s): We only have one person available per language, so review may take a few days.

Our webpage can be translated to other languages. Note that this is connected with issue #2764, about improving our webpage: if someone is working on that, there's likely no point in translating the page as it'll change.

Category: Translation

Labels: Priority-Medium, Type-Defect

Time to complete: 48 hours

We only have one person available per language, so review may take a few days.

Additional Note(s): We only have one person available per language, so review may take a few days.

Our webpage can be translated to other languages. Note that this is connected with issue #2764, about improving our webpage: if someone is working on that, there's likely no point in translating the page as it'll change.

Category: Translation

Labels: Priority-Medium, Type-Defect

Time to complete: 48 hours

We only have one person available per language, so review may take a few days.

Additional Note(s): We only have one person available per language, so review may take a few days.

Our webpage can be translated to other languages. Note that this is connected with issue #2764, about improving our webpage: if someone is working on that, there's likely no point in translating the page as it'll change.

Category: Translation

Labels: Priority-Medium, Type-Defect

Time to complete: 48 hours

We only have one person available per language, so review may take a few days.

Additional Note(s): We only have one person available per language, so review may take a few days.

Our webpage can be translated to other languages. Note that this is connected with issue #2764, about improving our webpage: if someone is working on that, there's likely no point in translating the page as it'll change.

Category: Translation

Labels: Priority-Medium, Type-Defect

Time to complete: 48 hours

We only have one person available per language, so review may take a few days.

Additional Note(s): We only have one person available per language, so review may take a few days.

Our webpage can be translated to other languages. Note that this is connected with issue #2764, about improving our webpage: if someone is working on that, there's likely no point in translating the page as it'll change.

Category: Translation

Labels: Priority-Medium, Type-Defect

Time to complete: 48 hours

We only have one person available per language, so review may take a few days.

Additional Note(s): We only have one person available per language, so review may take a few days.

Our webpage can be translated to other languages. Note that this is connected with issue #2764, about improving our webpage: if someone is working on that, there's likely no point in translating the page as it'll change.

Category: Translation

Labels: Priority-Medium, Type-Defect

Time to complete: 48 hours

We only have one person available per language, so review may take a few days.

Additional Note(s): We only have one person available per language, so review may take a few days.

Our webpage can be translated to other languages. Note that this is connected with issue #2764, about improving our webpage: if someone is working on that, there's likely no point in translating the page as it'll change.

Category: Translation

Labels: Priority-Medium, Type-Defect

Time to complete: 48 hours

We only have one person available per language, so review may take a few days.

We have a page on the wiki SymPy-Papers that should list (scientific) papers mentioning SymPy, but it's currently empty. Populating this would be interesting and could also persuade other academics to try out/use SymPy. Google Scholar can be used to track down papers. See also the thread which originally asked about this.

At http://docs.python.org/reference/datamodel.html, it lists all the __methods__ that Python works with (like __int__, __contains__, etc.). We should go through all of these and make sure they are all defined on Basic, Expr, or whatever relevant subclass, so that we don't have simple bugs like

Regarding where they should be defined, stuff that makes sense for any object should go on Basic, stuff that makes sense only on mathematical objects (like __add__ for example) should go on Expr, and stuff that makes sense only for numbers (like __int__) should go in Number.

So checkodesol() needs to be more aggressive, since dsolve() obtains these logarithms by calling logcombine(force=True). An expand with force=True should be used on expressions being tested or else (as shown above) terms which should go to zero, don't:

Integral.transform is confusing, since it requires you to use the same integration variable. But usually, when we do a transfrom on an integral we change the name of the variable. It should allow something like

Integral.transform(x, 2*y, y)

where y is the new variable. The third argument would default to the integration variable, so that you can still use the current syntax.

Also, the docstring needs some doctests, which would also make it less confusing.

This is related to issue 1908. When I met with Ondrej last summer, we worked on a core where
objects knew how to combine themselves with respect to Mul and Add. See the handler branch at
http://github.com/certik/sympyx/. The idea originally stemmed from issue 1336, but we soon
discovered that it also simplifies the logic for things like O() (the order function), and oo, which
combine abnormally with respect to Mul and Add. This could also be useful for issue 1940, so that
the units could tell Mul that they need to stay together without Mul explicitly having to know about
units. Right now, Mul.flatten is cluttered with code for handling all these things, and the only way
to handle additional classes is to either completely separate them from Basic (as with Poly), or to
add more special case code in Mul.flatten.

Anyway, if we ever rework the core as suggested in issue 1908 or elsewhere, we should also look into doing this too.

So my friend pointed out to me that WolphramAlpha lets you enter any LaTeX formula, and it will parse it and evaluate it. I think we should have a parser that lets us do the same thing. In his case, he takes notes in LaTeX and does all of his homework in it, and he was able to just paste an expression from his homework into WolphramAlpha and it did if for him.

I tried the new live.sympy.org on my 1st gen iPod touch (iOS 3). There are a couple of things that make the usage difficult:

Pressing both "Return" and "Shift-Return" on the keyboard just creates a newline in the input, regardless of whether the "Enter/Shift-Enter" popup is set to. You can still enter the expression by pressing the "Evaluate" button, but it would be nice if the keyboard worked.

There's no way to access the history. There is no "Control" key on an iPod touch.

You cannot scroll within a frame in mobile Safari, so you can't access the history of the session beyond a few inputs.

This may be an inherent problem with the fonts in iOS, but the unicode output of the result of dsolve(f(x).diff(x, x) + 2*f(x).diff(x) + f(x) - exp(x) + sin(x), f(x)) is a little off. I'm happy to report that the LaTeX output works great, though.

There are a few minor issues with the size of things, which would be fixed the best if there were a mobile version of the site. But this is a lower priority. If the above items can be fixed, the site as it is will work just fine in a mobile environment.

This is something that's been bothering me for a while. Piecewise has the following syntax (I quote the docstring):

Usage
=====
Piecewise( (expr,cond), (expr,cond), ... )
- Each argument is a 2-tuple defining a expression and condition
- The conds are evaluated in turn returning the first that is True.
If any of the evaluated conds are not determined explicitly False,
e.g. x < 1, the function is returned in symbolic form.
- If the function is evaluated at a place where all conditions are False,
a ValueError exception will be raised.
- Pairs where the cond is explicitly False, will be removed.
Examples
========
>>> from sympy import Piecewise, log
>>> from sympy.abc import x
>>> f = x**2
>>> g = log(x)
>>> p = Piecewise( (0, x<-1), (f, x<=1), (g, True))
>>> p.subs(x,1)
1
>>> p.subs(x,5)
log(5)

The problem is the use of (g, True) for the "otherwise" condition. The problem is that if a conditional reduces to True, then this will be interpreted as an "otherwise" condition rather than returning it.

Additional Note(s): It would be cool to have a little feed at the right on live.sympy.org to show what other people are entering, so that people can see what sorts of things are being done.

It would be cool to have a little feed at the right on live.sympy.org to show what other people are entering, so that people can see what sorts of things are being done. Of course, you should be able to disable this for your own entries, for privacy reasons. It should allow you to input the same expression in your session and execute it.

Category: User Interface

Labels: Live, Priority-Medium, Type-Defect

Time to complete: 144 hours

It would be cool to have a little feed at the right on live.sympy.org to show what other people are entering, so that people can see what sorts of things are being done.

Implement the algorithm for trigonometric simplification from the paper "Automated and readable simplification of trigonometric expressions" by Fu, et. al. (you should be able to find the paper for free from Google Scholar, otherwise email me and I will send it to you).

Additional Note(s): Currently slow tests are simply skipped, but this makes it hard to actually run them. There should be a decorator for this (e.g. @slow) that would all to to run such tests when give an extra option to bin/test or test() (--slow and slow=True, respectively). It should be also possible to specify a timeout for slow tests so that they do not hang test runner. It should be also possible to press Ctrl+C (KeyboardInterrupt) to kill a slow test without killing test runner. There should be statistics added at the end which would tell how many slow tests were run, how many timed out and maybe other. Also, almost all skipped tests (or maybe all) are currently skipped because they are slow, so after this is implemented, they should all be converted.

Currently slow tests are simply skipped, but this makes it hard to actually run them. There should be a decorator for this (e.g. @slow) that would all to to run such tests when give an extra option to bin/test or test() (--slow and slow=True, respectively). It should be also possible to specify a timeout for slow tests so that they do not hang test runner. It should be also possible to press Ctrl+C (KeyboardInterrupt) to kill a slow test without killing test runner. There should be statistics added at the end which would tell how many slow tests were run, how many timed out and maybe other.

Category: QualityAssurance

Labels: Priority-Medium, Testing, Type-Enhancement

Time to complete: 144 hours

Currently slow tests are simply skipped, but this makes it hard to actually run them. There should be a decorator for this (e.g. @slow) that would all to to run such tests when give an extra option to bin/test or test() (--slow and slow=True, respectively). It should be also possible to specify a timeout for slow tests so that they do not hang test runner. It should be also possible to press Ctrl+C (KeyboardInterrupt) to kill a slow test without killing test runner. There should be statistics added at the end which would tell how many slow tests were run, how many timed out and maybe other. Also, almost all skipped tests (or maybe all) are currently skipped because they are slow, so after this is implemented, they should all be converted.

simplify() already implements measure argument and uses it to choose over alternative expressions given by pairs of specific simplification routines. However, those specific simplification routines (like trigsimp()) don't support measure argument and make arbitrary built-in choices when simplifying expressions. This leads to simplification results that are dependent on the implicit measure built-in into a particular simplification step of a function. Those functions should use a measure to verify whether a candidate simplified expression is really simpler than an input expression. Investigate how to implement measures in those functions (at least in trigsimp()) to avoid combinatorial explosion of choices. You may have to employ optimization techniques like greedy algorithms, dynamic programming, meta heuristics, etc. Prepare sample non-trivial inputs, measures and outputs that can be used as tests for the algorithm(s) you will propose.