On Mon, Apr 8, 2013 at 3:38 PM, Tom Bachmann <[email protected]> wrote: > 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.
Well this is great to hear. So I take it then that 1 is your favorite. Obviously, 2 and 3 are more important for the project, with 2 being probably the most important idea on the ideas page. If you want to work on 2, take a look at https://code.google.com/p/sympy/issues/detail?id=3631, which is a start of an outline of what needs to be done (and there are a ton of things not listed there yet too). 3 is also important, though not as important as 2. The series module is basically the oldest module in SymPy. Ondrej originally wrote SymPy as a way to automatically compute series expansions (take a look at https://github.com/sympy/sympy-old). So it's obviously a core part of the project, and important to a great many people who use it. One question I have for 1, and I think most other community members will as well, is how it can translate into useful computations outside its own domain. In most of the polys, we have complicated algorithms, but they translate into real things, like simplifying expressions, or solving systems of polynomials. While I do think that being able to compute things about rings and modules is useful in its own right, how can you sell this to people who don't really care about this? As for mentoring, we'll have to see. For idea 1, it would have to be whoever has the most algebra background. I've got a much stronger background now than the last time I mentored you (or even the last time I reviewed your agca code), but if there is someone else who knows more, that would be great. For 2, I think really any core community member could mentor it, as all you really need to know is how the assumptions work and have historically worked. For 3, hopefully someone who is interested in it could step up. Really, you (nor any other potential GSoC student) shouldn't worry too much about mentors. If we want the project, we'll find someone to mentor it. Aaron Meurer > > 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. > > -- 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.
