Sachin Agarwal2020-07-12T11:25:59+00:00https://sachin-4099.github.io/Sachin Agarwalsachinagarwal0499@gmail.comGSoC 2020 - Week 82020-07-12T00:00:00+00:00https://sachin-4099.github.io//GSoC-2020-Week-8<p>Key <code class="language-plaintext highlighter-rouge">highlights</code> of this week’s work are:</p>
<ul>
<li>
<p><strong><a href="https://github.com/sympy/sympy/pull/19716">Fixed incorrect limit evaluation related to LambertW function</a></strong></p>
<ul>
<li>This was a minor bug fix. We added the <code class="language-plaintext highlighter-rouge">_singularities</code> feature to the <code class="language-plaintext highlighter-rouge">LambertW</code> function so that its limit gets evaluated using the <code class="language-plaintext highlighter-rouge">meromorphic check</code> already present in the limit codebase.
<br /><br /></li>
</ul>
</li>
<li>
<p><strong><a href="https://github.com/sympy/sympy/pull/18696">Fixed errors in assumptions when rewriting RisingFactorial / FallingFactorial as gamma or factorial</a></strong></p>
<ul>
<li>This was a long pending issue. The rewrite to <code class="language-plaintext highlighter-rouge">gamma</code> or <code class="language-plaintext highlighter-rouge">factorial</code> methods of <code class="language-plaintext highlighter-rouge">RisingFactorial</code> and <code class="language-plaintext highlighter-rouge">FallingFactorial</code> did not handle all the possible cases, which caused errors in some evaluations.
Thus, we decided to come up with a proper rewrite using <code class="language-plaintext highlighter-rouge">Piecewise</code> which accordingly returned the correct rewrite depending on the assumptions on the variables.
Handling such rewrites using <code class="language-plaintext highlighter-rouge">Piecewise</code> is never easy, and thus there were a lot of failing testcases.
After spending a lot of time debugging and fixing each failing testcase, we were finally able to merge this.</li>
</ul>
</li>
</ul>
<p>This marks the end of <code class="language-plaintext highlighter-rouge">Phase-2</code> of the program. I learnt a lot during these two months and gained many important things from my mentors.</p>
GSoC 2020 - Week 72020-07-05T00:00:00+00:00https://sachin-4099.github.io//GSoC-2020-Week-7<p>Key <code class="language-plaintext highlighter-rouge">highlights</code> of this week’s work are:</p>
<ul>
<li>
<p><strong><a href="https://github.com/sympy/sympy/pull/19680">Improved the limit evaluations of Power objects</a></strong></p>
<ul>
<li>
<p>This PR improves the limit evaluations of Power objects.
We first check if the limit expression is a <code class="language-plaintext highlighter-rouge">Power object</code> and then accordingly evaluate the limit depending on different cases.
First of all, we express <code class="language-plaintext highlighter-rouge">b**e</code> in the form of <code class="language-plaintext highlighter-rouge">exp(e*log(b))</code>. After this, we check if <code class="language-plaintext highlighter-rouge">e*log(b)</code> is <code class="language-plaintext highlighter-rouge">meromorphic</code> and accordingly evaluate the final result.
This check helps us to handle the trivial cases in the beginning itself.</p>
<p>Now, if <code class="language-plaintext highlighter-rouge">e*log(b)</code> is not meromorphic, then we separately evaluate the limit of the base and the exponent.
This helps us to determine the <code class="language-plaintext highlighter-rouge">indeterminant form</code> of the limit expression if present.
As we know, there are 3 indeterminate forms corresponding to power objects: <code class="language-plaintext highlighter-rouge">0**0</code>, <code class="language-plaintext highlighter-rouge">oo**0</code>, and <code class="language-plaintext highlighter-rouge">1**oo</code>, which need to be handled carefully.
If there is no indeterminate form present, then no further evaluations are required. Otherwise, we handle all the three cases separately and correctly evaluate the final result.</p>
<p>We also added some code to improve the evaluation of limits having <code class="language-plaintext highlighter-rouge">Abs()</code> expressions.
For every <code class="language-plaintext highlighter-rouge">Abs()</code> term present in the limit expression, we replace it simply by its argument or the negative of its argument, depending on
whether the value of the limit of the argument is greater than zero or less than zero for the given limit variable.</p>
<p>Finally, we were able to merge this after resolving some failing testcases.
<br /><br /></p>
</li>
</ul>
</li>
<li>
<p><strong><a href="https://github.com/sympy/sympy/pull/19697">Fixed limit evaluations involving error functions</a></strong></p>
<ul>
<li>
<p>The incorrect limit evaluations of <code class="language-plaintext highlighter-rouge">error functions</code> were mainly because the <code class="language-plaintext highlighter-rouge">tractable</code> rewrite was wrong and did not handle all the possible cases.
For a proper rewrite, it was required that the limit variable be passed to the corresponding rewrite method.
This is because, to define a correct rewrite we had to evaluate the limit of the argument of the <code class="language-plaintext highlighter-rouge">error function</code>, for the passed limit variable.
Thus, we added a default argument <code class="language-plaintext highlighter-rouge">limitvar</code> to all the <code class="language-plaintext highlighter-rouge">tractable rewrite</code> methods and resolved this issue.
While debugging, we also noticed that the <code class="language-plaintext highlighter-rouge">_eval_as_leading_term</code> method of error function was wrong, hence it was also fixed.</p>
<p>Finally, we were able to merge this after resolving some failing testcases.</p>
</li>
</ul>
</li>
</ul>
GSoC 2020 - Week 62020-06-28T00:00:00+00:00https://sachin-4099.github.io//GSoC-2020-Week-6<p>Key <code class="language-plaintext highlighter-rouge">highlights</code> of this week’s work are:</p>
<ul>
<li>
<p><strong><a href="https://github.com/sympy/sympy/pull/19646">Fixed RecursionError and Timeout in limit evaluations</a></strong></p>
<ul>
<li>
<p>The <code class="language-plaintext highlighter-rouge">Recursion Errors</code> in limit evaluations were mainly due to the fact that the indeterminant form of <code class="language-plaintext highlighter-rouge">1**oo</code> was not handled accurately in the <code class="language-plaintext highlighter-rouge">mrv()</code> function of the
<code class="language-plaintext highlighter-rouge">Gruntz algorithm</code>. So, some minor changes were required to fix those.</p>
<p>The major issue was to handle those cases which were timing out. On deep digging, we identified that the
<code class="language-plaintext highlighter-rouge">cancel()</code> function of <code class="language-plaintext highlighter-rouge">polytools.py</code> was the reason. Thus, we decided to completely transform the <code class="language-plaintext highlighter-rouge">cancel()</code> function to speed up its algorithm.
Now after this major modification, many testcases were failing as the <code class="language-plaintext highlighter-rouge">cancel()</code> function plays an important role in simplifying evaluations and
is thus used at many places across the codebase. Therefore, a lot of time was spent in debugging and rectifying these testcases.</p>
<p>Finally we were able to merge this, enhancing the limit evaluation capabilities of <code class="language-plaintext highlighter-rouge">SymPy</code>.</p>
</li>
</ul>
</li>
</ul>
GSoC 2020 - Week 52020-06-21T00:00:00+00:00https://sachin-4099.github.io//GSoC-2020-Week-5<p>Key <code class="language-plaintext highlighter-rouge">highlights</code> of this week’s work are:</p>
<ul>
<li>
<p><strong><a href="https://github.com/sympy/sympy/pull/19555">Adds cdir parameter to handle series expansions on branch cuts</a></strong></p>
<ul>
<li>
<p>Finally, after spending almost 2 weeks on this, we were able to merge the PR, adding a very important functionality of <code class="language-plaintext highlighter-rouge">series expansions</code> on the <code class="language-plaintext highlighter-rouge">branch cuts</code> to the codebase.
Previously, either <code class="language-plaintext highlighter-rouge">SymPy</code> raised some error or the series expansion was computed incorrectly, when the value in the input was on the branch cut. But now, for most of the functions, the expansion produced is correct.</p>
<p>Not only this, we added the <code class="language-plaintext highlighter-rouge">cdir</code> parameter to <code class="language-plaintext highlighter-rouge">leadterm</code> and <code class="language-plaintext highlighter-rouge">as_leading_term</code> functions as well. We even extended the functionality a bit to the <code class="language-plaintext highlighter-rouge">limits</code> module, so now,
<code class="language-plaintext highlighter-rouge">limits</code> of values lying on the branch cuts of a function are also computed correctly in most cases.</p>
<p>We are planning to extend this functionality to all the remaining <code class="language-plaintext highlighter-rouge">special functions</code> and wherever else possible to make the codebase even more <code class="language-plaintext highlighter-rouge">robust</code>.</p>
</li>
</ul>
</li>
</ul>
GSoC 2020 - Week 42020-06-14T00:00:00+00:00https://sachin-4099.github.io//GSoC-2020-Week-4<p>Key <code class="language-plaintext highlighter-rouge">highlights</code> of this week’s work are:</p>
<ul>
<li>
<p><strong><a href="https://github.com/sympy/sympy/pull/19515">Fixed incorrect evaluation caused due to subfactorial in limit_seq expression</a></strong></p>
<ul>
<li>This was a minor bug fix.
The functionality of rewriting the <code class="language-plaintext highlighter-rouge">subfactorial</code> term present in an expression into an equivalent term expressed in
the form of <code class="language-plaintext highlighter-rouge">factorial</code> or <code class="language-plaintext highlighter-rouge">gamma</code> was added which helped resolve the issue.
<br /><br /></li>
</ul>
</li>
<li>
<p><strong><a href="https://github.com/sympy/sympy/pull/19555">Adds cdir parameter to handle series expansions on branch cuts</a></strong></p>
<ul>
<li>
<p>Currently, many functions in the codebase are unable to produce correct <code class="language-plaintext highlighter-rouge">series expansions</code> on <code class="language-plaintext highlighter-rouge">branch cuts</code>. As a result,
the limit evaluation takes place incorrectly for these functions when the limiting value lies on the branch cuts.</p>
<p>Thus, we have decided to come up with a parameter named <code class="language-plaintext highlighter-rouge">cdir</code> which stands for <code class="language-plaintext highlighter-rouge">complex direction</code> and it indicates the direction from which the series expansion is required, thus helping us
to produce the correct series expansion. Special care needs to be taken while handling series expansions on the <code class="language-plaintext highlighter-rouge">branch points</code>.</p>
<p>Once we are finished with this work, it will be a <code class="language-plaintext highlighter-rouge">major enhancement</code> to the limit evaluation and series expansion capabilities of <code class="language-plaintext highlighter-rouge">SymPy</code>.</p>
</li>
</ul>
</li>
</ul>
<p>This marks the end of <code class="language-plaintext highlighter-rouge">Phase-1</code> of the program. I learnt a lot during this one month and gained many important things from my mentors.</p>
GSoC 2020 - Week 32020-06-07T00:00:00+00:00https://sachin-4099.github.io//GSoC-2020-Week-3<p>Key <code class="language-plaintext highlighter-rouge">highlights</code> of this week’s work are:</p>
<ul>
<li>
<p><strong><a href="https://github.com/sympy/sympy/pull/19508">Fixed _eval_nseries() of Power</a></strong></p>
<ul>
<li>
<p>This was a long pending issue.
Previously, in the codebase the <code class="language-plaintext highlighter-rouge">series expansion of b**e</code> 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.</p>
<p>Hence, it was very important to completely rewrite and clean-up <code class="language-plaintext highlighter-rouge">Pow._eval_nseries()</code>, so that many issues get resolved and
it becomes easy to debug any further issues related to series expansions or limit evaluations.</p>
<p>Thus, we came up with a <code class="language-plaintext highlighter-rouge">general algorithm</code> covering all the cases.</p>
<p>The series expansion of <code class="language-plaintext highlighter-rouge">b**e</code> is computed as follows:</p>
<ul>
<li>We express <code class="language-plaintext highlighter-rouge">b</code> as <code class="language-plaintext highlighter-rouge">f*(1 + g)</code> where <code class="language-plaintext highlighter-rouge">f</code> is the leading term of <code class="language-plaintext highlighter-rouge">b</code>. <code class="language-plaintext highlighter-rouge">g</code> has order <code class="language-plaintext highlighter-rouge">O(x**d)</code> where <code class="language-plaintext highlighter-rouge">d</code> is strictly positive.</li>
<li>Then <code class="language-plaintext highlighter-rouge">b**e</code> = <code class="language-plaintext highlighter-rouge">(f**e)*((1 + g)**e)</code>where, <code class="language-plaintext highlighter-rouge">(1 + g)**e</code> is computed using the concept of <code class="language-plaintext highlighter-rouge">binomial series</code>.</li>
</ul>
<p>The major challenge which we had to face was the fragile nature of the existing code of <code class="language-plaintext highlighter-rouge">Pow._eval_nseries()</code>.
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.</p>
<p>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.</p>
<p>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.</p>
</li>
</ul>
</li>
</ul>
GSoC 2020 - Week 22020-05-31T00:00:00+00:00https://sachin-4099.github.io//GSoC-2020-Week-2<p>Key <code class="language-plaintext highlighter-rouge">highlights</code> of this week’s work are:</p>
<ul>
<li>
<p><strong><a href="https://github.com/sympy/sympy/pull/19369">Fixed _eval_nseries() of Mul</a></strong></p>
<ul>
<li>
<p>This was a long pending issue.
Previously, in the codebase the <code class="language-plaintext highlighter-rouge">series expansion of a product</code> was computed as the <code class="language-plaintext highlighter-rouge">product of expansions of the factors</code>.
This approach was correct only when the <code class="language-plaintext highlighter-rouge">leading term of each series</code> is a <code class="language-plaintext highlighter-rouge">constant</code> but not in general.</p>
<p>For example, to compute the expansion of <code class="language-plaintext highlighter-rouge">f(x)/x**10</code> at <code class="language-plaintext highlighter-rouge">x = 0</code> to order <code class="language-plaintext highlighter-rouge">O(x**10)</code> it is necessary to compute the series expansion
of the function <code class="language-plaintext highlighter-rouge">f(x)</code> to order <code class="language-plaintext highlighter-rouge">O(x**20)</code> and thus, computing till order <code class="language-plaintext highlighter-rouge">O(x**10)</code> would not suffice.</p>
<p>The strategy we implemented to resolve this issue was:</p>
<ul>
<li>Compute the order <code class="language-plaintext highlighter-rouge">n0</code> of the <code class="language-plaintext highlighter-rouge">leading term of the product</code> as the <code class="language-plaintext highlighter-rouge">sum of the orders</code> of the <code class="language-plaintext highlighter-rouge">leading terms of the factors</code>.</li>
<li>For each factor, compute <code class="language-plaintext highlighter-rouge">n - n0</code> terms of its series expansion (starting from its <code class="language-plaintext highlighter-rouge">leading term of order n1</code> and <code class="language-plaintext highlighter-rouge">ending at order n - n0 + n1</code>).</li>
<li>Multiply the expansions (<code class="language-plaintext highlighter-rouge">truncating at terms of order n</code>).</li>
</ul>
<p>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.
<br /><br /></p>
</li>
</ul>
</li>
<li>
<p><strong><a href="https://github.com/sympy/sympy/pull/19432">Used is_meromorphic() function to speed up limit evaluations</a></strong></p>
<ul>
<li>
<p>In this PR, we made use of the <code class="language-plaintext highlighter-rouge">is_meromorphic()</code> function of SymPy to speed up limit evaluations for certain type of cases.</p>
<p>A function is said to be <code class="language-plaintext highlighter-rouge">meromorphic</code> at a point, if at that point the <code class="language-plaintext highlighter-rouge">limit of the function exists but is infinite</code>.
In these cases, the value of the limit can usually be determined with the help of the <code class="language-plaintext highlighter-rouge">series expansion of that function</code> and
thus, there is no need to invoke the <code class="language-plaintext highlighter-rouge">Gruntz algorithm</code>.</p>
<p>While working on the implementation of this functionality, we required the <code class="language-plaintext highlighter-rouge">leading term</code> of the <code class="language-plaintext highlighter-rouge">series expansion of the function in the limit expression at the point at which the limit needs to be evaluated</code>.</p>
<p>But we came across a weird situation, where for some functions, we got <code class="language-plaintext highlighter-rouge">Complex Infinity</code> as the <code class="language-plaintext highlighter-rouge">leading term</code>.
Thus, we had to rectify the <code class="language-plaintext highlighter-rouge">_eval_as_leading_term()</code> methods of these functions (done in a separate <strong><a href="https://github.com/sympy/sympy/pull/19461">PR</a></strong>).</p>
<p>After resolving this issue, we succeeded in adding the required functionality and hence, increased the efficiency of the limit evaluation algorithm of SymPy.</p>
</li>
</ul>
</li>
</ul>
GSoC 2020 - Week 12020-05-24T00:00:00+00:00https://sachin-4099.github.io//GSoC-2020-Week-1<p>Key <code class="language-plaintext highlighter-rouge">highlights</code> of this week’s work are:</p>
<ul>
<li>
<p><strong><a href="https://github.com/sympy/sympy/pull/19292">Fixed incorrect limit evaluations caused due to different assumptions of the limit variable</a></strong></p>
<ul>
<li>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 <code class="language-plaintext highlighter-rouge">integer = True</code> was common between all the incorrectly evaluated limit expressions.
Thus, we concluded that the <code class="language-plaintext highlighter-rouge">Gruntz algorithm</code> is not able to correctly evaluate those expressions where the limit variable possesses <code class="language-plaintext highlighter-rouge">integer = True</code> property.
So, in order to get all the correct mathematical behaviour from the expression, we decided to define a dummy variable lacking <code class="language-plaintext highlighter-rouge">integer = True</code> 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.
<br /><br /></li>
</ul>
</li>
<li>
<p><strong><a href="https://github.com/sympy/sympy/pull/19297">Fixed incorrect limit evaluations caused due to bug in rewriting</a></strong></p>
<ul>
<li>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 <code class="language-plaintext highlighter-rouge">rewriting</code> of the expression was taking place incorrectly and we shifted our focus towards the <code class="language-plaintext highlighter-rouge">rewrite()</code> function.
Afterwards, it was pretty evident that the <code class="language-plaintext highlighter-rouge">xreplace()</code> function utilised for rewriting is not sufficient, as it did not find everything that needs to replaced.
Thus, replacing the <code class="language-plaintext highlighter-rouge">xreplace()</code> function with the <code class="language-plaintext highlighter-rouge">subs()</code> function helped us to resolve this issue.</li>
</ul>
</li>
</ul>
GSoC 2020 - Community Bonding Period2020-05-17T00:00:00+00:00https://sachin-4099.github.io//GSoC-2020-Community-Bonding-Period<p>The first part of my GSoC journey was the Community Bonding Period.</p>
<p>In this period, I mainly focussed on the following things:</p>
<ul>
<li>Setting up my blog, where I will provide weekly reports on the progress of my project, and synchronizing it with Planet SymPy.</li>
<li>Setting up a public gitter channel for discussions regarding the project.</li>
<li>Prioritising the issues to be solved.</li>
<li>Deciding the finer details of the workflow with my mentors and working out efficient ways to solve each particular issue.</li>
</ul>
<p>Since I have been contributing to SymPy for the past 8-9 months, it was easier for me to blend into the community.</p>
<p>Now, as everything has gone as planned, I have decided to make a head start and begin with the implementation of my project.</p>
GSoC 2020 Acceptance2020-05-07T00:00:00+00:00https://sachin-4099.github.io//GSoC-2020-with-sympy<p><img src="/public/gsoc.png" style="width:30%;height:30%;float:left;" />
<img src="/public/sympy.png" style="width:25%;height:25%;float:right;margin-right:100px;" /></p>
<p><br /><br /><br /><br /><br /><br /><br /><br /></p>
<p>The results of <strong><a href="https://summerofcode.withgoogle.com/organizations/4831132022996992/#5816442299088896">Google Summer of Code</a></strong> were out on 04 May 2020 and I am pleased to share with you that my proposal with <strong><a href="http://sympy.org">SymPy</a></strong> was accepted.</p>
<p>I would like to thank all the members of the organisation especially <a href="https://github.com/jksuom">Kalevi Suominen</a> for guiding me in my proposal and PR’s. I am really excited to work for such an amazing organization.</p>
<p>I will be working on my project, <a href="https://drive.google.com/file/d/1OgbnWLzQzaLfmmSM-fK09TCJmUzJ6tq4/view?usp=sharing">Amendments to Limit Evaluation and Series Expansion</a>, during a period of 3 months spanning from June to August, under the mentorship of <a href="https://github.com/jksuom">Kalevi Suominen</a> and <a href="https://github.com/leosartaj">Sartaj Singh</a>.</p>
<p>My primary focus will be to work on the <code class="language-plaintext highlighter-rouge">series</code> module and make it more robust as it is the backbone of all the limit evaluations performed by the library.</p>
<p>Looking forward for a really productive and wonderful summer ahead.</p>