On Tue, Apr 9, 2013 at 4:13 AM, Tom Bachmann <[email protected]> wrote:
> So, from the responses so far it seems clear that (2) is preferred over
> (3). I'll start writing more detailed proposals.
>
> Any further comments are of course still appreciated :-).
I agree with everything Aaron said (who said it better than I could:-).
Just one comment about (1). I would compare with Sage. John Palmeri (Univ
Wash) and Simon
King (Ireland) seem to be the lead programmers.
>
>
> On 08.04.2013 22:40, Tom Bachmann 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.
>>
>> 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
> sympy+unsubscribe@**googlegroups.com<sympy%[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<http://groups.google.com/group/sympy?hl=en-US>
> .
> For more options, visit
> https://groups.google.com/**groups/opt_out<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.
