The convention used is actually related to the Karr algorithm, in that it is based on the conventions defined in his paper https://docs.sympy.org/latest/modules/concrete.html#sympy.concrete.summations.Sum. It relates to the way so-called indefinite summations work, which are an important part of the algorithm.
Regarding the project, I would warn that the Karr algorithm is quite complicated, so it would be good to try to split it into workable pieces, with the assumption that only some of the first pieces may be completed over the summer. Aaron Meurer On Wed, Mar 11, 2020 at 7:18 AM Oscar Benjamin <[email protected]> wrote: > > Hi Neeraj, > > That all sounds excellent. I don't know the algorithms you are > referring to or the summation code that well myself but I know that it > needs some love! > > A GSOC proposal is always more enticing if it demonstrates > understanding of the existing codebase and known problems. It is > probably worth taking a look at the open issues and PRs that have the > concrete label: > https://github.com/sympy/sympy/issues?q=is%3Aopen+is%3Aissue+label%3Aconcrete > https://github.com/sympy/sympy/pulls?q=is%3Aopen+is%3Apr+label%3Aconcrete > > Can you see any examples there that could be calculated with the > algorithms you mentioned? > > One thing that needs sorting out is a fully precise definition of what > a Sum actually represents. At the moment we have > > In [24]: Sum(1, (x, 1, S(1)/2)) > Out[24]: > 1/2 > ___ > ╲ > ╲ > ╱ 1 > ╱ > ‾‾‾ > x = 1 > > In [25]: Sum(1, (x, 1, S(1)/2)).doit() > Out[25]: 1/2 > > To me that's gibberish but the question is how non-integer limits > should be interpreted (or whether they should be allowed). > > We also have things like this: > > In [31]: Sum(1, (x, y, z)).doit() > Out[31]: -y + z + 1 > > In [32]: Sum(1, (x, y, z)).doit().subs(z, -1).subs(y, 1) > Out[32]: -1 > > I think that the current summation code is not very mature so be > prepared to find that various surrounding bits need improvement while > implementing the algorithms. > > > Oscar > > On Wed, 11 Mar 2020 at 08:16, Neeraj Adhikari <[email protected]> wrote: > > > > Hello SymPy Developers, > > > > I am interested in applying to GSoC 2020 so here's my introduction. > > > > I'm a grad student at the University of Rhode Island, currently in my > > second semester pursuing a Master's Degree in Computer Science. I have > > strong interests in mathematics in general and specifically the > > intersection of mathematics and computer science. I have been programming > > in python on and off since about 2015, when I worked on my undergraduate AI > > project (a basic chat bot). More recently I used python for a computer > > vision project in my previous job. The project involved extracting > > structured information from images of identity cards. > > > > Maple is the CAS I'm most familiar with as I'm using it for course I'm > > taking. I had heard of Sage before but didn't know that SymPy was its > > backend for symbolic computation. For GSoC 2020, I want to work on > > summation algorithms. With SymPy only implementing Gosper's algorithm now, > > there are a lot of expression classes whose summations cannot be computed. > > Before the summer, I will be implementing an algorithm that uses generating > > functions (link to paper) to sum hybrid functions as a project for the > > course. This algorithm can find sums containing special functions like the > > harmonic numbers and fibonacci numbers, which SymPy is mostly unable to do > > now. (For example, summation(k*harmonic(k), (k,1,n)) does not produce a > > closed form). My implementation for the course will be in the Maple > > programming language, and my first task would be porting that to SymPy. > > Once that is done, I want to move on to implementing Karr's algorithm, > > first for the indefinite case and then the definite case. I think > > implementing an algorithm I'm already familiar with first might be better > > than to dive headfirst into the more complex Karr's algorithm. What are > > your thoughts on this? > > > > Another relevant piece of information: my major professor (Dr. Ed Lamagna) > > is a computer algebra researcher and has contributed to the implementation > > of some algorithms in Maple. I will be able to ask him for advice in case > > I'm stuck on something. > > > > Thanks, > > Neeraj > > > > -- > > 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 view this discussion on the web visit > > https://groups.google.com/d/msgid/sympy/e51d9e24-149c-45b7-a10d-a42b881f8cf0%40googlegroups.com. > > -- > 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 view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/CAHVvXxQkqt8ZJg-OSQUyioWM_YiiQo75jb23q3o0-G92UAYyCw%40mail.gmail.com. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6Jm8TyaXqYSJc%2BOMCeYrEJpZ_R0V-PscpcumhMxGGMwFQ%40mail.gmail.com.
