Dear all,
I would like to begin by apolgoizing for my long absence. I still think
sympy is a great project, but amidst my masters studies and phd
applicatios I simply had no time to make meaningful contributions. I am
now in the revision / exam preparation phase, and additionally have
secured a phd place, whence I have some small amount of free time (which
I have been trying to use to clear out the PR queue). In particular my
exams finish on 7 june and then have the whole summer ahead of me,
probably for the last time almost ever (since being a phd is essentially
a "real job").
So I'd like to code for sympy again! GSOC seems idea, since it will
allow me to do a substantial amount of work, without having to worry
about the financial situation.
The main point of this email is to gauge interest in projects I would
like to work on. I present here three: the first one is something I
would like to advance for personal reasons. The other two are more of
the "badly needed refactoring" kind. I figured that having a
(relatively) seasoned developer work on core sympy for three months
would probably be a good opportunity to clean up some cruft.
Anyway, these are sketches of my proposals:
-----------------------------------------------------------------------
(1) Extend the commutative algebra module.
I started the commutative algebra module ("agca") (and am currently the
sole contributor) to integrate the groebner basis code in polys/ in a
pythonic fashion into sympy. Specifically, the agca module focusses on
commutative algebra computations involving modules over polynomial rings.
In its current state, the module is very incomplete, and in any case far
behind the obvious competitors (macaulay2 and singular). Also, it is
somewhat removed from the sympy core focus (although we had some
interesting success regarding trigsimp).
My basic suggestion then would be to extend the agca module, not
focussing on polynomial rings, but on fields (and perhaps PIDs).
Specifically (for starters, more details to come in an actual proposal):
(a) get all the basic stuff (kernels, intersections, ...) working over
PIDs [you can currently work over fields, written as k[x]/(x), but that
is rather suboptimal]
(b) same for finitely generated algebras (over PIDs)
(c) implement a framework for functors (in particular Hom and tensor)
and derived functors (so in particular Ext and Tor)
Part (a) has the desirable effect of connecting agca to the matrices
module. This means that the agca module can do (much) more efficient
computations over fields, and, perhaps more importantly, it provides an
"abstract wrapper" for matrix operations. In particular this will give
sympy the ability to express linear algebra in a coordinate-free fashion
(i.e. this yields first-class representations of vector spaces,
subspaces, quotient spaces, etc).
Part (b) leverages part (a), because all computations for
finitely-generated algebras reduce to computations for modules.
Part (c) is where the interesting stuff starts. I have some chain
complexes code lying around, which can compute free resolutions for
modules over polynomial rings (in principle, though this code is very
inefficient). For PIDs, this is not particularly interesting. But for
finite-dimensional algebras over fields, we can implement the standard
(or "Bar") resolution. Provided the matrices module is sufficiently
optimized, this is actually reasonably efficient.
Once part (c) is implemented, we immediately get:
- hochschild homology and cohomology of finite-dimensional algebras
- group homology and cohomology of finite groups
I'll stop here, but I think it is clear that there is basically no limit
to the possibilities ;).
(2) Get rid of the old assumptions.
Well, what am I to say. The old assumptions system is inflexible and
arcane at its best, and inconsistent on slightly worse days (bounded
implies nonzero anyone?). We have a shiny new system (well, not so new
anymore), but we couldn't switch for a variety of practical reasons
(mainly performance and compatibility).
This is a nasty can of worms, and I am sure everyone would like to see
it fixed. But it also seems clear that this is going to be a major effort.
(3) Refactor/rewrite the series module.
This brings me back to my earliest work on sympy. The series module, in
its current form, has a number of interrelated problems:
(a) series expansions are slow
(b) series expansions are stored as sums of core objects
(c) the core has to deal with order terms
(d) limits are slow
(e) various kinds of series expansions are lumped under one heading
(f) various clients with different requirements call "series" and hope
for the best
(g) limits are buggy
[Actually I just recently hit (a) when for my masters thesis, I wanted
to do some computations with theta functions.]
It seems clear to me that the way to go is
(*) give series expansions a first class representation
in the series/ module. This (essentially) immediately (modulo a good
design) solves (b) and should go a long way for improving (a). We can
get rid of (or at least drastically simplify) (c). Fixing (a) is going
to go a long way to fix (d). Moreover, now that we have first-class
representations, there is no reason not to have different
representations for different kinds of series, so we can fix (e) and
hence (f), thus likely improving (g).
I would also see it as part of my project to investigate the limit()
heuristics, and to get rid of them as much as possible.
There have been previous attempts at doing (*), in particular by mario
(pernici). As far as I can tell these essentially proved the
effectiveness of this method, but did not make it mainstream because of
the difficulty of incorporating them into the rest of sympy.
Again it seems likely that with three months time at my hands and a
(reasonably) good understanding of sympy as a whole, this project should
be both attainable and very beneficial for the community.
-----------------------------------------------------------------------
I would like to ask for all sorts of opinions. In particular:
- which of (2) and (3) seems more important / useful to you?
- who would be interested in mentoring either of these projects?
If there is interest, I will work out (1) and one of (2) and (3) into
fully-fledged project proposals.
Best,
Tom
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sympy?hl=en-US.
For more options, visit https://groups.google.com/groups/opt_out.
