GSoC 2020 - Week 3

Key highlights of this week’s work are:

• Fixed _eval_nseries() of Power

  • This was a long pending issue. Previously, in the codebase the series expansion of b**e was computed by breaking the code into different cases, depending on the values of the exponent or if the exponent has a symbol etc. Moreover, there was code to handle specific cases, and it was not written in a general way. As a result, the code was very long and it was difficult to debug it when some issue popped up.

    Hence, it was very important to completely rewrite and clean-up Pow._eval_nseries(), so that many issues get resolved and it becomes easy to debug any further issues related to series expansions or limit evaluations.

    Thus, we came up with a general algorithm covering all the cases.

    The series expansion of b**e is computed as follows:

    • We express b as f*(1 + g) where f is the leading term of b. g has order O(x**d) where d is strictly positive.
    • Then b**e = (f**e)*((1 + g)**e)where, (1 + g)**e is computed using the concept of binomial series.

    The major challenge which we had to face was the fragile nature of the existing code of Pow._eval_nseries(). Changing the code even a bit resulted in many test failures, as this function plays an important role in both series expansions and limit evaluations.

    At times, it became extremely difficult to debug the cause of failures because there were several other functions as well on which the code of this function depended. Not only this, fixing one failure caused several others to pop-up.

    Ultimately, after a week of hard-work, we got everything working. After which, we further optimised the code ensuring that we are not compromising with efficiency. At last, this issue was resolved and we ended up adding an extremely optimised implementation of the function to the codebase.

GSoC 2020 - Week 2

Key highlights of this week’s work are:

• Fixed _eval_nseries() of Mul

  • This was a long pending issue. Previously, in the codebase the series expansion of a product was computed as the product of expansions of the factors. This approach was correct only when the leading term of each series is a constant but not in general.

    For example, to compute the expansion of f(x)/x**10 at x = 0 to order O(x**10) it is necessary to compute the series expansion of the function f(x) to order O(x**20) and thus, computing till order O(x**10) would not suffice.

    The strategy we implemented to resolve this issue was:

    • Compute the order n0 of the leading term of the product as the sum of the orders of the leading terms of the factors.
    • For each factor, compute n - n0 terms of its series expansion (starting from its leading term of order n1 and ending at order n - n0 + n1).
    • Multiply the expansions (truncating at terms of order n).

    I enjoyed implementing all this because at every step we had to ensure that we are not compromising with the efficiency of the code. Finally, this issue was resolved and we ended up adding an extremely optimised implementation of the function to the codebase.
    
    

• Used is_meromorphic() function to speed up limit evaluations

  • In this PR, we made use of the is_meromorphic() function of SymPy to speed up limit evaluations for certain type of cases.

    A function is said to be meromorphic at a point, if at that point the limit of the function exists but is infinite. In these cases, the value of the limit can usually be determined with the help of the series expansion of that function and thus, there is no need to invoke the Gruntz algorithm.

    While working on the implementation of this functionality, we required the leading term of the series expansion of the function in the limit expression at the point at which the limit needs to be evaluated.

    But we came across a weird situation, where for some functions, we got Complex Infinity as the leading term. Thus, we had to rectify the _eval_as_leading_term() methods of these functions (done in a separate PR).

    After resolving this issue, we succeeded in adding the required functionality and hence, increased the efficiency of the limit evaluation algorithm of SymPy.

GSoC 2020 - Week 1

Key highlights of this week’s work are:

• Fixed incorrect limit evaluations caused due to different assumptions of the limit variable

  • In this issue, due to different assumptions of the limit variable, the output was coming out to be different and incorrect for the same limit expression. On digging deep into this issue, we observed that the assumption integer = True was common between all the incorrectly evaluated limit expressions. Thus, we concluded that the Gruntz algorithm is not able to correctly evaluate those expressions where the limit variable possesses integer = True property. So, in order to get all the correct mathematical behaviour from the expression, we decided to define a dummy variable lacking integer = True property. After which, we simply had to substitute the limit variable with this dummy variable for these type of limit expressions to resolve the issue.
    
    

• Fixed incorrect limit evaluations caused due to bug in rewriting

  • At first, this issue seemed tough to resolve because we were unable to find the source of the error. But then, we decided to examine each expression which is generated during evaluation. This helped us to observe that rewriting of the expression was taking place incorrectly and we shifted our focus towards the rewrite() function. Afterwards, it was pretty evident that the xreplace() function utilised for rewriting is not sufficient, as it did not find everything that needs to replaced. Thus, replacing the xreplace() function with the subs() function helped us to resolve this issue.

GSoC 2020 - Community Bonding Period

The first part of my GSoC journey was the Community Bonding Period.

In this period, I mainly focussed on the following things:

• Setting up my blog, where I will provide weekly reports on the progress of my project, and synchronizing it with Planet SymPy.
• Setting up a public gitter channel for discussions regarding the project.
• Prioritising the issues to be solved.
• Deciding the finer details of the workflow with my mentors and working out efficient ways to solve each particular issue.

Since I have been contributing to SymPy for the past 8-9 months, it was easier for me to blend into the community.

Now, as everything has gone as planned, I have decided to make a head start and begin with the implementation of my project.

GSoC 2020 Acceptance

The results of Google Summer of Code were out on 04 May 2020 and I am pleased to share with you that my proposal with SymPy was accepted.

I would like to thank all the members of the organisation especially Kalevi Suominen for guiding me in my proposal and PR’s. I am really excited to work for such an amazing organization.

I will be working on my project, Amendments to Limit Evaluation and Series Expansion, during a period of 3 months spanning from June to August, under the mentorship of Kalevi Suominen and Sartaj Singh.

My primary focus will be to work on the series module and make it more robust as it is the backbone of all the limit evaluations performed by the library.

Looking forward for a really productive and wonderful summer ahead.