Yathartha Joshi2022-01-21T19:50:20+00:00https://Yathartha22.github.io/Yathartha Joshiyathartha32@gmail.comGSoC 2018 - A Great Summer with SymPy2018-08-22T00:00:00+00:00https://Yathartha22.github.io//gsoc-conclusion<p>Today’s day started with receiving an email from Google. Here is a snapshot:</p>
<p><img src="/public/gsoc4.png" /></p>
<p>This left a big smile on my face 😄</p>
<p>The past 3-4 months have been amazing and I have learnt a lot during the course of time. I would like to thank <a href="https://github.com/asmeurer">Aaron</a>, <a href="https://github.com/certik">Ondrej</a> and the <a href="http://sympy.org">SymPy</a> team for providing me with this opportunity, my mentor <a href="https://github.com/aktech">Amit Kumar</a> for guiding me all through the phases and a special thanks to <a href="https://github.com/smichr">Chris</a> who was not officially my mentor but was present all the time for reviweing my work and helping me complete the project successfully.</p>
<p>Here is what Amit has to say:</p>
<p><img src="/public/gsoc5.png" /></p>
<p>Though GSoC is completed I will be continuing my contribution in the developement of the software.</p>
GSoC 2018 - Week 12 - Continuing with logarithmic solver and implementing lambert solver Part-II2018-08-09T00:00:00+00:00https://Yathartha22.github.io//gsoc-week-12<p>This week I continued the work with log solver and lambert solver. The log solver implementation is almost done with just few check for assumptions. Symbolic logarithmic equations should be dealt with proper assumptions. Such equations would give unsolved instance of <code class="language-plaintext highlighter-rouge">ConditionSet</code> otherwise.</p>
<div class="language-python highlighter-rouge"><div class="highlight"><pre class="highlight"><code>
<span class="o">>>></span> <span class="n">a</span><span class="p">,</span> <span class="n">b</span><span class="p">,</span> <span class="n">x</span> <span class="o">=</span> <span class="n">symbols</span><span class="p">(</span><span class="s">'a, b, x'</span><span class="p">)</span>
<span class="o">>>></span> <span class="n">solveset</span><span class="p">(</span><span class="n">a</span><span class="o">**</span><span class="n">x</span> <span class="o">-</span> <span class="n">b</span><span class="o">**</span><span class="p">(</span><span class="n">x</span> <span class="o">+</span> <span class="mi">1</span><span class="p">),</span> <span class="n">x</span><span class="p">,</span> <span class="n">S</span><span class="p">.</span><span class="n">Reals</span><span class="p">)</span>
<span class="n">ConditionSet</span><span class="p">(</span><span class="n">x</span><span class="p">,</span> <span class="n">Eq</span><span class="p">(</span><span class="n">a</span><span class="o">**</span><span class="n">x</span> <span class="o">-</span> <span class="n">b</span><span class="o">**</span><span class="p">(</span><span class="n">x</span> <span class="o">+</span> <span class="mi">1</span><span class="p">),</span> <span class="mi">0</span><span class="p">),</span> <span class="n">S</span><span class="p">.</span><span class="n">Reals</span><span class="p">)</span>
<span class="c1"># because the bases (here, `a and b`) should have a positive value > 0)
</span>
<span class="o">>>></span> <span class="n">a</span><span class="p">,</span> <span class="n">b</span> <span class="o">=</span> <span class="n">symbols</span><span class="p">(</span><span class="s">'a b'</span><span class="p">,</span> <span class="n">positive</span><span class="o">=</span><span class="bp">True</span><span class="p">)</span>
<span class="o">>>></span> <span class="n">solveset</span><span class="p">(</span><span class="n">a</span><span class="o">**</span><span class="n">x</span> <span class="o">-</span> <span class="n">b</span><span class="o">**</span><span class="p">(</span><span class="n">x</span> <span class="o">+</span> <span class="mi">1</span><span class="p">),</span> <span class="n">x</span><span class="p">,</span> <span class="n">S</span><span class="p">.</span><span class="n">Reals</span><span class="p">)</span>
<span class="p">{</span><span class="n">log</span><span class="p">(</span><span class="n">b</span><span class="p">)</span><span class="o">/</span><span class="p">(</span><span class="n">log</span><span class="p">(</span><span class="n">a</span><span class="p">)</span> <span class="o">-</span> <span class="n">log</span><span class="p">(</span><span class="n">b</span><span class="p">))}</span>
</code></pre></div></div>
<p>Discussions with Amit and Chris suggested that there should be some other way to handle vanilla symbols. There should be atleast a <code class="language-plaintext highlighter-rouge">ValueError</code> or something else that would tell the user why this cannot be solved. Chris suggested of returning a <code class="language-plaintext highlighter-rouge">Piecewise</code> as object for this scenario. Something like:</p>
<div class="language-python highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="n">cond</span> <span class="o">=</span> <span class="bp">True</span> <span class="k">if</span> <span class="n">fuzzy_and</span><span class="p">([</span><span class="n">a</span> <span class="o">></span> <span class="mi">0</span><span class="p">,</span> <span class="n">b</span> <span class="o">></span> <span class="mi">0</span><span class="p">,</span> <span class="n">Eq</span><span class="p">(</span><span class="n">im</span><span class="p">(</span><span class="n">f</span><span class="p">),</span> <span class="mi">0</span><span class="p">),</span> <span class="n">Eq</span><span class="p">(</span><span class="n">im</span><span class="p">(</span><span class="n">g</span><span class="p">),</span> <span class="mi">0</span><span class="p">)])</span> <span class="k">else</span> <span class="bp">False</span>
<span class="n">Piecewise</span><span class="p">((</span><span class="n">solutions</span><span class="p">,</span> <span class="n">cond</span><span class="p">),</span> <span class="n">ConditionSet</span><span class="p">(........),</span> <span class="bp">True</span><span class="p">))</span>
</code></pre></div></div>
<p>Using Piecewise was not the greatest of the option as:</p>
<ul>
<li>
<p>Though the assumptions were checked but it didn’t provided information to the user that why did it not solved.</p>
</li>
<li>
<p>Also using <code class="language-plaintext highlighter-rouge">Piecewise</code> had some problem causing recursion error, though it could be solved but it would make things unncessarily complicated.</p>
</li>
<li>
<p>Also <code class="language-plaintext highlighter-rouge">solveset</code> is not made to return objects other than <code class="language-plaintext highlighter-rouge">Sets</code>.</p>
</li>
</ul>
<p>So we switched to a completely different approach. We tried using a different type of <code class="language-plaintext highlighter-rouge">ConditionSet</code>: providing the information within it that is necessary for the equation to be solved. The approach was: <em>Force the equation to get solved but return a ConditionSet (a different than ususal) with the required assumptions, like:</em>
<code class="language-plaintext highlighter-rouge">ConditionSet(x, And(a_base>0, b_base>0, Eq(im(a_exp), 0), Eq((im(b_exp), 0))), {solutions})</code>. So now the above equation would return solutions something like:
<code class="language-plaintext highlighter-rouge">ConditionSet(x, (a > 0) & (b > 0), Intersection(Reals, {log(b)/(log(a) - log(b))}))</code></p>
<p>So this approach has been applied in the <a href="https://github.com/sympy/sympy/pull/14792">PR</a> as of now, only a few minor changes needs to be done. I will try to finish this by the end of the week.</p>
<p>Apart from this some work has been done in <code class="language-plaintext highlighter-rouge">lambert solver</code>:</p>
<ul>
<li>Used <code class="language-plaintext highlighter-rouge">_is_lambert</code> to identify lambert type equations.</li>
<li>Implemented bivariate solver (I will add a commit for this soon).</li>
<li>Ran <code class="language-plaintext highlighter-rouge">solve</code>’s tests, to get an idea of the extent to which <code class="language-plaintext highlighter-rouge">solveset</code> would handle such equations.</li>
</ul>
<p><strong>What’s next:</strong></p>
<p>I will try to wrap up the work of both the PR’s. Lambert solver PR would need a bit more time for reviewing but nevertheless I will be continuing its work post GSoC. Implementing these two solvers will make <code class="language-plaintext highlighter-rouge">solveset</code> fully functional to handle transcendental equations which is a major part of my GSoC propsal. There will be a few minor things left that I will try to finish post GSoC. Also since this is the last week for the coding period, I will be needing to submit a final report of my work, I will complete and submit it before the deadline.</p>
GSoC 2018 - Week 11 - Continuing with logarithmic solver and implementing lambert solver2018-07-29T00:00:00+00:00https://Yathartha22.github.io//gsoc-week-11<p>So this week I started up with implementing and sending a PR for lambert solver <a href="https://github.com/sympy/sympy/pull/14972">#14972</a>. Solving these equations can be achieved by <code class="language-plaintext highlighter-rouge">_solve_lambert</code> routine of <a href="https://github.com/sympy/sympy/blob/2b4afb6cd0a7cd5791d512b80fce493cda9b57e0/sympy/solvers/bivariate.py">bivariate.py</a>. It is really powerful and can solve a varied type of equations having a general form. Another routine comes into action, the <code class="language-plaintext highlighter-rouge">bivariate_type</code> to solve majorly lambert type of equations when the former is unable to solve. These two routines can be handy for implementing such equations. As of now I have added <code class="language-plaintext highlighter-rouge">_solve_lambert()</code> in the PR. I will add <code class="language-plaintext highlighter-rouge">bivariate_type</code> once the log solver PR gets finalised. There are few equations that can be solved by posifying the variable that needs to be solved. A bit discussion is needed on this part.</p>
<p>Apart from this, a lot of work was done in the <code class="language-plaintext highlighter-rouge">log solver</code> PR</p>
<ul>
<li>
<p><code class="language-plaintext highlighter-rouge">_term_factors()</code> is used again.</p>
</li>
<li>
<p>Logic for exponential identifying is modified to not identify lambert type equations</p>
</li>
<li>
<p>Few mores tests were added.</p>
</li>
<li>
<p><a href="https://github.com/smichr">Chris</a> advised to make identification helpers such that they identify their class even if they won’t get solved by their respective solvers, the equation should not be passed to any of the other helpers for further solving. This wasn’t the case before, the identifying helpers were implemented only for equations that their helpers could solve. So now this idea is implemented for both the exponential and logarithmic solver.
Equations that these identifiers can’t identify will be further solved as lambert type.</p>
</li>
</ul>
<p>Almost all the work of the log solver PR is done. I will be finishing the work on lambert solver PR and complete in coming week. I hope both the PR’s gets merged before the GSoC period ends.</p>
GSoC 2018 - Week 10 - Continuing with logarithmic solver2018-07-22T00:00:00+00:00https://Yathartha22.github.io//gsoc-week-10<p>This week started with the merge of the PR <a href="https://github.com/sympy/sympy/pull/14736">#14736</a>. Yehhhh!!!!!. So now <code class="language-plaintext highlighter-rouge">solveset</code> will be able to solve a varied type of exponential equations. Next work is going on to build the logarithmic and lambert solver.</p>
<p>A lot of discussion has been taken place over the implementation of the logarithmic solver, there were mainly two points to consider:</p>
<ul>
<li>How the logarithmic equation gets evaluated, i.e., should we consider solutions that would make the log term negative.</li>
</ul>
<p>Take for instance a logarithmic equation <code class="language-plaintext highlighter-rouge">log(x - 3) + log(x + 3) = 0</code>, when solved the solutions would be <code class="language-plaintext highlighter-rouge">-sqrt(10) and sqrt(10)</code>, but <code class="language-plaintext highlighter-rouge">-sqrt(10)</code> make the log term negative. So the question was what should we do for such a scenario? Should we add a check to remove these solution or just accept. it.</p>
<p>As of now as suggested by <a href="https://github.com/jksuom">Kalevi</a> and <a href="https://github.com/asmeurer">Aaron</a> we should focus on the liberal interpratation for evaluating equations: if an expression can be written in its equivalent form and makes sense then we can consider solutions of this equivalent form. Therefore both the above solutions are acceptable.</p>
<ul>
<li>How the identification of the logarithmic equations would take place.</li>
</ul>
<p>The identification of logarithmic type is another question and is still yet to be agreed upon. At first the implementation was done by extracting each term of the expression and see if it has <code class="language-plaintext highlighter-rouge">log</code> terms in it, this wasn’t the best of the method as we are trying to identify a large class of logarithmic equation while solving is done only for a subset of those equations (only those that can be reduced by <code class="language-plaintext highlighter-rouge">logcombine</code>). So Amit and Chris stressed upon making the logarithmic identification for equations that its solver would solve. So as of now I have made changes accordingly.</p>
<p>Another problem that this PR is facing is of the infinite recursion. The equations that both exponential and logarithmic can’t solve but still their respective solver try to handle gets into infinite recursion. One way (though not appropriate) is to use <code class="language-plaintext highlighter-rouge">flags</code> like in <code class="language-plaintext highlighter-rouge">solve</code>, using this would remove the infinite recursion but is not the best way to handle, therefore I am looking into ways on how to get this fixed.</p>
<p>Apart from the work on log solver, I did some work on lambert solver- how the implementation would go, ran all the tests of <code class="language-plaintext highlighter-rouge">solve</code>, differentiated the tests that <code class="language-plaintext highlighter-rouge">_solve_lambert</code> could solve and that <code class="language-plaintext highlighter-rouge">bivariate_type</code> would. I will be adding a PR for this in a day or so.</p>
<p>Next week goals:</p>
<ul>
<li>
<p>Finish things with logarithmic solver</p>
</li>
<li>
<p>Sending a PR for lambert solver and try to finish its work as quickly as possible.</p>
</li>
</ul>
GSoC 2018 - Week 9 - Starting up with Lambert equations2018-07-13T00:00:00+00:00https://Yathartha22.github.io//gsoc-week-9<p>At the start of the week I worked on the leftovers of week 8:</p>
<ul>
<li>added <code class="language-plaintext highlighter-rouge">log_singularities()</code> that will help in determining logarithmic singularities,</li>
<li>improved documentation of all helpers as suggested by Amit to maintain consistency</li>
</ul>
<p>Status of the PR’s:</p>
<p>PR <a href="https://github.com/sympy/sympy/pull/14736">#14736</a> is ready to be merged.</p>
<p>PR <a href="https://github.com/sympy/sympy/pull/14792">#14792</a> is being worked on. Major tasks has been completed, just review and refining has to be done.</p>
<p>Apart from this I started working on the way Lambert type equations can be solved through <code class="language-plaintext highlighter-rouge">_transolve()</code>. I looked into <code class="language-plaintext highlighter-rouge">_tsolve's</code> way of handling such equations.
For solving Lambert type equations <code class="language-plaintext highlighter-rouge">_tsolve()</code> largely depends on <code class="language-plaintext highlighter-rouge">bivariate.py</code>. It takes help of the different utility functions implemented there.
Of them two important are <code class="language-plaintext highlighter-rouge">_solve_lambert()</code> and <code class="language-plaintext highlighter-rouge">bivariate_type()</code>. These two helpers help in getting the equations evaluated.</p>
<p>Equations that can be written in the standard form as: <code class="language-plaintext highlighter-rouge">A + B*x + C*log(D + E*x) = 0</code> has the solutions in terms of <code class="language-plaintext highlighter-rouge">Lambert</code> function as:</p>
<p><code class="language-plaintext highlighter-rouge">D/E + C*B*W(t) with (B/C*E)*exp((BD - AE)/CE)</code></p>
<p>This is what <code class="language-plaintext highlighter-rouge">_solve_lambert()</code> determines and accordingly returns the solutions, otherwise returns a <code class="language-plaintext highlighter-rouge">NotImplementedError</code></p>
<p>If <code class="language-plaintext highlighter-rouge">_solve_lambert()</code> is unable to handle <code class="language-plaintext highlighter-rouge">bivariate_type()</code> is tried. This function first tries to identify the type of composite bivariate and then substitutes <code class="language-plaintext highlighter-rouge">Dummy</code> in place of them. For eq: <code class="language-plaintext highlighter-rouge">(x + y)**2 - 3</code> would become <code class="language-plaintext highlighter-rouge">_u**2 - 3</code> where <code class="language-plaintext highlighter-rouge">_u</code> is the dummy variable. The idea is that solving the latter equation for <code class="language-plaintext highlighter-rouge">u</code> and then equating the solutions to the former equation is equivalent for solving the original one.</p>
<p>While implementing in <code class="language-plaintext highlighter-rouge">_transolve</code> this philosophy needs to be applied. As of now I have looked into different tests on how they behave. I will start implementing it next.</p>
<p>Next week’s plan:</p>
<ul>
<li>
<p>Finishing with the logsolver</p>
</li>
<li>
<p>Implementing lambert solver.</p>
</li>
</ul>
GSoC 2018 - Week 8 - Improving solving of logarithmic equations2018-07-08T00:00:00+00:00https://Yathartha22.github.io//gsoc-week-8<p>Before the start of the week Amit and I discussed on a few points on:</p>
<p><strong>Note</strong>: <code class="language-plaintext highlighter-rouge">is_logarithmic()</code> is an identifier helper for <code class="language-plaintext highlighter-rouge">_transolve</code> to determine whether the expression is logarithmic or not.
and <code class="language-plaintext highlighter-rouge">_solve_log()</code> is a solving helper that returns the equation in a tractable form for <code class="language-plaintext highlighter-rouge">solveset</code> to better handle.</p>
<ul>
<li>What should <code class="language-plaintext highlighter-rouge">is_logarithmic()</code> return?</li>
</ul>
<p>While designing the method at first it returned a <code class="language-plaintext highlighter-rouge">logcombined</code> equation if found to be logarithmic, but we agreed upon having consistency among all the identifying helpers to return either <code class="language-plaintext highlighter-rouge">True</code> or <code class="language-plaintext highlighter-rouge">False</code>.</p>
<ul>
<li>How <code class="language-plaintext highlighter-rouge">_is_logarithmic()</code> should work?</li>
</ul>
<p>Next question was how it should work. We can implement it in two ways either to make the <code class="language-plaintext highlighter-rouge">logcombined</code> equation, if the expression reduces, it is obviously a logarithmic equation otherwise not. We also need to check whether the equation reduced has the variable to be solved in its <code class="language-plaintext highlighter-rouge">free_symbols</code>
But <code class="language-plaintext highlighter-rouge">logcombine</code> possessed a problem that it unknowingly manipulates the equation, like <code class="language-plaintext highlighter-rouge">log(x) - log(2*x)</code> would reduce to <code class="language-plaintext highlighter-rouge">log(1/2)</code> for which the routine would return <code class="language-plaintext highlighter-rouge">False</code> as there are no symbol involved. So a more better way needs to be implemented.</p>
<ul>
<li>How <code class="language-plaintext highlighter-rouge">_solve_log()</code> will handle removing unwanted solutions?</li>
</ul>
<p>Simply reducing the logarithmic equation to a tractable form for <code class="language-plaintext highlighter-rouge">solveset</code> to handle would cause spurious solutions in the result. Therefore it becomes necessary to remove them. Take for example: <code class="language-plaintext highlighter-rouge">solveset</code> gives the result of <code class="language-plaintext highlighter-rouge">log(x - 3) + log(x + 3)</code> as <code class="language-plaintext highlighter-rouge">{-sqrt(10), sqrt(10)}</code>, but <code class="language-plaintext highlighter-rouge">-sqrt(10)</code> is not the solution in <code class="language-plaintext highlighter-rouge">Real</code> domain. Therefore one way to remove it was using <code class="language-plaintext highlighter-rouge">checksol</code>. Amit suggested on to have a look over the singularities and try incorporating the check in <code class="language-plaintext highlighter-rouge">_solveset</code>.</p>
<p>Things that I did during the week:</p>
<ul>
<li>improved <code class="language-plaintext highlighter-rouge">is_logarithmic()</code></li>
</ul>
<p>Removed the <code class="language-plaintext highlighter-rouge">logcombine</code> way of checking the equation. As of now the <code class="language-plaintext highlighter-rouge">_is_logarithm</code> checks for every term to be logarithmic in terms of the variable to be solved, if so it returns <code class="language-plaintext highlighter-rouge">True</code> otherwise <code class="language-plaintext highlighter-rouge">False</code></p>
<ul>
<li>improved the <code class="language-plaintext highlighter-rouge">_solve_log()</code></li>
</ul>
<p>As per the current documentation of <code class="language-plaintext highlighter-rouge">_transolve</code> this routine is improved to return a modified form of the equation that <code class="language-plaintext highlighter-rouge">solveset</code> could better handle. Checking of the spurious solutions will take place in <code class="language-plaintext highlighter-rouge">solveset</code> itself.</p>
<ul>
<li>Way to remove spurious solutions</li>
</ul>
<p>To handle this scenario I have added a <a href="https://github.com/sympy/sympy/pull/14792/files#diff-eec0422923e8f100745c015cd8fdd6cfR985">check</a> in <code class="language-plaintext highlighter-rouge">_solveset</code> specifically for logarithmic equations to remove spurious solutions.
The idea is based on the fact that natural log in undefined for negative and zero value, therefore this method gets each term of the expression, substitutes each solution to every term one by one and if for any term the value isn’t real that solution will not be included.</p>
<p>Why <code class="language-plaintext highlighter-rouge">checksol()</code> is not the appropriate way?</p>
<p>At first I thought of using the <code class="language-plaintext highlighter-rouge">checksol()</code>, but it possessed a problem. <code class="language-plaintext highlighter-rouge">checksol</code> unintensionally allows wrong solution to creep in. Take for example <code class="language-plaintext highlighter-rouge">log(3*x) - log(-x + 1) - log(4*x + 1)</code>, <code class="language-plaintext highlighter-rouge">solveset</code> would give <code class="language-plaintext highlighter-rouge">-1/2 and 1/2</code> as the solutions but the former isn’t a solution in real domain. Using <code class="language-plaintext highlighter-rouge">checksol</code> would not remove this as <code class="language-plaintext highlighter-rouge">I*pi</code> gets cancelled out during evaluating the expression therefore it returns <code class="language-plaintext highlighter-rouge">True</code>, which is not correct.</p>
<ul>
<li>Addressing comments</li>
</ul>
<p>Apart from this few changes have been done in the <code class="language-plaintext highlighter-rouge">_transolve</code> <a href="https://github.com/sympy/sympy/pull/14736">PR</a>:</p>
<ul>
<li>
<p>I have added a method that would return all the terms present in the expression: <a href="https://github.com/sympy/sympy/pull/14736/files#diff-eec0422923e8f100745c015cd8fdd6cfR988">make_expr_args()</a></p>
</li>
<li>
<p>Made the expresssion remain unevaluated when doing <a href="https://github.com/sympy/sympy/pull/14736/files#diff-eec0422923e8f100745c015cd8fdd6cfR1299">lhs - rhs</a> within <code class="language-plaintext highlighter-rouge">_transolve</code>.</p>
</li>
</ul>
<p>Read this <a href="http://localhost:4000/gsoc-week-5">blog</a> for better understanding of logarithmic solving.</p>
GSoC 2018 - Week 7 - Continuing with transolve Part-IV2018-07-01T00:00:00+00:00https://Yathartha22.github.io//gsoc-week-7<p>This week I continued to work on finalising the design of the <code class="language-plaintext highlighter-rouge">_transolve</code>. Following were the things discussed and implemented:</p>
<ul>
<li>
<p>The loop over the <code class="language-plaintext highlighter-rouge">rhs_s</code> was removed because <code class="language-plaintext highlighter-rouge">solveset</code> already has a loop and since <code class="language-plaintext highlighter-rouge">_transolve</code> is called within the loop therefore there won’t be a case where there would be more than one argument in <code class="language-plaintext highlighter-rouge">rhs_s</code> inside <code class="language-plaintext highlighter-rouge">_transolve</code>.</p>
</li>
<li>
<p><code class="language-plaintext highlighter-rouge">pow_type()</code> was created to handle power type equations in <code class="language-plaintext highlighter-rouge">_transolve</code> but it turns out that power type equations will be handled in the <code class="language-plaintext highlighter-rouge">_invert()</code> itself, so it was repetitive to add again.</p>
</li>
<li>
<p>The names of the solving helpers were improved to <code class="language-plaintext highlighter-rouge">_solve_class</code> from the previous <code class="language-plaintext highlighter-rouge">_class_solver</code>.</p>
</li>
<li>
<p>Discussions with Amit and Chris led to the conclusion that <code class="language-plaintext highlighter-rouge">_transolve</code> should be completely made an internal function of <code class="language-plaintext highlighter-rouge">solveset</code>, i.e. it should not be used as an independent function. At first the thought was that it can be used as an independent function, but this created a problem of the code being repeated as that of <code class="language-plaintext highlighter-rouge">solveset</code>, so Chris suggested that <code class="language-plaintext highlighter-rouge">_transolve</code> should raise an error for equations that <code class="language-plaintext highlighter-rouge">solveset</code> can handle, but again this created problem, it would make unnnecessary complications in the code as we need to be very specific as to when and where raise an error.</p>
</li>
<li>
<p>We decided to have same arguments for all the helpers. Be it identification or solving helper, both will take the equation and the variable as their arguments, with the choice that the helper can ignore to use any of the argument if not needed.</p>
</li>
<li>
<p>There were a lot of improvement in the documentation as the design changed.</p>
</li>
</ul>
<p>Apart from these changes work in implementing <code class="language-plaintext highlighter-rouge">log solver</code> is going on in parallel.</p>
GSoC 2018 - Week 6 - Continuing with transolve Part-III2018-06-23T00:00:00+00:00https://Yathartha22.github.io//gsoc-week-6<p>For the sixth week, I started working on a few things as per the discussions with Amit:</p>
<ul>
<li>Improving the API of <code class="language-plaintext highlighter-rouge">transolve</code>.</li>
</ul>
<p>As <code class="language-plaintext highlighter-rouge">transolve</code> grew over the past few weeks the API became a bit messy, which was against the plan. So Amit suggested on to work on it to make it look clean. For this I added two internal functions <code class="language-plaintext highlighter-rouge">add_type()</code> and <code class="language-plaintext highlighter-rouge">pow_type()</code>, to handle expressions having <code class="language-plaintext highlighter-rouge">add</code> or <code class="language-plaintext highlighter-rouge">power</code> terms respectively. This could help us in achieving what we planned of: making the API extensible without it getting affected from the changes done in the function itself. If new solvers are to be added the modifcation has to be done in either of the internal functions.</p>
<ul>
<li>Improved the working of <code class="language-plaintext highlighter-rouge">_check_expo</code>.</li>
</ul>
<p>The implementation of the <code class="language-plaintext highlighter-rouge">check_expo</code> had a probelm, of not being generalised, only equations having two terms were checked. So the task was to make it generalised, so I implemented it using <a href="http://docs.sympy.org/latest/modules/core.html#atom">atoms</a>, filtered the equations having <code class="language-plaintext highlighter-rouge">Pow</code> or <code class="language-plaintext highlighter-rouge">exp</code> with the help of <code class="language-plaintext highlighter-rouge">.atoms()</code> and then checked whether the variable that needs to be solved is present in the exponent or not but this too possesed a problem: asking for atoms was not a great choice as they can come from anywhere like <code class="language-plaintext highlighter-rouge">cos(2**x).atoms(Pow, exp)</code> would give <code class="language-plaintext highlighter-rouge">2**x</code> and consequently the helper would return <code class="language-plaintext highlighter-rouge">True</code>, which is wrong. For this <a href="https://github.com/smichr">smichr</a> suggested even better method of using <a href="https://github.com/sympy/sympy/blob/master/sympy/core/operations.py#L344">.make_args()</a>. We will seperate out all the <code class="language-plaintext highlighter-rouge">Add</code> arguments and then in each of them we will look for <code class="language-plaintext highlighter-rouge">Mul</code> arguments which will give us the atomic argument of the expression, now this term can be tested to have variable in the exponent.</p>
<ul>
<li>Changes in the documentation</li>
</ul>
<p>Also there were a few things that needed to fixed in the documentation. The docstring of <code class="language-plaintext highlighter-rouge">expo_solver</code> and <code class="language-plaintext highlighter-rouge">check_expo</code> were improved. Few changes were also done in <code class="language-plaintext highlighter-rouge">transolve's</code> documentation.</p>
<ul>
<li>Worked on improvement of <code class="language-plaintext highlighter-rouge">log solver</code></li>
</ul>
<p>Apart from this I did some improvement in <code class="language-plaintext highlighter-rouge">check_log</code> to handle corner cases. As per the current logic <code class="language-plaintext highlighter-rouge">check_log</code> would return a “<em>logcombined</em>” equation to be further solved by <code class="language-plaintext highlighter-rouge">log_solver</code>, but this lead to a problem that the some equation (<code class="language-plaintext highlighter-rouge">log(x**y) - y*log(x)</code>) might get reduced to <code class="language-plaintext highlighter-rouge">0</code> and the check would fail, therefore this was handled by improving the condition as <code class="language-plaintext highlighter-rouge">if condition not False</code>. Apart from this single term expression needs to be properly handled.</p>
<p>Also I started getting familiar with <code class="language-plaintext highlighter-rouge">lambert</code> equations.</p>
<p>So these were the things that I worked on this week. The PR needs a bit more improvement to get merged, I will try to get it finished by mid of the coming week and start working on implementation of other solvers.</p>
GSoC 2018 - Week 5 - Implementing log solver2018-06-17T00:00:00+00:00https://Yathartha22.github.io//gsoc-week-5<p>So this is the last week of the first evaluation. I started with implementing log solver as part of <code class="language-plaintext highlighter-rouge">transolve</code>. As per the documentation of the <code class="language-plaintext highlighter-rouge">transolve</code> we will need two helpers for implementing log solver, <code class="language-plaintext highlighter-rouge">check_log</code> that will check whether the equation is logarithmic or not and <code class="language-plaintext highlighter-rouge">log_solver</code> that will solve the equation. Here’s the <a href="https://github.com/sympy/sympy/pull/14792">PR</a></p>
<p><strong>Idea behind <code class="language-plaintext highlighter-rouge">check_log</code></strong></p>
<p>Heuristic is implemented to determine whether the equation is logarithmic or not. According to it the logarithmic equations can be reduced to simpler form using log identities. For this purpose we use SymPy’s function <a href="http://docs.sympy.org/latest/tutorial/simplification.html#logcombine">logcombine</a>. If the equation is logarithmic it will be reduced and hence the number of log in the original and modified equation may differ. This will ensure that the equation is logarithmic.</p>
<p><strong>Idea behind the log solver</strong></p>
<p>The idea is simple, the reduced form from the <code class="language-plaintext highlighter-rouge">check_log</code> is used as the new target equation and is sent to <code class="language-plaintext highlighter-rouge">solveset</code> to handle. Solutions are retuned from <code class="language-plaintext highlighter-rouge">solveset</code>, but it may contain values that won’t satisfy the equation (log does not take negative values in real domain). Therfore to remove unwanted values we use <a href="http://docs.sympy.org/latest/modules/solvers/solvers.html#sympy.solvers.solvers.checksol">checksol</a> function of solve module which substitutes each solution in the equation and returns <code class="language-plaintext highlighter-rouge">True</code> if it satisfies otherwise <code class="language-plaintext highlighter-rouge">False</code>.</p>
<p>Apart from implementing helpers, I have added their documentation. Certain things needs to be done before the PR is ready for review: Tests needs to be added for the helpers and <code class="language-plaintext highlighter-rouge">check_log</code> needs to be improved a bit to handle corner cases.</p>
<p>In parallel I am also working on improving <code class="language-plaintext highlighter-rouge">transolve's</code> PR to make it merge as soon as possible. After these two gets completely fixed we will be focusing on implementing <code class="language-plaintext highlighter-rouge">lambert equation solver</code>.</p>
<p>In the coming week I will be focussing on finishing off the work of these two PR.</p>
GSoC 2018 - Week 4 - Continuing with transolve Part-II2018-06-09T00:00:00+00:00https://Yathartha22.github.io//gsoc-week-4<p>By the end of the previous week I had completed majority of the TODO’s of the <a href="https://github.com/sympy/sympy/pull/14736/">PR #14736</a>.
This week I started on minor improvements suggested by Amit. This included:</p>
<ul>
<li>
<p>Minor Documentation changes<br />
Included proof of correctness, typo fixes, rephrasing lines etc.</p>
</li>
<li>
<p>Removing <code class="language-plaintext highlighter-rouge">flag</code> variable from transolve.<br />
<code class="language-plaintext highlighter-rouge">flag</code> variable was passed as a function parameter in <code class="language-plaintext highlighter-rouge">transolve</code> and was used to check on the recursive call. The thought was that there might be a case when equation could not be solved by any of the helpers but during the process the equation might get modified, so we wanted to double check whether the modified equation could be solved again, thats why we used <code class="language-plaintext highlighter-rouge">flag</code> but Amit suggested on removing it as there wasn’t a case as of now and it will only make things unnecessarily complicated.</p>
</li>
<li>
<p>Also worked on XFAILS, mainly on solving equations containing only symbols. There was an exception raised in <code class="language-plaintext highlighter-rouge">_invert_real</code>, because of a relational comparison made with <code class="language-plaintext highlighter-rouge">0</code> which caused the faiure of the tests. It has been fixed by handling the exception.</p>
</li>
<li>
<p>Imported tests of log and lambert.</p>
</li>
<li>
<p>Another thing we discussed was about log solver. The helpers for solving logarithmic equations will be implemented in a seperated PR, to make the review and implementing task easy and independent.</p>
</li>
</ul>
<p>After this I started a working on solving exponential equations in complex domain, though it turns out that we will be focussing on only the real domain as of now. But I have added tests for it as XFAIL.<br />
To make exponents work in complex domain, we require the <a href="https://en.wikipedia.org/wiki/Complex_logarithm">complex logarithm</a>.
If we have equation as</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code> z = e**w,
where w is complex number and z is non-zero complex number,
then
Ln(z) = ln|z| + I*(Arg(z) + 2*n*pi)
where Ln(z) is the complex logarithm and ln|z| is the
logarithm evaluated with real number argument.
</code></pre></div></div>
<p>Apart from this we also had a meeting yesterday in which we discussed about how we will be wrapping up things before the first evaluation.<br />
I will be completing few leftovers of the current PR to make it merge and start working on implementing log solver (making a commit probably by tomorrow).</p>
<p>Amit also suggested on creating a coverage report so as to get an idea about the amount of tests covered by the code. The current coverage report can be found <a href="/covhtml/sympy_solvers_solveset_py.html">here</a>. Other than this he also advised on reading <a href="https://www.investigatii.md/uploads/resurse/Clean_Code.pdf">Clean Code</a> by <code class="language-plaintext highlighter-rouge">Robert C. Martin</code> which will help me improve in writing clean and efficient code.</p>
<p>The main target for the coming week will be merging <code class="language-plaintext highlighter-rouge">PR #14736</code>, implementing <code class="language-plaintext highlighter-rouge">log solver</code> (will try to merge this as well), starting with implementing <code class="language-plaintext highlighter-rouge">lambert solver</code> (try to add atleast a WIP PR) and reading the book.</p>
<p>Hope things go as planned!!</p>
GSoC 2018 - Week 3 - Continuing with transolve2018-06-02T00:00:00+00:00https://Yathartha22.github.io//gsoc-week-3<p>I continued my work of week 2 in this week as well. Though I was travelling for 2-3 days, I was able to give most of the hours to the work dedicated for this week. I had to add a detailed descriptive documentation for <code class="language-plaintext highlighter-rouge">transolve</code>, for this I read documentation of the <code class="language-plaintext highlighter-rouge">ode</code> module as Amit and Harsh suggested, apart from this I read several other documentation of sympy modules. Made a commit regarding this in the <a href="https://github.com/sympy/sympy/pull/14736/">PR</a>.</p>
<p>As of now transolve supports solving majority of exponential equations.
I have also imported exponential tests of solve and added a few of mine. Some of them needs another look, I have added them to <code class="language-plaintext highlighter-rouge">XFAIL</code> as of now. I am working on these tests to pass. Also done minor changes in the function, like removed <code class="language-plaintext highlighter-rouge">force=True</code> option from <code class="language-plaintext highlighter-rouge">expand_log</code> because using this option is not a healthy choice as the function expands logarithm without considering the assumptions (for exponents the variable should be real) which may sometime get a wrong result.</p>
<p><strong>Idea behind <code class="language-plaintext highlighter-rouge">transolve</code></strong></p>
<p>The idea is simple, we are mainly focusing on making it modular and extensible. So to achieve this different identifying and solving helpers will be implemented that will identify the type of equation and then solve it. For detailed information refer to the <a href="https://github.com/sympy/sympy/pull/14736/">PR</a></p>
<p><strong>Idea behind <code class="language-plaintext highlighter-rouge">exponential solver</code></strong></p>
<p>Exponential equations are solved by using logarithms. Currently the <code class="language-plaintext highlighter-rouge">expo_solver</code> reduces the equation to log form which can further be handled by solveset itself. For this purpose <a href="http://docs.sympy.org/latest/tutorial/simplification.html#expand-log">expand_log</a> function of sympy is used which reduces the equation using log identities.
Take for example a simple exponential equation <code class="language-plaintext highlighter-rouge">3**(2*x) - 2**(x + 3)</code>, this equation can be reduced to <code class="language-plaintext highlighter-rouge">2*x*log(3) - (x+3)*log(2)</code>, this type of equation is easily solvable by <code class="language-plaintext highlighter-rouge">solveset</code>.</p>
<p>Once we approve on the documentation and the working of exponential solver I will proceed to implement logarithmic solver (probably in the coming week).</p>
<p>Hope things go as planned!!</p>
GSoC 2018 - Week 2 - Getting started with transolve2018-05-27T00:00:00+00:00https://Yathartha22.github.io//gsoc-week-2<p>So this is the end of the second week of GSoC and I am still working on implementing and improving <code class="language-plaintext highlighter-rouge">transolve</code>. In the previous week Amit and I discussed about the things that are necessary for implementing <code class="language-plaintext highlighter-rouge">transolve</code>. I have covered it in the previous <a href="https://yathartha22.github.io//gsoc-week-1">blog post</a>. Based on the discussions I have a submitted a WIP PR <a href="https://github.com/sympy/sympy/pull/14736">here</a>.</p>
<p>In the second meeting we had <a href="https://github.com/hargup">Harsh</a> joining us to the discussion.</p>
<p>Amit and Harsh stressed on making transolve modular and extensilbe, unlike <code class="language-plaintext highlighter-rouge">_tsolve</code> which lacks these features (though it is very powerful).</p>
<p>So there are few things that <code class="language-plaintext highlighter-rouge">transolve</code> should have:</p>
<ul>
<li>Proper documentation</li>
</ul>
<p>Documentation is always a very important aspect of any software. Therefore to make it easy to understand to the users, transolve needs to have a proper descriptive documentation that should explain why, what and how of transolve. Amit suggested on covering every detail of the working of function. It should cover the following:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>- What is transolve.
- How to use transolve.
- Why it is better than `_tsolve`.
- How equations are solved.
- How to add a new class of equations.
</code></pre></div></div>
<ul>
<li>Extensibility</li>
</ul>
<p><code class="language-plaintext highlighter-rouge">transolve</code> should be extensible, i.e. the design of the API should be such that it becomes easy to add a new class of equation solver without affecting the structure of the function.
The idea to make this happen is to have a two step procedure of equation solving. <code class="language-plaintext highlighter-rouge">transolve</code> will solve any equation by first identifying the class of the equations (a helper will do that) and then calling another helper to solve that equation. So in this way one needs to figure out how to identify the equation and how to solve it. Once this is done he just needs to invoke the helpers at the proper location in transolve.</p>
<ul>
<li>Modularity</li>
</ul>
<p>As it is clear from the above point, <code class="language-plaintext highlighter-rouge">transolve</code> will have two step procedure for solving different classes of equations. Helper function needs to be implemented for identification and solving equations. This will make <code class="language-plaintext highlighter-rouge">transolve</code> modular as solving equations will not depend on the main function.</p>
<ul>
<li>Proof of correctness</li>
</ul>
<p>Since identification and solving equations will be achieved with few heuristics/algorithms. There should be a proper document of its prof of correctness. I will be adding proper documentation with examples explaining its authenticity.</p>
<p>Apart from this Amit also adviced on reading documentation of <a href="https://github.com/sympy/sympy/blob/master/sympy/solvers/ode.py">ode</a> module so as to get an idea, also importing tests from solve, making it atleast as powerful as _tsolve will be other things that needs care.</p>
<p>I will be focussing on completing it by this week!!</p>
GSoC 2018 - Week 1 - Starting up2018-05-20T00:00:00+00:00https://Yathartha22.github.io//gsoc-week-1<p>So the coding period started from 14 May 2018. So most of the days of the first week I spent was giving final exams and travelling. But now everything is over and I will be spending most of the time implementing what I have proposed for the first evaluations. I had a meeting with Amit during the community bonding period where we discussed :</p>
<ul>
<li>
<p>Schedule and frequency of meetings.</p>
</li>
<li>
<p>How to proceed with implementing transolve, documenting and writing tests for it.</p>
</li>
</ul>
<p>As of now I have looked few things:</p>
<ul>
<li>
<p>How <code class="language-plaintext highlighter-rouge">_tsolve</code> works in <code class="language-plaintext highlighter-rouge">solve</code>.</p>
</li>
<li>
<p>How exponential and logarithmic equations are solved.</p>
</li>
<li>
<p>Filtering out the tests for the above.</p>
</li>
<li>
<p>Figuring out how the API would look like.</p>
</li>
<li>
<p>What will be the flow of <code class="language-plaintext highlighter-rouge">transolve</code>.</p>
</li>
</ul>
<p>The last two points needs more discussions and planning. In the coming week I will try to figure it out by dicussing it with Amit and by the end I will try to make an initial commit to <code class="language-plaintext highlighter-rouge">transolve</code>.</p>
<p>Hope I execute the plan well!!</p>
Got Selectd in GSoC2018-04-29T00:00:00+00:00https://Yathartha22.github.io//gsoc-selection<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 />
Sorry for the late post!!</p>
<p>The results of <strong><a href="https://summerofcode.withgoogle.com/organizations/5583344046178304/#6097058637807616">Google Summer of Code</a></strong> were out on 23 April 2018 and guess what I got selected and will be working under <strong><a href="http://sympy.org">Sympy</a></strong> for the next 3 months. I will be working on my project, <a href="https://docs.google.com/document/d/1kcZCdQuY3XxgHPuSA8vvwc6O8AbVZ-nYskMuXIia9hA/edit?usp=sharing">Solvers: Completing Solveset</a>, during this period. I am really excited to work with such an amazing organization. I would like to thank all the mentors especially <a href="https://github.com/asmeurer">Aaron Meurer</a>, <a href="https://github.com/smichr">Christopher Smith</a>, <a href="https://github.com/aktech">Amit Kumar</a> and <a href="https://github.com/jksuom">Kalevi Suominen</a> for guiding me in my proposal and PR’s. My official mentor will be <strong>Amit Kumar</strong>.</p>
<p>The first phase is the <em>Community Bonding Period</em>, I will focussing on the following things before the coding period begans.</p>
<ul>
<li>
<p>Setting up blog and synchronizing it with planet sympy.</p>
</li>
<li>
<p>Discussing possible means of communication, weekly meetings etc.</p>
</li>
<li>
<p>Planning the implementation of the project with Amit.</p>
</li>
<li>
<p>Familiarizing with the codebase of Sympy and see how it may help solving the problems while implementing the project.</p>
</li>
</ul>
<p>I will be having my end sems and practicals during this period but I will try to accomplish the above tasks whenever I get time.</p>
<p>Looking forward for a wonderful summer ahead 😄 !!</p>