SymPy middle term plans

8 views
Skip to first unread message

Ondrej Certik

unread,
May 26, 2009, 12:30:29 AM5/26/09
to sy...@googlegroups.com
Hi,

the GSoC just started[0], so let me write our middle term directions and plans,
so that all of you know where we are going and how you can help (and also
discuss it if you'd like we also go in some other direction not mentioned
below).

First of all, we have 5 GSoC students Aaron, Priit, Luke, Fabian and Freddie,
you can read what they will be doing at [0].

There are several main directions that I will push forward things a
lot (at the same time):


1) New assumptions system, Cythonized core

Fabian will be working on assumptions full time over the summer, when it
crystallizes a bit, I'll be helping with integrating the Cython core in my free
time. The Cython core will be optional, I still want to use the pure python
mode in Cython, we'll figure it out somehow. This is a very important project,
both the assumptions and the speed.

Fredrik was recently at Sage Days, how are you going to use Cython in
mpmath? Will you make it both pure Python and optionally Cython (maybe in pure
python mode), or will you stop being pure Python and just use Cython?


2) Ordinary and partial differential equations support

Aaron (ODE) and Priit (PDE) will be working on those fulltime. I'll be in Los
Alamos over the summer, working on magnetohydrodynamics, which means solving
fluid dynamics (Navier-Stokes equations) in a magnetic field, using finite
elements. One thing that we were discussing lately in our group was to use
SymPy to represent a PDE (actually a weak formulation), and then the C++ solver
(wrapped using Cython) will just use that sympy representation to figure out
everything it needs to solve the problem, see [1] for more details and
discussions.

This also concerns Luke, as he needs to solve ODEs numerically. Things should
be as automatic as possible, e.g. pydy[2] derives the equations, and one could
then easily choose to use Runge-Kutta to solve it, or scipy's ODEPACK, or
hopefully soon our 1D finite element code[3]. It should be integrated into
sympy and sympy should call the external libraries (the user has to install
them, or use SPD, see below).

The goal is that one should be able to write any ODE or PDE equation in sympy
and then be able to interface in principle any solver out there and
also use sympy
to do symbolic stuff with the equation like symbolically deriving the
Jacobian etc.

This project may also mean improving the tensor support, so that one can write
equations in a coordinate independent way.

3) Source Python Distribution (SPD)

Together with Brian Granger, William Stein and other Sage developers I was
working hard on SPD[4], whose aim is to provide a Sage like distribution for
any Python project and provide easy to use web notebook. The standard packages
include numpy, scipy, sympy, matplotlib and the Sage notebook (plus all
dependencies). Then one can take it and include new numerical packages easily
and create his/her own distribution. It is compatible with Sage, so any
packages you create for SPD will work in Sage and vice versa.

This also means improving sympy plotting integration with matplotlib,
easy latex
like equations in the notebook and so on, so that sympy is really easy to use
in the web notebook.

With SPD, people will be able to use sympy together with all other libraries
very easily.

4) Documentation

We need more examples in docstrings (tested with bin/doctest), because that
greatly helps to understand what each function/method is doing and it has to be
kept uptodate with bin/doctest. Preferably most of the sphinx documentation
should be generated using docstrings and module docstrings. Besides that we
need some tutorials, and those should also be checked using doctests.
We also need to write or improve docs for lots of the core functions.

Fabian is partly working on this too, many thanks for that.


So those are things that are high priority for me for this summer and
fall. That said, I encourage any other use of sympy, for example
Alan's excellent work in geometric algebra support.

Ondrej

[0] http://code.google.com/p/sympy/wiki/GSoC2009
[1] http://groups.google.com/group/hpfem/browse_thread/thread/aec7206a9709dbd2
[2] http://code.google.com/p/pydy/
[3] http://hpfem.math.unr.edu/projects/hermes1d/
[4] http://code.google.com/p/spdproject/

Fredrik Johansson

unread,
May 26, 2009, 12:48:07 AM5/26/09
to sy...@googlegroups.com
On Tue, May 26, 2009 at 6:30 AM, Ondrej Certik <ond...@certik.cz> wrote:
> Fredrik was recently at Sage Days, how are you going to use Cython in
> mpmath? Will you make it both pure Python and optionally Cython (maybe in pure
> python mode), or will you stop being pure Python and just use Cython?

My goal right now is to put mpmath efficiently in Sage (since this is
what I'm getting paid
to do :-). I'm therefore writing an alternative backend for mpmath in Cython
using Sage's build tools and its GMP (MPIR) interface. It's quite
fast, by the way, about
8-15 times faster than worst-case current Python+GMPY mpmath and 1-2
times slower
than Sage's MPFR wrapped numbers. It should be possible later to take this
extension code and remove the Sage dependency to make a standalone build.

Fredrik

Andy Ray Terrel

unread,
May 30, 2009, 7:12:13 PM5/30/09
to sy...@googlegroups.com
> One thing that we were discussing lately in our group was to use
> SymPy to represent a PDE (actually a weak formulation), and then the C++ solver
> (wrapped using Cython) will just use that sympy representation to figure out
> everything it needs to solve the problem, see [1] for more details and
> discussions.


Are you planing on adding support for forms in sympy? I don't think
it would be that difficult and if it is already supported I would love
to be using it.

-- Andy

Ondrej Certik

unread,
May 30, 2009, 7:24:52 PM5/30/09
to sy...@googlegroups.com

Could you elaborate what exactly is your idea? Some structure to hold
forms like:

a(f)
b(f, g)

e.g. input is a function(s) and output is a number? Yes, definitely,
this should be in sympy -- it's just two classes.
Could you write some simple features that it should have? I can write
it and you can then help me polish it.

Ondrej

Brian Granger

unread,
May 31, 2009, 3:23:46 AM5/31/09
to sy...@googlegroups.com
> My goal right now is to put mpmath efficiently in Sage (since this is
> what I'm getting paid
> to do :-). I'm therefore writing an alternative backend for mpmath in Cython
> using Sage's build tools and its GMP (MPIR) interface. It's quite
> fast, by the way, about
> 8-15 times faster than worst-case current Python+GMPY mpmath and 1-2
> times slower
> than Sage's MPFR wrapped numbers. It should be possible later to take this
> extension code and remove the Sage dependency to make a standalone build.

Will this part of i be able to remain BSD? (please :-) )

Brian Granger

unread,
May 31, 2009, 3:25:23 AM5/31/09
to sy...@googlegroups.com
> This also means improving sympy plotting integration with matplotlib,
> easy latex
> like equations in the notebook and so on, so that sympy is really easy to use
> in the web notebook.

What are you thinking of for sympy+matplotlib?

Ondrej Certik

unread,
May 31, 2009, 3:27:52 AM5/31/09
to sy...@googlegroups.com

Currently we use pyglet for all plotting, which is cool for 3D stuff,
but useless for notebook and also matplotlib can produce better graphs
than what we currently have.

So we'll just add an option to plotting to use matplotlib (and
probably make it the default). And mayavi for 3d plots. And the user
can choose what he wants to use.

Ondrej

Fredrik Johansson

unread,
May 31, 2009, 3:44:41 AM5/31/09
to sy...@googlegroups.com

Everything I write will be BSD.

Fredrik

Reply all
Reply to author
Forward
0 new messages