Planet SymPy
http://planet.sympy.org/
enPlanet SymPy - http://planet.sympy.org/http://nesar2017.wordpress.com/?p=342Abdullah Javed Nesar (Abdullahjavednesar)Abdullah Javed Nesar (Abdullahjavednesar): GSoC Progress ReportSun, 13 Aug 2017 16:15:12 GMT
https://nesar2017.wordpress.com/2017/08/13/gsoc-progress-report-5/
<p>Hi all, sorry for the delay. We have added test suit 1.2 successfully, This week we will complete implementing all tests for expressions involving products of powers of linears. I have completed parsing test suits for quadratic but implementation is yet to do.  There are about 5-6 Utility functions which are left and are difficult to implement using SymPy’s pattern matcher but, I’ll try to implement those as soon as possible. There were few failing test cases for <code class="highlighter-rouge">PowerVariableDegree</code> I’ve fixed those.</p><br /> <a href="http://feeds.wordpress.com/1.0/gocomments/nesar2017.wordpress.com/342/" rel="nofollow"><img alt="" border="0" src="http://feeds.wordpress.com/1.0/comments/nesar2017.wordpress.com/342/" /></a> <img alt="" border="0" height="1" src="https://pixel.wp.com/b.gif?host=nesar2017.wordpress.com&blog=126779945&post=342&subd=nesar2017&ref=&feed=1" width="1" />http://arif7blog.wordpress.com/?p=711Arif Ahmed (ArifAhmed1995)Arif Ahmed (ArifAhmed1995): Week 10 Report(August 4 – August 10) : More functionality for 3D case.Thu, 10 Aug 2017 20:12:47 GMT
https://arif7blog.wordpress.com/2017/08/10/week-10-reportaugust-4-august-10-more-functionality-for-3d-case/
<p>This week I continued work on<span style="color: #00ff00;"> <a href="https://github.com/sympy/sympy/pull/13082" rel="noopener" target="_blank">PR#13082</a></span>. The last implementation left for the 3D case is the hyperplane representation. For example, the user can express the list of facets of the polytope by a list of points for each facet or a list of hyperplane parameters(a tuple for each facet).</p>
<pre><code>p1 = [(0, 1, 0), (1, 0, 0), (0, 0, 0)]
p2 = [([-1, 0, 0], 0), ([1, 1, 0], 1), ([0, -1, 0], 0)]</code></pre>
<p>The code should be able to figure out what the points are and then pass on that list of points representation to the rest of the other functions. I should be done with this in a day or two. To finish up the work for GSoC I’ll get the <span style="color: #00ff00;"><a href="https://github.com/sympy/sympy/pull/12931" rel="noopener" target="_blank">PR on intersecting polygons</a></span> sorted out. After that, remaining documentation will have to be written and requisite clean-up to be done.</p><br /> <a href="http://feeds.wordpress.com/1.0/gocomments/arif7blog.wordpress.com/711/" rel="nofollow"><img alt="" border="0" src="http://feeds.wordpress.com/1.0/comments/arif7blog.wordpress.com/711/" /></a> <img alt="" border="0" height="1" src="https://pixel.wp.com/b.gif?host=arif7blog.wordpress.com&blog=126429718&post=711&subd=arif7blog&ref=&feed=1" width="1" />https://szymag.github.io/post/week-10/Szymon Mieszczak (szymag)Szymon Mieszczak (szymag): Week 10Thu, 10 Aug 2017 19:41:21 GMT
https://szymag.github.io/post/week-10/
<p>During week 10 with my mentor, we finished creation of new CoordSys3D constructor. We can set now transformation while coordinate system is created. We’ve moved functionality from _connect_to_standard_cartesian to constructor so we support the same type of transformation as previously.
Now I demonstrate shorty how coordinate system different that Caertsian can be created in SymPy:
a = CoordSys3D('a', transformation='spherical', variable_names=["r", "theta", "phi"]) a.lame_coefficients() a.transformation_to_parent() b = CoordSys3D('b', lambda r, theta, phi: (r*sin(theta)*cos(phi), r*sin(theta)*sin(phi), r*cos(theta)), variable_names=["https://parsoyaarihant.github.io/blog/gsoc/2017/08/10/GSoC17-Week10-ReportArihant Parsoya (parsoyaarihant)Arihant Parsoya (parsoyaarihant): GSoC17 Week 10 ReportThu, 10 Aug 2017 06:30:00 GMT
https://parsoyaarihant.github.io/blog/gsoc/2017/08/10/GSoC17-Week10-Report.html
<h2 id="work-done">Work Done</h2>
<ul>
<li>Completed test suit for Algebraic Linear products.</li>
</ul>
<h2 id="todo">Todo</h2>
<ul>
<li>So far, we have implemented large utility functions using some of inbuilt SymPy’s functions(example: <code class="highlighter-rouge">trigsimp</code>). These functions are very large to be implemented by hand. I have an idea to implement these functions using MatchPy’s <code class="highlighter-rouge">ManyToOneReplacer</code>(similar to what we have done with main Rubi Integrate function).</li>
<li>Test Algebraic Quadratic products rules.</li>
</ul>http://valglad.github.io/2017/08/08/completeValeriia Gladkova (valglad)Valeriia Gladkova (valglad): Completing homomorphismsTue, 08 Aug 2017 00:00:00 GMT
http://valglad.github.io/2017/08/08/complete/
<p>I sent the <a href="https://github.com/sympy/sympy/pull/1307">PR with the other homomorphism cases</a> a week ago, so about a day after my last post. The work required for the main part of the PR wasn’t really complicated but it took a while to get merged (earlier today) because some more problems showed up in the rewriting system part.</p>
<p>It started off with <a href="https://github.com/jksuom">Kalevi</a> noticing that in the case of a free abelian group, the list of rewriting rules after initiation seemed incomplete - it so happened that the test didn’t pick up on it because it didn’t need the missing rules. In itself, that wouldn’t be much of a problem because the missing rules could be added during the run of <code class="highlighter-rouge">make_confluent</code> but <code class="highlighter-rouge">is_confluent</code> was already <code class="highlighter-rouge">True</code> - that was definitely wrong. So for one thing, <code class="highlighter-rouge">_check_confluence</code> wasn’t working properly and also I thought that the type of rules that wasn’t added during rule initiation, could be added as another case - if it could be done in place, why wait till it’s discovered by the double loop in <code class="highlighter-rouge">make_confluent</code>. I made a few little changes throughout the code to fix things but ultimately, it was the inadequacy of <code class="highlighter-rouge">add_rule</code> that was causing problems.</p>
<p>When a pair of words is given to <code class="highlighter-rouge">add_rule</code>, it first multiplies them by the inverse of the first element of the longer word until the length difference is 0, 1 or 2 (greater length differences are redundant when the smaller length differences are in the rules dictionary). Then it does the same on the other (right) side which leads to a different set of rules. We could obtain even more rules right here, without waiting for <code class="highlighter-rouge">make_confluent</code>, if we allow switching sides, i.e. not just continuously multiplying on the right or on the left, but perform some left multiplications after several on the right, etc. This makes <code class="highlighter-rouge">make_confluent</code> a little more efficient as more rules are discovered at one time but trying all possible combinations of sides would probably take too much time without actually being productive. At the moment, when the length difference becomes sufficiently small, instead of adding the rule directly, <code class="highlighter-rouge">add_rule</code> calls itself recursively which allows for some side switching. Perhaps in the future, it would seem fit to try all combinations. A couple of days ago I added a rules cache to prevent repeating the work that has already been done by the function so maybe it won’t cause too much of a slow-down in practice.</p>
<p>After this, one rule was still missing. I reread the code several times and it took a while to work out that the problem was what seems quite obvious now. When a pair of words <code class="highlighter-rouge">w1, w2</code> of the same length is given to <code class="highlighter-rouge">add_rule</code>, the only rule that was added was <code class="highlighter-rouge">w1: w2</code> for <code class="highlighter-rouge">w1 > w2</code>. But another possibility right there could be <code class="highlighter-rouge">w2**-1: w1**-1</code> provided <code class="highlighter-rouge">w2**-1 > w1**-1</code>. Normally, this inverse rule doesn’t need to be added because if <code class="highlighter-rouge">len(w1) > len(w2)</code>, then <code class="highlighter-rouge">w1**-1 > w2**-1</code> and <code class="highlighter-rouge">w**-1: w2**-1</code> is implied by how word reduction is set up. Adding this last case solved the issue.</p>
<p>There were some other little improvements. For example, <code class="highlighter-rouge">make_confluent</code> has been made to returns a boolean at all times, not just when checking if the system is confluent. This could be used to see if it is successful. I also spotted an error in the kernel computation method that hadn’t come up before only by sheer luck.</p>
<p>Now that all the basic homomorphism functionality is available, I can have a go at extending the <code class="highlighter-rouge">FpGroup</code> class with <code class="highlighter-rouge">PermutationGroup</code> methods. I might be able to get it to work without the <a href="https://github.com/sympy/sympy/pull/12986">finite presentation of permutation groups PR</a> (it hasn’t been reviewed yet) but I’m not entirely sure yet.</p>
<p>Another thing on my hands is sylow subgroups. I actually thought I got them to work several days ago but then one of the test groups (<code class="highlighter-rouge">SymmetricGroup(10)</code>) revealed a bug in the <code class="highlighter-rouge">_strong_gens_slp</code> attribute. It wasn’t caused by the sylow method and only comes up after computing a stabilizer or a normalizer - something I only realised yesterday; this bug really confused me for a while. I did fix it now but a different problem came up and what worked before no longer does. I don’t see why the bug fix would lead to it but evidently it did… So still trying to sort it out.</p>
<p><strong>Update</strong>: Have just worked out that sylow thing. Turned out minimal blocks weren’t being computed properly (my fault: I wrote a separate function that should have outputed all minimal block systems but failed on minimality). So now all that remains is to do some more testing and tidy up the code, and I can send a PR with it in a day or so (if no other bugs turn up, that is).</p>https://shikharj.github.io//2017/08/07/GSoC-Progress-Week-10Shikhar Jaiswal (ShikharJ)Shikhar Jaiswal (ShikharJ): GSoC Progress - Week 10Mon, 07 Aug 2017 00:00:00 GMT
https://shikharj.github.io//2017/08/07/GSoC-Progress-Week-10/
<p>Greetings!
The GSoC final submissions are about three weeks away and I’m trying my best to get everything sorted out before the deadline. However, we are faced with an issue. Isuru won’t be available for the major part of the penultimate week. As such, I’ll have to reach out to Sumith for reviews, who’s been pretty busy lately. Hence my goal for the next week would be to get everything reviewed and merged as soon as possible. Here is a gist of the work done in the previous week.</p>
<h2 id="report">Report</h2>
<h3 id="symenginepy">SymEngine.py</h3>
<p>I implemented some attributes seeking inspiration from <code class="highlighter-rouge">SymPy</code>’s classes in <a href="https://github.com/symengine/symengine.py/pull/180">#180</a>, which is reviewed and merged. I also took some time fixing the assertion failures in <code class="highlighter-rouge">SymPy</code>’s modules, which would be pushed in soon. More on this next week.</p>
<p>That’s all I have.</p>
<p><strong>Totsiens</strong></p>https://parsoyaarihant.github.io/blog/gsoc/2017/08/06/GSoC17-Week9-ReportArihant Parsoya (parsoyaarihant)Arihant Parsoya (parsoyaarihant): GSoC17 Week 9 ReportSun, 06 Aug 2017 06:30:00 GMT
https://parsoyaarihant.github.io/blog/gsoc/2017/08/06/GSoC17-Week9-Report.html
<h2 id="work-done">Work Done</h2>
<ul>
<li>I have parsed all the rule in SymPy syntax and removed Rubi’s dependency on machpy-sympy converters and MatchPy’s <code class="highlighter-rouge">Operations</code>. I have also updated the parser to accommodate for this change.</li>
<li>Completed the test suit for 1.2. Tests are failing since Travis is still using older version of MatchPy which does not support new functionalities.</li>
</ul>
<h2 id="todo">Todo</h2>
<p>Tests for all algebraic rules are already added.</p>
<ul>
<li>I have already added test for test suit 1.3. I am investigating them locally. I am trying my best to pass all the algebraic test suit by this week.</li>
<li><code class="highlighter-rouge">AppellF1</code> is not implemented in SymPy. I couldn’t find time to implement is last week. I will implement basic version of <code class="highlighter-rouge">AppellF1</code>.</li>
</ul>http://nesar2017.wordpress.com/?p=317Abdullah Javed Nesar (Abdullahjavednesar)Abdullah Javed Nesar (Abdullahjavednesar): GSoC Progress ReportThu, 03 Aug 2017 19:20:07 GMT
https://nesar2017.wordpress.com/2017/08/03/gsoc-progress-report-4/
<p>We are almost done with the implementation of utility functions. My next task would be to parse all test suits and minimize the test cases as there are numerous tests (of similar type) which is taking too long to run in Python. Along with it I’ll be completing some incomplete utility functions and fixing bugs. We need to port all the rules and test it as early as possible to fix all possible bugs. Although a major bulk of our work is completed adding rules and test should not take much time.</p><br /> <a href="http://feeds.wordpress.com/1.0/gocomments/nesar2017.wordpress.com/317/" rel="nofollow"><img alt="" border="0" src="http://feeds.wordpress.com/1.0/comments/nesar2017.wordpress.com/317/" /></a> <img alt="" border="0" height="1" src="https://pixel.wp.com/b.gif?host=nesar2017.wordpress.com&blog=126779945&post=317&subd=nesar2017&ref=&feed=1" width="1" />http://arif7blog.wordpress.com/?p=691Arif Ahmed (ArifAhmed1995)Arif Ahmed (ArifAhmed1995): Week 9 Report(June 27 – August 3) : Basic 3D prototype.Wed, 02 Aug 2017 20:12:18 GMT
https://arif7blog.wordpress.com/2017/08/02/week-9-reportjune-27-august-3-basic-3d-prototype/
<p>This week I returned to college and quite some time was spent in setting up the room, registering for courses, etc. Also, I have 27 hours a week of classes from now on which is okay considering that some of my batch-mates have 31 – 32 hours/week.</p>
<p>The good thing is that the major part of my work is complete. This week I worked on the 3D case. Here is the PR : <a href="https://github.com/sympy/sympy/pull/13082" rel="noopener" target="_blank">#13082</a> . A minor limitation(minor from the perspective of fixing it) is that only constant expressions are supported. Another limitation is that the input has to be a list of the polygons constituting the faces of the 3D polytope. This should actually be a list of points in correct order and the algorithm should figure out the polygon from the input. Examples of such input are in <a href="http://dilbert.engr.ucdavis.edu/~suku/quadrature/cls-integration.pdf" rel="noopener" target="_blank">Chin et. al(2015)</a> .<br />
I’ll finish it up by Saturday and then proceed to completing PR <a href="https://github.com/sympy/sympy/pull/12931" rel="noopener" target="_blank">#12931</a> . That might extend to the first few days of next week as well.</p><br /> <a href="http://feeds.wordpress.com/1.0/gocomments/arif7blog.wordpress.com/691/" rel="nofollow"><img alt="" border="0" src="http://feeds.wordpress.com/1.0/comments/arif7blog.wordpress.com/691/" /></a> <img alt="" border="0" height="1" src="https://pixel.wp.com/b.gif?host=arif7blog.wordpress.com&blog=126429718&post=691&subd=arif7blog&ref=&feed=1" width="1" />https://szymag.github.io/post/week-9/Szymon Mieszczak (szymag)Szymon Mieszczak (szymag): Week 9Wed, 02 Aug 2017 19:41:21 GMT
https://szymag.github.io/post/week-9/
<p>Reconstruction of constructor in CoordSys3D is like never ending story, but fortunately we are almost at the end of the work. We decide to distinguish two cases. When rotation matrix or location is set and when transformation is set. In the first case we are creating transformation equations from rotation matrix and translation vector. In the second, user is responsible for defining transformation equations but it is also possible to use some pre-defined curvilinear coordinate system.https://shikharj.github.io//2017/08/01/GSoC-Progress-Week-9Shikhar Jaiswal (ShikharJ)Shikhar Jaiswal (ShikharJ): GSoC Progress - Week 9Tue, 01 Aug 2017 00:00:00 GMT
https://shikharj.github.io//2017/08/01/GSoC-Progress-Week-9/
<p>Hi all, we’re in the final month of <code class="highlighter-rouge">GSoC</code> with only about 4 weeks remaining on the development time. Last week was a bit rough because my college semester started off with a heavy schedule on the very first day, and a number of boarding issues, due to which a number of my days were spent in shifting my stuff from one room to another. Add to that the summer heat of this country, and it becomes a total nightmare. Here’s what I could do.</p>
<h2 id="report">Report</h2>
<h3 id="symengine">SymEngine</h3>
<p>I pushed in <a href="https://github.com/symengine/symengine.py/pull/1316">#1316</a>, resolving some of the scope issues we were facing in <code class="highlighter-rouge">SymEngine.py</code>. I’m expecting a light implementation schedule here in <code class="highlighter-rouge">SymEngine</code> form now on, as we have most of the stuff we need for a sizeable amount of <code class="highlighter-rouge">SymPy</code>’s directories to be ported over <code class="highlighter-rouge">SymEngine</code>.</p>
<h3 id="sympy">SymPy</h3>
<p>Pushed in <a href="https://github.com/sympy/sympy/pull/13051">#13051</a>, fixing a minor piece of code that was previously preventing us from using <code class="highlighter-rouge">SymEngine</code>’s <code class="highlighter-rouge">igcd</code> in <code class="highlighter-rouge">SymPy</code>’s <code class="highlighter-rouge">LieAlgebras</code> module. I had also taken some time updating the work on other directories.</p>
<h3 id="symenginepy">SymEngine.py</h3>
<p>I worked on implementing some miscellaneous missing functionalities in <a href="https://github.com/symengine/symengine.py/pull/179">#179</a>, which should soon be ready to get merged.</p>
<p>Since we are slowly reaching towards the end of the project, I’ll have to request Isuru for a release in <code class="highlighter-rouge">SymEngine</code> and <code class="highlighter-rouge">SymEngine.py</code> so that our latest work becomes available for <code class="highlighter-rouge">SymPy</code>.</p>
<p><strong>Pozdrav</strong></p>http://ranjithkumar007.github.io/2017/08/01/Week-09Ranjith Kumar (ranjithkumar007)Ranjith Kumar (ranjithkumar007): Week-09Tue, 01 Aug 2017 00:00:00 GMT
http://ranjithkumar007.github.io/2017/08/01/Week-09/
<p>Hey everyone, this post contains progress in week-9. We are in the last phase of GSoC project. My progress is a bit lagging from the proposed timeline primarily due to commencement of classes.</p>
<p>As mentioned in my last blog, I was able to get the <a href="https://github.com/symengine/symengine/pull/1314">PR</a> on fixes for ImageSet merged in and
I baked all remaining pieces within <a href="https://github.com/symengine/symengine/pull/1305">#1305</a>.</p>
<p>In this, I implemented a <code class="highlighter-rouge">IsALinearArgTrig</code> as follows</p>
<div class="highlighter-rouge"><pre class="highlight"><code>class IsALinearArgTrigVisitor
: public BaseVisitor<IsALinearArgTrigVisitor, StopVisitor>
{}
</code></pre>
</div>
<p>It checks if the argument of Trigonometric and Hyperbolic parts is linear in symbol or not. If input is not linear in symbol, then we can’t solve that equation using the present TrigSolver.</p>
<p>Next is <code class="highlighter-rouge">invertComplex</code>.</p>
<div class="highlighter-rouge"><pre class="highlight"><code>class InvertComplexVisitor : public BaseVisitor<InvertComplexVisitor>
{}
</code></pre>
</div>
<p>This is useful for finding inverse. Ex: for finding the <code class="highlighter-rouge">x</code> that satisfies the equation <code class="highlighter-rouge">exp(I*x) = 3</code>. Some tests are failing on <code class="highlighter-rouge">MSVC15</code> compiler. I will try to figure out and fix that ASAP.</p>
<p>Meanwhile, I implemented basic solvers for system of equations in this <a href="https://github.com/symengine/symengine/pull/1317">PR</a>.</p>
<p>That’s all for now. See you next time.</p>http://valglad.github.io/2017/07/31/sylowValeriia Gladkova (valglad)Valeriia Gladkova (valglad): The rewriting PR and Sylow SubgroupsMon, 31 Jul 2017 00:00:00 GMT
http://valglad.github.io/2017/07/31/sylow/
<p>The <a href="https://github.com/sympy/sympy/pull/12893">rewriting PR</a> only got merged today. Firstly, it took several days to sort out the <code class="highlighter-rouge">FpSubgroup</code>’s <code class="highlighter-rouge">__contains__</code> method (in this <a href="https://github.com/sympy/sympy/pull/13028">PR</a>). Secondly, my mentor pointed out a case I overlooked in the <code class="highlighter-rouge">add_rule</code> routine, and once I corrected it, another problem presented itself. It wasn’t to do with <code class="highlighter-rouge">add_rule</code> but adding the overlooked case made it possible for the tests to pick up on it (luckily). The problem was that sometimes <code class="highlighter-rouge">make_confluent</code> would try to use a non-existent key for the dictionary of rewriting rules. This happened because <code class="highlighter-rouge">make_confluent</code> is set up in such a way that if sufficiently many rules are added, <code class="highlighter-rouge">_remove_redundancies</code> method is called, and this removes or modifies some of the existing rules, and the function didn’t account for this change properly. It took me several goes until I finally got it. And while I was at it, I noticed yet another bug which took some time to track down. Turned out that “for” loops don’t always properly iterate over lists that are changed inside the loop (spefically, they ignore newly appended elements). I didn’t think it would be a problem because I have done similar things before in python. I ended up replacing it with a “while” loop like:</p>
<div class="highlighter-rouge"><pre class="highlight"><code>>>> while i < len(some_list):
>>> some_list.append(new_element)
>>> i += 1
</code></pre>
</div>
<p>and that worked properly. Still not entirely sure what happened there: appending elements inside a for loop in the terminal shell doesn’t cause such problems - I should probably look into that more at some point, for future reference.</p>
<p>So I only began working on completing the other homomorphism cases today (not counting what I have sketched in the previous couple of weeks). I’ll try to send a PR with some of it in several days. At this point, I should be able to do everything except checking that a homomorphism from a permutation group is well defined. For that I’ll need the <a href="https://github.com/sympy/sympy/pull/12986/">presentation PR</a> and it’s quite substantial so its review will almost certaintly take more than several days. I’m planning to add the keyword argument <code class="highlighter-rouge">check</code> to the <code class="highlighter-rouge">homomorphism</code> function so that if <code class="highlighter-rouge">check==False</code>, the given images are assumed to define a homomorphism. I found it useful in some of the work I was doing last week.</p>
<p>I decided to work on computing sylow subgroups, and as part of it, wrote two new homomorphism functions specifically for permutation groups: <code class="highlighter-rouge">orbit_action_homomorphism</code> and <code class="highlighter-rouge">block_action_homomorphism</code> for defining homomorphisms induced by the action of the group on a union of orbits or a block system respectively. These are of course homomorphisms between permutation groups and there is no need to check if they are well-defined so it was possible to create them without the presentation PR. I don’t know if it will stay that way as it hasn’t been discussed yet but it seemed appropriate to have them as separate functions in the homomorphisms file. Also, I found a bug in the <code class="highlighter-rouge">minimal_block</code> method while testing <code class="highlighter-rouge">block_action_homomorphism</code> yesterday but it’s not anything major and the <a href="https://github.com/sympy/sympy/pull/13070">fix</a> for it will likely be merged soon. There was some trouble with Travis today though.</p>
<p>The actual computation of sylow subgroups is going to be a <code class="highlighter-rouge">PermutationGroup</code> method <code class="highlighter-rouge">sylow_subgroup()</code> and it already works for some cases so it’s going well. However, I am going to pause it for now to finish homomorphisms.</p>https://parsoyaarihant.github.io/blog/gsoc/2017/07/30/GSoC17-Week8-ReportArihant Parsoya (parsoyaarihant)Arihant Parsoya (parsoyaarihant): GSoC17 Week 8 ReportSun, 30 Jul 2017 06:30:00 GMT
https://parsoyaarihant.github.io/blog/gsoc/2017/07/30/GSoC17-Week8-Report.html
<h2 id="work-done">Work Done</h2>
<p>Manuel found a way to use MatchPy <code class="highlighter-rouge">Symbol</code> with SymPy <code class="highlighter-rouge">Symbol</code>(<a href="https://gist.github.com/wheerd/b57efd0dba2dbdba4bc10ff6e71cf5ab">sample code</a>). Implementing rules using SymPy symbols would increase the speed of module since we don’t have to convert the expressions back and forth (sympy-matchpy).</p>
<p>I am removing constraint(<code class="highlighter-rouge">cons()</code>) defined for the patterns and started using <code class="highlighter-rouge">CustomConstraint</code> in <code class="highlighter-rouge">Patterns</code>. I wasn’t able to do this previously since <code class="highlighter-rouge">ManyToOneReplacer</code> was only able to handle MatchPy expressions. Now that I can use <code class="highlighter-rouge">CustomConstraint</code>, I have divided the constraint into smaller <code class="highlighter-rouge">CustomConstraint</code>. Example:</p>
<h4 id="old-way-to-define-constraint">Old way to define constraint:</h4>
<div class="language-python highlighter-rouge"><pre class="highlight"><code><span class="n">pattern3</span> <span class="o">=</span> <span class="n">Pattern</span><span class="p">(</span><span class="n">Int</span><span class="p">(</span><span class="n">Pow</span><span class="p">(</span><span class="n">x_</span><span class="p">,</span> <span class="n">Wildcard</span><span class="o">.</span><span class="n">optional</span><span class="p">(</span><span class="s">'m'</span><span class="p">,</span> <span class="n">mpyInt</span><span class="p">(</span><span class="s">'1'</span><span class="p">))),</span> <span class="n">x_</span><span class="p">),</span> <span class="n">cons</span><span class="p">(</span><span class="n">And</span><span class="p">(</span><span class="n">FreeQ</span><span class="p">(</span><span class="n">m</span><span class="p">,</span> <span class="n">x</span><span class="p">),</span> <span class="n">NonzeroQ</span><span class="p">(</span><span class="n">Add</span><span class="p">(</span><span class="n">m_</span><span class="p">,</span> <span class="n">matchpyInteger</span><span class="p">(</span><span class="mi">1</span><span class="p">)))),</span> <span class="p">(</span><span class="n">m</span><span class="p">,</span> <span class="n">x</span><span class="p">)))</span>
</code></pre>
</div>
<h4 id="new-way-to-define-constraint">New way to define constraint:</h4>
<div class="language-python highlighter-rouge"><pre class="highlight"><code><span class="n">pattern3</span> <span class="o">=</span> <span class="n">Pattern</span><span class="p">(</span><span class="n">Int</span><span class="p">(</span><span class="n">Pow</span><span class="p">(</span><span class="n">x_</span><span class="p">,</span> <span class="n">Wildcard</span><span class="o">.</span><span class="n">optional</span><span class="p">(</span><span class="s">'m'</span><span class="p">,</span> <span class="n">mpyInt</span><span class="p">(</span><span class="s">'1'</span><span class="p">))),</span> <span class="n">x_</span><span class="p">),</span> <span class="n">CustomConstraint</span><span class="p">(</span><span class="k">lambda</span> <span class="n">m</span><span class="p">,</span> <span class="n">x</span><span class="p">:</span> <span class="n">FreeQ</span><span class="p">(</span><span class="n">m</span><span class="p">,</span> <span class="n">x</span><span class="p">)),</span> <span class="n">CustomConstraint</span><span class="p">(</span><span class="k">lambda</span> <span class="n">m</span><span class="p">:</span> <span class="n">NonzeroQ</span><span class="p">(</span><span class="n">Add</span><span class="p">(</span><span class="n">m_</span><span class="p">,</span> <span class="n">mpyInt</span><span class="p">(</span><span class="mi">1</span><span class="p">)))))</span>
</code></pre>
</div>
<p>Defining the Constraints in this way will help the <code class="highlighter-rouge">ManyToOneReplacer</code> to backtrack easily and thereby improving the overall speed of the module. There is a <a href="https://github.com/HPAC/matchpy/issues/20">bug</a> in MatchPy related to this, I hope it will be fixed soon.</p>
<p>I have updated the parser to make the above changes. It divides the constraint into different constraints if the <code class="highlighter-rouge">head</code> of expression tree is <code class="highlighter-rouge">And</code>:</p>
<div class="language-python highlighter-rouge"><pre class="highlight"><code><span class="k">def</span> <span class="nf">_divide_constriant</span><span class="p">(</span><span class="n">s</span><span class="p">,</span> <span class="n">symbols</span><span class="p">):</span>
<span class="c"># Creates a CustomConstraint of the form `CustomConstraint(lambda a, x: FreeQ(a, x))`</span>
<span class="k">if</span> <span class="n">s</span><span class="p">[</span><span class="mi">0</span><span class="p">]</span> <span class="o">==</span> <span class="s">'FreeQ'</span><span class="p">:</span>
<span class="k">return</span> <span class="s">''</span>
<span class="n">lambda_symbols</span> <span class="o">=</span> <span class="nb">list</span><span class="p">(</span><span class="nb">set</span><span class="p">(</span><span class="n">get_free_symbols</span><span class="p">(</span><span class="n">s</span><span class="p">,</span> <span class="n">symbols</span><span class="p">,</span> <span class="p">[])))</span>
<span class="k">return</span> <span class="s">'CustomConstraint(lambda {}: {})'</span><span class="o">.</span><span class="n">format</span><span class="p">(</span><span class="s">','</span><span class="o">.</span><span class="n">join</span><span class="p">(</span><span class="n">lambda_symbols</span><span class="p">),</span> <span class="n">generate_sympy_from_parsed</span><span class="p">(</span><span class="n">s</span><span class="p">))</span>
<span class="k">def</span> <span class="nf">divide_constraint</span><span class="p">(</span><span class="n">s</span><span class="p">,</span> <span class="n">symbols</span><span class="p">):</span>
<span class="k">if</span> <span class="n">s</span><span class="p">[</span><span class="mi">0</span><span class="p">]</span> <span class="o">==</span> <span class="s">'And'</span><span class="p">:</span>
<span class="n">result</span> <span class="o">=</span> <span class="p">[</span><span class="n">_divide_constriant</span><span class="p">(</span><span class="n">i</span><span class="p">,</span> <span class="n">symbols</span><span class="p">)</span> <span class="k">for</span> <span class="n">i</span> <span class="ow">in</span> <span class="n">s</span><span class="p">[</span><span class="mi">1</span><span class="p">:]]</span>
<span class="k">else</span><span class="p">:</span>
<span class="n">result</span> <span class="o">=</span> <span class="n">_divide_constriant</span><span class="p">(</span><span class="n">s</span><span class="p">,</span> <span class="n">symbols</span><span class="p">)</span>
<span class="n">r</span> <span class="o">=</span> <span class="p">[</span><span class="s">''</span><span class="p">]</span>
<span class="k">for</span> <span class="n">i</span> <span class="ow">in</span> <span class="n">result</span><span class="p">:</span>
<span class="k">if</span> <span class="n">i</span> <span class="o">!=</span> <span class="s">''</span><span class="p">:</span>
<span class="n">r</span><span class="o">.</span><span class="n">append</span><span class="p">(</span><span class="n">i</span><span class="p">)</span>
<span class="k">return</span> <span class="s">', '</span><span class="o">.</span><span class="n">join</span><span class="p">(</span><span class="n">r</span><span class="p">)</span>
</code></pre>
</div>
<h2 id="todo">Todo</h2>
<ul>
<li>Parse all the rules using SymPy <code class="highlighter-rouge">Symbol</code></li>
<li>Remove sympy-matchpy converters and matchpy <code class="highlighter-rouge">Operations</code></li>
</ul>http://nesar2017.wordpress.com/?p=286Abdullah Javed Nesar (Abdullahjavednesar)Abdullah Javed Nesar (Abdullahjavednesar): GSoC Progress ReportThu, 27 Jul 2017 18:51:18 GMT
https://nesar2017.wordpress.com/2017/07/27/gsoc-progress-report-3/
<p>I have almost completed implementing all the Utility Functions just to complete few tests and few left out functions. Till now we were using <code class="highlighter-rouge">Rt()</code> which could only handle numeric value the new definition can handle even expressions. This week I was a bit engaged with my pending academic works so I was a bit inactive. I’ll be committing my changes soon. These are few tests for <code class="highlighter-rouge">Rt()</code>.</p>
<div class="language-python highlighter-rouge">
<pre class="highlight"><code>def test_Rt():
assert Rt(x**2, 2) == x
assert Rt(S(2 + 3*I), S(8)) == (2 + 3*I)**(1/8)
assert Rt(x**2 + 4 + 4*x, 2) == x + 2
assert Rt(S(8), S(3)) == 2
assert Rt(S(16807), S(5)) == 7</code></pre>
</div>
<p> </p><br /> <a href="http://feeds.wordpress.com/1.0/gocomments/nesar2017.wordpress.com/286/" rel="nofollow"><img alt="" border="0" src="http://feeds.wordpress.com/1.0/comments/nesar2017.wordpress.com/286/" /></a> <img alt="" border="0" height="1" src="https://pixel.wp.com/b.gif?host=nesar2017.wordpress.com&blog=126779945&post=286&subd=nesar2017&ref=&feed=1" width="1" />http://arif7blog.wordpress.com/?p=680Arif Ahmed (ArifAhmed1995)Arif Ahmed (ArifAhmed1995): Week 8 Report(July 18 – July 26): Beginning 3D caseWed, 26 Jul 2017 06:19:18 GMT
https://arif7blog.wordpress.com/2017/07/26/week-8-reportjuly-18-july-26-beginning-3d-case/
<p>So, I wrapped up <a href="https://github.com/sympy/sympy/pull/12931" rel="noopener" target="_blank">PR#12931</a> on handling implicit intersections. I’ve to clean it up a bit more as suggested by Christopher. I plan to implement the Bentley-Ottmann Algorithm and the case with intersecting polygons with more than two sides passing through same point in separate PRs.</p>
<p>Now, about the 3D case I initially thought about writing a 3-Polytope class first but I now realise that there is no need as such. The API can be kept simpler. I’ll update this post with a PR link for the 3D case quite soon.</p><br /> <a href="http://feeds.wordpress.com/1.0/gocomments/arif7blog.wordpress.com/680/" rel="nofollow"><img alt="" border="0" src="http://feeds.wordpress.com/1.0/comments/arif7blog.wordpress.com/680/" /></a> <img alt="" border="0" height="1" src="https://pixel.wp.com/b.gif?host=arif7blog.wordpress.com&blog=126429718&post=680&subd=arif7blog&ref=&feed=1" width="1" />https://szymag.github.io/post/week-8/Szymon Mieszczak (szymag)Szymon Mieszczak (szymag): Week 8Tue, 25 Jul 2017 19:41:21 GMT
https://szymag.github.io/post/week-8/
<p>During week 8 I added several methods which calculate transformation equations for some specific situation. We’ve finished step, where transformation equations are obtained for rotation, translation, and changing the type of coordinate system. This all transitions are handled in vector module. We’ve also prepared the method for composition of any two kind of transformations, because coordinate system can be rotated and translated at the same time.
My current task is to use already added methods in CoordSys3D constructor.https://shikharj.github.io//2017/07/25/GSoC-Progress-Week-8Shikhar Jaiswal (ShikharJ)Shikhar Jaiswal (ShikharJ): GSoC Progress - Week 8Tue, 25 Jul 2017 00:00:00 GMT
https://shikharj.github.io//2017/07/25/GSoC-Progress-Week-8/
<p>My first two months under <code class="highlighter-rouge">GSoC</code> have finally ended, and we are right on track towards the completion of the project. I finished up on my log of <code class="highlighter-rouge">SymPy</code>’s directories and have analysed everything that needs to be further implemented or improved upon.</p>
<h2 id="report">Report</h2>
<h3 id="symengine">SymEngine</h3>
<p>I pushed in <a href="https://github.com/symengine/symengine.py/pull/1313">#1313</a>, implementing <code class="highlighter-rouge">row_insert</code> and <code class="highlighter-rouge">column_insert</code> functions in <code class="highlighter-rouge">DenseMatrix</code> class and <code class="highlighter-rouge">row_del</code> and <code class="highlighter-rouge">col_del</code> functions in <code class="highlighter-rouge">C</code> wrappers, while making <code class="highlighter-rouge">row_join</code>, <code class="highlighter-rouge">col_join</code>, <code class="highlighter-rouge">row_del</code> and <code class="highlighter-rouge">col_del</code> in-place member functions.</p>
<h3 id="sympy">SymPy</h3>
<p>After testing all the viable directories that could use <code class="highlighter-rouge">SymEngine</code> as a backend, only the <code class="highlighter-rouge">LieAlgebras</code> module worked completely out of the box, with no major issues. As such, we were able to achieve the same through <a href="https://github.com/sympy/sympy/pull/13023">#13023</a>, which now marks the beginning of Phase III of my proposal. I have also pushed the work done on other directories as separate branches on my local repository, to be finished upon gradually.</p>
<h3 id="symenginepy">SymEngine.py</h3>
<p>I worked on implementing the <code class="highlighter-rouge">Singleton</code> pattern in the wrappers through <a href="https://github.com/symengine/symengine.py/pull/178">#178</a>, though the work is currently in progress. More on this next week.</p>
<p>That’s all I have for now.</p>
<p><strong>Bidāẏa</strong></p>http://ranjithkumar007.github.io/2017/07/25/Trigonometric Solvers Part IIRanjith Kumar (ranjithkumar007)Ranjith Kumar (ranjithkumar007): Trigonometric Solvers Part IITue, 25 Jul 2017 00:00:00 GMT
http://ranjithkumar007.github.io/2017/07/25/Trigonometric-Solvers-Part-II/
<p>This is the blog on progress for week-7 and week-8. It revolves around trigonometric solvers. As a side note, My progress rate has significantly dropped since the commencement of classes due to tight schedule and loaded assignments. I am working all out on weekends to compensate this time loss.</p>
<p>As I mentioned in my previous blog, I continued my work on solving simple trigonometric equations. As isuruf suggested, I breaked the PR <a href="https://github.com/symengine/symengine/pull/1305">#1305</a> into several small parts.</p>
<p>First one is on <code class="highlighter-rouge">as_real_imag</code> <a href="https://github.com/symengine/symengine/pull/1310">#1310</a>. Several Changes were made like adding support for TrigFunctions and HyperbolicFunctions.</p>
<p>Next PR is on <code class="highlighter-rouge">rewrite_as_exp</code> <a href="https://github.com/symengine/symengine/pull/1309">#1309</a>. For this, I Implemented a Base Transform Visitor as follows.</p>
<div class="highlighter-rouge"><pre class="highlight"><code>class TransformVisitor : public BaseVisitor<TransformVisitor>
{}
</code></pre>
</div>
<p>and <code class="highlighter-rouge">rewrite_as_exp</code> is implemented with a class overriding TransformVisitor’s methods.</p>
<div class="highlighter-rouge"><pre class="highlight"><code>class RewriteAsExp : public BaseVisitor<RewriteAsExp, TransformVisitor>
{}
</code></pre>
</div>
<p>Additionally, going by srajan’s suggestion, I changed introduced a new base class <code class="highlighter-rouge">TrigBase</code> for TrigFunctions and its inverses and similarly for HyperbolicFunctions.</p>
<p>Additionally, I made some fixes in <code class="highlighter-rouge">ImageSet</code> <a href="https://github.com/symengine/symengine/pull/1314">here</a>.</p>
<p>Once, this PR gets in, I will push the remaining bits and pieces from #1305.</p>http://valglad.github.io/2017/07/24/delaysValeriia Gladkova (valglad)Valeriia Gladkova (valglad): DelaysMon, 24 Jul 2017 00:00:00 GMT
http://valglad.github.io/2017/07/24/delays/
<p>The rewriting PR hasn’t been merged yet. At the beginning of last week, there was still some work to be done on it. For example, the <code class="highlighter-rouge">RewritingSystem</code>’s <code class="highlighter-rouge">check_confluence()</code> method (which, unsurprisingly, checks if the system is confluent) would add new rewriting rules while it runs - definitely not something it should do. Another addition, suggested by my mentor, was the attribute <code class="highlighter-rouge">_max_exceeded</code>: this is <code class="highlighter-rouge">True</code> when the Knuth-Bendix completion method has already been attempted but the maximum number of rules allowed to be added to the system was exceeded. Trying again would be a waste of time. However, if the maximum number of rules is increased, <code class="highlighter-rouge">_max_exceeded</code> is reset so that the completion method could be run again.</p>
<p>Then I worked on the multi-step version of the presentation algorithm (which was possible because the homomorphism <a href="https://github.com/sympy/sympy/pull/12827">PR</a> was merged by then). Once I wrote it up, made sure it worked and started testing against the single step one, I noticed that the multi-step version ran several times as fast for several of the groups I was using and yet was suddenly much slower for a group of higher order. This was unexpected and I spent a while trying to work out why that would be. The reason was this: the function uses <code class="highlighter-rouge">coset_enumeration_c</code> for filling in a certain coset table. <code class="highlighter-rouge">coset_enumeration_c</code> stores the deductions it makes while filling in so that it can process them later. However, if there are too many deductions, it’s not practical to go through all of them so the algorithm uses the method <code class="highlighter-rouge">look_ahead</code> that allows it to continue without looking at the deduction stack which is emptied. The critical size of the deduction stack was 500 by default. For large groups, the single step version would greatly exceed that most of the time so <code class="highlighter-rouge">look_ahead</code> was run instead, speeding it up considerably, while the multi step version would be working with a smaller coset table and the number of deductions would be large but not over 500 which made it slow. So it looked like processing close to 500 deductions was inefficient and I reduced the number to 100 to see what happens. What happened was that both version got faster but now the multi-step version was consistently faster than the single-step one. I ran the coset table tests and they seemed to be fine too so the reduction in the maximum number of deductions didn’t seem to affect anything negatively. I pushed the multi step version into the presentation <a href="https://github.com/sympy/sympy/pull/12986">PR</a> but that hasn’t started being reviewed because another problem came up.</p>
<p>The homomorphisms tests from the merged PR would occasionally time out so that needed investigating. Turned out it was because the <code class="highlighter-rouge">__contains__</code> method of the <code class="highlighter-rouge">FpSubgroup</code> class couldn’t handle group elements in the conjugate form, i.e. something of the form <code class="highlighter-rouge">r**-1*w*r</code> for some words <code class="highlighter-rouge">r, w</code>. It would get into an infinite loop and the tests would only occasionally time out because the method is used during kernel computation which is randomised. So a couple of days was spent thinking about what would be the best way to eliminate the problem, whether this sort of problem would only be caused by conjugate elements and finally expanding the code accordingly. You can follow what I did in this <a href="https://github.com/sympy/sympy/pull/13028">PR</a>. Though this is still being discussed and it’s unclear whether some other solution would be called for.</p>
<p>So because of all this, I couldn’t work on the other homomorphism cases (though I did sketch some things that I can use once the dependent PRs are merged). If the <code class="highlighter-rouge">FpSubgroup</code> issue is resolved soon and the rewriting PR is merged, I will implement homomorphisms to <code class="highlighter-rouge">FpGroup</code>s. The presentation PR will probably need more reviewing and I can’t implement <code class="highlighter-rouge">PermutationGroup</code> domains without it. I’m considering looking into an alternative method of doing homomorphisms specifically for the <code class="highlighter-rouge">PermutationGroup</code> to <code class="highlighter-rouge">PermutationGroup</code> case because I’ve seen a section on it in the Handbook. Or I could start working on Sylow subgroups which is another things I was thinking of doing. These things shouldn’t depend on any of the unmerged PRs so it would be a good use of time.</p>https://parsoyaarihant.github.io/blog/gsoc/2017/07/23/GSoC17-Week7-ReportArihant Parsoya (parsoyaarihant)Arihant Parsoya (parsoyaarihant): GSoC17 Week 7 ReportSun, 23 Jul 2017 06:30:00 GMT
https://parsoyaarihant.github.io/blog/gsoc/2017/07/23/GSoC17-Week7-Report.html
<p>Francesco opened the <a href="https://github.com/sympy/sympy/pull/12978">PR</a> to merge the Rubi module in SymPy. I made the code compatible for python<3.6 to pass the Travis tests. I used <code class="highlighter-rouge">@doctest_depends_on</code> function decorator to stop the doctest for python<3.6 and defined dummy classes to pass the tests. We are keeping the PR open for now since it will allow me to run tests on Travis and I expect significant change in code after code generation functionality is added in MatchPy.</p>
<h4 id="parser">Parser</h4>
<p>I have updated the parser to accommodate for <code class="highlighter-rouge">Wildcard.optional()</code>. Previously, I sympified the expression and substituted the optional values to create new patterns. The current parser does not use sympy and is very fast compared to previous version.</p>
<h4 id="tests">Tests</h4>
<p>I ran the test suit for algebraic rules 1.2 previously and ~1250/1500 tests were passing. The tests are really slow since they use <code class="highlighter-rouge">simplify</code> and <code class="highlighter-rouge">expand</code> functions. I tried using numerical evaluation at random points and it turned out to be faster than evaluating tests symbolically. Test suits are grouped by the type of expression:</p>
<div class="language-python highlighter-rouge"><pre class="highlight"><code><span class="c"># Integrands of the form a</span>
<span class="p">[</span><span class="n">S</span><span class="p">(</span><span class="mi">0</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="mi">1</span><span class="p">),</span> <span class="n">S</span><span class="p">(</span><span class="mi">0</span><span class="p">)],</span>
<span class="p">[</span><span class="n">S</span><span class="p">(</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="mi">1</span><span class="p">),</span> <span class="n">x</span><span class="p">],</span>
<span class="p">[</span><span class="n">S</span><span class="p">(</span><span class="mi">5</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="mi">1</span><span class="p">),</span> <span class="n">S</span><span class="p">(</span><span class="mi">5</span><span class="p">)</span><span class="o">*</span><span class="n">x</span><span class="p">],</span>
<span class="p">[</span> <span class="o">-</span> <span class="n">S</span><span class="p">(</span><span class="mi">2</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="mi">1</span><span class="p">),</span> <span class="o">-</span> <span class="n">S</span><span class="p">(</span><span class="mi">2</span><span class="p">)</span><span class="o">*</span><span class="n">x</span><span class="p">],</span>
<span class="c"># Integrands of the form x**m</span>
<span class="p">[</span><span class="n">x</span><span class="o">**</span><span class="n">m</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="mi">1</span><span class="p">),</span> <span class="n">x</span><span class="o">**</span><span class="p">(</span><span class="n">S</span><span class="p">(</span><span class="mi">1</span><span class="p">)</span> <span class="o">+</span> <span class="n">m</span><span class="p">)</span><span class="o">/</span><span class="p">(</span><span class="n">S</span><span class="p">(</span><span class="mi">1</span><span class="p">)</span> <span class="o">+</span> <span class="n">m</span><span class="p">)],</span>
<span class="p">[</span><span class="n">x</span><span class="o">**</span><span class="n">S</span><span class="p">(</span><span class="mi">100</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="mi">1</span><span class="p">),</span> <span class="n">S</span><span class="p">(</span><span class="mi">1</span><span class="p">)</span><span class="o">/</span><span class="n">S</span><span class="p">(</span><span class="mi">101</span><span class="p">)</span><span class="o">*</span><span class="n">x</span><span class="o">**</span><span class="n">S</span><span class="p">(</span><span class="mi">101</span><span class="p">)],</span>
<span class="p">[</span><span class="n">x</span><span class="o">**</span><span class="n">S</span><span class="p">(</span><span class="mi">3</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="mi">1</span><span class="p">),</span> <span class="n">S</span><span class="p">(</span><span class="mi">1</span><span class="p">)</span><span class="o">/</span><span class="n">S</span><span class="p">(</span><span class="mi">4</span><span class="p">)</span><span class="o">*</span><span class="n">x</span><span class="o">**</span><span class="n">S</span><span class="p">(</span><span class="mi">4</span><span class="p">)],</span>
<span class="c"># Integrands of the form x**(m/S(2))</span>
<span class="p">[</span><span class="n">x</span><span class="o">**</span><span class="p">(</span><span class="n">S</span><span class="p">(</span><span class="mi">5</span><span class="p">)</span><span class="o">/</span><span class="n">S</span><span class="p">(</span><span class="mi">2</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="mi">1</span><span class="p">),</span> <span class="n">S</span><span class="p">(</span><span class="mi">2</span><span class="p">)</span><span class="o">/</span><span class="n">S</span><span class="p">(</span><span class="mi">7</span><span class="p">)</span><span class="o">*</span><span class="n">x</span><span class="o">**</span><span class="p">(</span><span class="n">S</span><span class="p">(</span><span class="mi">7</span><span class="p">)</span><span class="o">/</span><span class="n">S</span><span class="p">(</span><span class="mi">2</span><span class="p">))],</span>
<span class="p">[</span><span class="n">x</span><span class="o">**</span><span class="p">(</span><span class="n">S</span><span class="p">(</span><span class="mi">3</span><span class="p">)</span><span class="o">/</span><span class="n">S</span><span class="p">(</span><span class="mi">2</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="mi">1</span><span class="p">),</span> <span class="n">S</span><span class="p">(</span><span class="mi">2</span><span class="p">)</span><span class="o">/</span><span class="n">S</span><span class="p">(</span><span class="mi">5</span><span class="p">)</span><span class="o">*</span><span class="n">x</span><span class="o">**</span><span class="p">(</span><span class="n">S</span><span class="p">(</span><span class="mi">5</span><span class="p">)</span><span class="o">/</span><span class="n">S</span><span class="p">(</span><span class="mi">2</span><span class="p">))],</span>
<span class="p">[</span><span class="n">x</span><span class="o">**</span><span class="p">(</span><span class="n">S</span><span class="p">(</span><span class="mi">1</span><span class="p">)</span><span class="o">/</span><span class="n">S</span><span class="p">(</span><span class="mi">2</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="mi">1</span><span class="p">),</span> <span class="n">S</span><span class="p">(</span><span class="mi">2</span><span class="p">)</span><span class="o">/</span><span class="n">S</span><span class="p">(</span><span class="mi">3</span><span class="p">)</span><span class="o">*</span><span class="n">x</span><span class="o">**</span><span class="p">(</span><span class="n">S</span><span class="p">(</span><span class="mi">3</span><span class="p">)</span><span class="o">/</span><span class="n">S</span><span class="p">(</span><span class="mi">2</span><span class="p">))],</span>
<span class="c"># Integrands of the form x**(m/S(3))</span>
<span class="p">[</span><span class="n">x</span><span class="o">**</span><span class="p">(</span><span class="n">S</span><span class="p">(</span><span class="mi">5</span><span class="p">)</span><span class="o">/</span><span class="n">S</span><span class="p">(</span><span class="mi">3</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="mi">1</span><span class="p">),</span> <span class="n">S</span><span class="p">(</span><span class="mi">3</span><span class="p">)</span><span class="o">/</span><span class="n">S</span><span class="p">(</span><span class="mi">8</span><span class="p">)</span><span class="o">*</span><span class="n">x</span><span class="o">**</span><span class="p">(</span><span class="n">S</span><span class="p">(</span><span class="mi">8</span><span class="p">)</span><span class="o">/</span><span class="n">S</span><span class="p">(</span><span class="mi">3</span><span class="p">))],</span>
<span class="p">[</span><span class="n">x</span><span class="o">**</span><span class="p">(</span><span class="n">S</span><span class="p">(</span><span class="mi">4</span><span class="p">)</span><span class="o">/</span><span class="n">S</span><span class="p">(</span><span class="mi">3</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="mi">1</span><span class="p">),</span> <span class="n">S</span><span class="p">(</span><span class="mi">3</span><span class="p">)</span><span class="o">/</span><span class="n">S</span><span class="p">(</span><span class="mi">7</span><span class="p">)</span><span class="o">*</span><span class="n">x</span><span class="o">**</span><span class="p">(</span><span class="n">S</span><span class="p">(</span><span class="mi">7</span><span class="p">)</span><span class="o">/</span><span class="n">S</span><span class="p">(</span><span class="mi">3</span><span class="p">))],</span>
<span class="p">[</span><span class="n">x</span><span class="o">**</span><span class="p">(</span><span class="n">S</span><span class="p">(</span><span class="mi">2</span><span class="p">)</span><span class="o">/</span><span class="n">S</span><span class="p">(</span><span class="mi">3</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="mi">1</span><span class="p">),</span> <span class="n">S</span><span class="p">(</span><span class="mi">3</span><span class="p">)</span><span class="o">/</span><span class="n">S</span><span class="p">(</span><span class="mi">5</span><span class="p">)</span><span class="o">*</span><span class="n">x</span><span class="o">**</span><span class="p">(</span><span class="n">S</span><span class="p">(</span><span class="mi">5</span><span class="p">)</span><span class="o">/</span><span class="n">S</span><span class="p">(</span><span class="mi">3</span><span class="p">))],</span>
</code></pre>
</div>
<p>Adding thousands of tests could lead to slowdown of tests. So far my plan is to add 1-2 test from each expression type:</p>
<div class="language-python highlighter-rouge"><pre class="highlight"><code><span class="p">[</span><span class="n">S</span><span class="p">(</span><span class="mi">0</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="mi">1</span><span class="p">),</span> <span class="n">S</span><span class="p">(</span><span class="mi">0</span><span class="p">)],</span>
<span class="p">[</span><span class="n">x</span><span class="o">**</span><span class="n">m</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="mi">1</span><span class="p">),</span> <span class="n">x</span><span class="o">**</span><span class="p">(</span><span class="n">S</span><span class="p">(</span><span class="mi">1</span><span class="p">)</span> <span class="o">+</span> <span class="n">m</span><span class="p">)</span><span class="o">/</span><span class="p">(</span><span class="n">S</span><span class="p">(</span><span class="mi">1</span><span class="p">)</span> <span class="o">+</span> <span class="n">m</span><span class="p">)],</span>
<span class="p">[</span><span class="n">x</span><span class="o">**</span><span class="n">S</span><span class="p">(</span><span class="mi">100</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="mi">1</span><span class="p">),</span> <span class="n">S</span><span class="p">(</span><span class="mi">1</span><span class="p">)</span><span class="o">/</span><span class="n">S</span><span class="p">(</span><span class="mi">101</span><span class="p">)</span><span class="o">*</span><span class="n">x</span><span class="o">**</span><span class="n">S</span><span class="p">(</span><span class="mi">101</span><span class="p">)],</span>
<span class="p">[</span><span class="n">x</span><span class="o">**</span><span class="p">(</span><span class="n">S</span><span class="p">(</span><span class="mi">5</span><span class="p">)</span><span class="o">/</span><span class="n">S</span><span class="p">(</span><span class="mi">2</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="mi">1</span><span class="p">),</span> <span class="n">S</span><span class="p">(</span><span class="mi">2</span><span class="p">)</span><span class="o">/</span><span class="n">S</span><span class="p">(</span><span class="mi">7</span><span class="p">)</span><span class="o">*</span><span class="n">x</span><span class="o">**</span><span class="p">(</span><span class="n">S</span><span class="p">(</span><span class="mi">7</span><span class="p">)</span><span class="o">/</span><span class="n">S</span><span class="p">(</span><span class="mi">2</span><span class="p">))],</span>
</code></pre>
</div>
<p>While inspecting the failed tests, I figured out that the failing tests depend on rules from other modules(such as binomials). Hence, they could not be integrated currently.</p>
<h4 id="adding-more-rules">Adding more rules</h4>
<p>I have added all algebriac rules to the matcher(~1700). But, it led to significant decrease in speed. In some cases, the matcher take so much time that I have to stop the program itself. I have <a href="https://github.com/HPAC/matchpy/issues/13">opened</a> an issue for this. Hope this get fixed asap.</p>
<p>I have added all Algebriac rules to the matcher.</p>
<h4 id="todo">Todo</h4>
<p>I have already added all algebraic rules which is 1/5 of all the rules. I cannot really test all those rules
until the speed issue gets fixed. I will focus on the following this week:</p>
<ul>
<li>Once speed is fixed, start testing other modules</li>
<li>Prepare test for remaining rubi modules (add tests from each expression type)</li>
<li>Rename <code class="highlighter-rouge">Integer</code> in rubi.symbols to <code class="highlighter-rouge">matchpyInteger</code></li>
<li>Add support for code generation in Rubi if it gets implemented in MatchPy(Manuel said he was working on it last week)</li>
</ul>http://nesar2017.wordpress.com/?p=237Abdullah Javed Nesar (Abdullahjavednesar)Abdullah Javed Nesar (Abdullahjavednesar): GSoC Progress ReportWed, 19 Jul 2017 18:21:17 GMT
https://nesar2017.wordpress.com/2017/07/19/gsoc-progress-report-2/
<p>I’ve been working on the last set of Utility functions and after that I’ll complete some left over functions yet to be implemented. Along with it we have been fixing some bugs which we could notice.</p>
<p><code>TrigReduce()</code> is an inbuilt function in <a href="http://reference.wolfram.com/language/ref/TrigReduce.html.en">Mathematica</a>, following is its code in Python.</p>
<pre>def TrigReduce(i):
if SumQ(i):
t = 0
for k in i.args:
t += TrigReduce(k)
return t
if ProductQ(i):
if any(PowerQ(k) for k in i.args):
if (i.rewrite(sin, exp).rewrite(cos, exp).expand().rewrite(exp, sin)).has(I):
return i.rewrite(sin, exp).rewrite(cos, exp).expand().rewrite(exp, sin).simplify()
else:
return i.rewrite(sin, exp).rewrite(cos, exp).expand().rewrite(exp, sin)
else:
a = Wild('a')
b = Wild('b')
v = Wild('v')
Match = i.match(v*sin(a)*cos(b))
if Match:
a = Match[a]
b = Match[b]
v = Match[v]
# 2 sin A cos B = sin(A + B) + sin(A − B)
return i.subs(v*sin(a)*cos(b), v*S(1)/2*(sin(a + b) + sin(a - b)))
Match = i.match(v*sin(a)*sin(b))
if Match:
a = Match[a]
b = Match[b]
v = Match[v]
# 2 sin A sin B = cos(A − B) − cos(A + B)
return i.subs(v*sin(a)*sin(b), v*S(1)/2*cos(a - b) - cos(a + b))
Match = i.match(v*cos(a)*cos(b))
if Match:
a = Match[a]
b = Match[b]
v = Match[v]
# 2 cos A cos B = cos(A + B) + cos(A − B)
return i.subs(v*cos(a)*cos(b), v*S(1)/2*cos(a + b) + cos(a - b))
if PowerQ(i):
if i.has(sin):
if (i.rewrite(sin, exp).expand().rewrite(exp, sin)).has(I):
return i.rewrite(sin, exp).expand().rewrite(exp, sin).simplify()
else:
return i.rewrite(sin, exp).expand().rewrite(exp, sin)
if i.has(cos):
if (i.rewrite(cos, exp).expand().rewrite(exp, cos)).has(I):
return i.rewrite(cos, exp).expand().rewrite(exp, cos).simplify()
else:
return i.rewrite(cos, exp).expand().rewrite(exp, cos)
else:
return i</pre>
<p>Some tests for <code>TrigReduce()</code></p>
<pre> assert TrigReduce(cos(x)**2) == cos(2*x)/2 + 1/2
assert TrigReduce(cos(x)**2*sin(x)) == sin(x)/4 + sin(3*x)/4
assert TrigReduce(cos(x)**2+sin(x)) == sin(x) + cos(2*x)/2 + 1/2
assert TrigReduce(cos(x)**2*sin(x)**5) == 5*sin(x)/64 + sin(3*x)/64 - 3*sin(5*x)/64 + sin(7*x)/64
assert TrigReduce(2*sin(x)*cos(x) + 2*cos(x)**2) == sin(2*x) + cos(2*x) + 1</pre>
<p>I have taken some help from a reply in <a href="https://stackoverflow.com/questions/30541734/how-to-rewrite-sinx2-to-cos2x-form-in-sympy">stackoverflow</a> and may be now we can answer that question much better.</p>
<p>My next week’s target would be to complete all the utility functions and fix bugs as much as possible.</p><br /> <a href="http://feeds.wordpress.com/1.0/gocomments/nesar2017.wordpress.com/237/" rel="nofollow"><img alt="" border="0" src="http://feeds.wordpress.com/1.0/comments/nesar2017.wordpress.com/237/" /></a> <img alt="" border="0" height="1" src="https://pixel.wp.com/b.gif?host=nesar2017.wordpress.com&blog=126779945&post=237&subd=nesar2017&ref=&feed=1" width="1" />https://gxyd.github.io/blogs/Gsoc2017-week-6Gaurav Dhingra (gxyd)Gaurav Dhingra (gxyd): GSoC 2017: Week 6Wed, 19 Jul 2017 00:00:00 GMT
https://gxyd.github.io/blogs/Gsoc2017-week-6/
<p>We worked on <a href="https://github.com/sympy/sympy/pull/12885">Parametric logarithmic derivative PR #12885</a> only this week. So now I will get to a few mathematical points regarding the problem of “parametric logarithmic derivative” problem (will shortly write it as <code class="highlighter-rouge">PLD</code> problem).</p>
<p>The <code class="highlighter-rouge">PLD</code> problem is, for a given hyperexponential monomial over a differential field and , to decide whether there exists with , for the equation: , and to find one such solution.</p>
<p>There are two versions of it, the first one being the heursitic version which is quite simple (with available pseudo code) and is already implemented in SymPy, but since it doesn’t handle all the cases, it becomes necessary to have the deterministic version of it. The deterministic version is sort of used as a fallback i.e in case the heuristic version fails (raises <code class="highlighter-rouge">NotImplementedError</code>) which isn’t quite often.</p>
<p>We already have done the basic programming of it in SymPy, so before I say any further let’s see an example.</p>
<p>A simple example of where the heuristic version fails is:</p>
<div class="highlighter-rouge"><pre class="highlight"><code>>>> fa, fd = Poly(1, x), Poly(1, x)
>>> wa, wd = Poly(1, x), Poly(1, x)
>>> DE = DifferentialExtension(extension={'D': [Poly(1, x, domain='ZZ'), Poly(t, t, domain='ZZ')], 'exts': [None, 'exp']})
>>> parametric_log_deriv_heu(fa, fd, wa, wd, DE)
None
# while the deterministic version, runs fine
>>> parametric_log_deriv(fa, fd, wa, wd, DE)
[Matrix([[-1, 1, 0]]), Matrix([[-1, 0, 1]])] # don't worry about output type
</code></pre>
</div>
<blockquote>
<h2 id="internals-of-deterministic-version">Internals of deterministic version</h2>
</blockquote>
<p>In the deterministic version we use the Risch’s structure theorem, i.e</p>
<p> ( equation 1)</p>
<p>where we solve for each .</p>
<p>This result of structure theorem is quite useful, this same theorem can be used in the process of <code class="highlighter-rouge">DifferentialExtension</code> construction, as can be seen the section 5.2 in book (Outline and Scope of Integration Algorithm, search by section name if you have a different version of the book).</p>
<p>In <code class="highlighter-rouge">PLD</code> (deterministic) we first obtain the and parts depending on ‘log’/’exp’ extension respectively and store them in a list <code class="highlighter-rouge">F</code> (the order wouldn’t matter).</p>
<p>We reorganize this problem in a way somewhat similar to <code class="highlighter-rouge">limited_integrate</code> problem, i.e , we solve the problem and chose the one where .</p>
<p>The same thing we do here in this problem, but that does cause some problem as may not necesarily be contained in the extension , and currently we are working on solving this part of the problem, Kalevi suggests to take the unfinished <code class="highlighter-rouge">DE</code> object and the extension containing could be built on that.(No need to start from scratch.)</p>
<p>I haven’t mentioned much regarding the function that does the working for converting the relation in eq (1) over a field to one over . It contains <code class="highlighter-rouge">Poly</code> manipulation methods to do that. It does mathematically the same thing as “to obtain a system with coefficients in C and the same constant solutions.”</p>
<p>I’ll complete the <code class="highlighter-rouge">parametric_log_deriv</code> before the next week starts.</p>https://szymag.github.io/post/week-7/Szymon Mieszczak (szymag)Szymon Mieszczak (szymag): Week 7Tue, 18 Jul 2017 19:41:21 GMT
https://szymag.github.io/post/week-7/
<p>During week 7 I continued my work on transformation equations for rotation. One PR #12960 which obtains transformation equations from rotation matrix was merged. I have prepared also method for composition of transformation equation but I didn’t push them. I need to still think how to arrange the whole structure. My mentor suggest that we can just use transformation equations instead of rotation matrix, because it’s just general concept. After that we could modify constructor in CoordSys3D class and put them transformation equation instead of rotation matrix.https://shikharj.github.io//2017/07/18/GSoC-Progress-Week-7Shikhar Jaiswal (ShikharJ)Shikhar Jaiswal (ShikharJ): GSoC Progress - Week 7Tue, 18 Jul 2017 00:00:00 GMT
https://shikharj.github.io//2017/07/18/GSoC-Progress-Week-7/
<p>My seventh report on my GSoC progress. It’s been quite a journey so far, full of challenges and rewards. This week, apart from the work, I took some time to write a proposal for a full fledged talk at the upcoming <code class="highlighter-rouge">PyCon India 2017</code> Conference, titled <code class="highlighter-rouge">SymEngine: Leveraging The Power Of A Computer Algebra System (CAS) To Another</code> to be held during the first week of <code class="highlighter-rouge">November 2017</code> in <code class="highlighter-rouge">New Delhi</code>. What’s more exciting is that Sumith and Ranjith would be there as well, hopefully if it gets selected.</p>
<h2 id="report">Report</h2>
<h3 id="symengine">SymEngine</h3>
<p>I pushed in <a href="https://github.com/symengine/symengine.py/pull/1308">#1308</a> fixing a minor <code class="highlighter-rouge">Travis</code> irregularity.</p>
<h3 id="symenginepy">SymEngine.py</h3>
<p>I pushed in <a href="https://github.com/symengine/symengine.py/pull/176">#176</a>, a minor PR for skipping some of the tests where <code class="highlighter-rouge">SymPy</code> wasn’t being used.</p>
<p>Most of my time this week was spent on finding inconsistencies between <code class="highlighter-rouge">SymEngine</code> and <code class="highlighter-rouge">SymPy</code> objects which arise while using <code class="highlighter-rouge">SymEngine</code> in <code class="highlighter-rouge">SymPy</code>. I’m currently maitaining a log of all the issues that are occuring and their possible solutions. As such, I have decided to make a small change in our strategy. For the coming week, I’ll try and complete the issue log, and implement the possible missing functionalities and attributes in <code class="highlighter-rouge">SymEngine.py</code>, after which a minor release in <code class="highlighter-rouge">SymEngine</code> and <code class="highlighter-rouge">SymEngine.py</code> would be made to make these changes available for <code class="highlighter-rouge">SymPy</code>.</p>
<p>Till Next Time!</p>
<p><strong>Ciao</strong></p>http://arif7blog.wordpress.com/?p=677Arif Ahmed (ArifAhmed1995)Arif Ahmed (ArifAhmed1995): Week 7 Report(July 11 – July 17) : Implicit IntersectionsMon, 17 Jul 2017 19:24:49 GMT
https://arif7blog.wordpress.com/2017/07/17/week-7-reportjuly-11-july-17-implicit-intersections/
<p>I had initially planned to begin implementing the 3D case this week. But I wanted closure for the 2D case. Currently there is no support for implicit intersections for polygons. One could make the failing tests pass by not raising an error when such a polygon is encountered, but obviously that wouldn’t be a good solution.<br />
So, from the discussion in pull request <a href="https://github.com/sympy/sympy/pull/12931" rel="noopener" target="_blank">#12931 </a>:</p>
<p>1. Fleury’s algorithm is not required. A better approach to calculate area would be to simply flip the sides after crossing an intersection point and come back to initial direction of traversal once that point is encountered again. I have implemented this technique locally. It has worked fine for the following polygons but still seems to have some minor bugs which I’ll fix really soon. Once that’s done I’ll update the pull request.</p>
<pre><code>>>> p1 = Polygon((0,-3), (-1,-2), (2,0), (-1,2), (0,3))
>>> p1.area
-13/3
>>> p2 = Polygon((0,0), (1,0), (0,1), (1,1))
>>> p2.area
1/2</code></pre>
<p>All of this was because of the material <span style="color: #99cc00;"><a href="https://codegolf.stackexchange.com/questions/47638/area-of-a-self-intersecting-polygon/47640" rel="noopener" target="_blank">here</a></span>.</p>
<p>2. The intersections are currently being found by a slow technique which I designed. A much better one by the name of Bentley-Ottmann algorithm exists for the same purpose. Once I get the area working for all the test cases on the <span style="color: #99cc00;"><a href="https://codegolf.stackexchange.com/questions/47638/area-of-a-self-intersecting-polygon/47640" rel="noopener" target="_blank">codegolf link</a></span>, I’ll work on implementing this.</p>
<p>3. Christopher also suggested that we add a property called footprint_area, which would refer to area that a polygon covers(i.e. the hull of the polygon) and another property called hull which would refer to that very path. I was initially confusing this area with the area that depends on direction. Now I see that this footprint area isn’t the one normally referred to when talking about the area of a polygon and it’s actually the other one.</p><br /> <a href="http://feeds.wordpress.com/1.0/gocomments/arif7blog.wordpress.com/677/" rel="nofollow"><img alt="" border="0" src="http://feeds.wordpress.com/1.0/comments/arif7blog.wordpress.com/677/" /></a> <img alt="" border="0" height="1" src="https://pixel.wp.com/b.gif?host=arif7blog.wordpress.com&blog=126429718&post=677&subd=arif7blog&ref=&feed=1" width="1" />http://valglad.github.io/2017/07/17/presentationValeriia Gladkova (valglad)Valeriia Gladkova (valglad): Presentations of Permutation GroupsMon, 17 Jul 2017 00:00:00 GMT
http://valglad.github.io/2017/07/17/presentation/
<p>The work on finding finite presentations of permutation groups was somewhat delayed last week because I’ve come across a bug in the <code class="highlighter-rouge">reidemester_presentation</code> code while testing the one step version of the presetation algorithm (which is essentially finished). Turned out it was caused by an unnecessary cyclic reduction on one line in the main elimination technique. See <a href="https://github.com/sympy/sympy/pull/12973">PR</a> for the explanation.</p>
<p>Another delay was because I realised that for the multi-step version, it would be useful to have the homomorphism <a href="https://github.com/sympy/sympy/pull/12827">PR</a> merged. Mostly this is because of the <code class="highlighter-rouge">generator_product</code> method from the <code class="highlighter-rouge">PermutationGroup</code> class - this takes an arbitrary permutation in the group and returns a list of the strong generators such that the product of the elements of the list is equal to this permutation. But the homomorphism functionality that’s already there (the case of the homomorphism from an <code class="highlighter-rouge">FpGroup</code> to a <code class="highlighter-rouge">PermutationGroup</code>) would be helpful too. So I switched by attention to getting that PR ready for merging.</p>
<p>So this week I’ll try to add the multistep version and will also start implementing homomorphisms from <code class="highlighter-rouge">PermutationGroup</code>s and to <code class="highlighter-rouge">FpGroup</code>s, as outlined in the plan. Also, at some point when the rewriting PR is merged, I could try out the potentially improved random element generator for <code class="highlighter-rouge">FpGroup</code>s that I sketched a couple of weeks ago. This is not officially part of the plan and not in any way urgent, but could probably give better random elements which would be useful for the <code class="highlighter-rouge">order()</code> method and the kernel calculation for homomorphisms. Though I might not actually get around to it this week.</p>https://parsoyaarihant.github.io/blog/gsoc/2017/07/16/GSoC17-Week6-ReportArihant Parsoya (parsoyaarihant)Arihant Parsoya (parsoyaarihant): GSoC17 Week 6 ReportSun, 16 Jul 2017 06:30:00 GMT
https://parsoyaarihant.github.io/blog/gsoc/2017/07/16/GSoC17-Week6-Report.html
<p>Manuel has implemented Optional arguments in MatchPy. I am currently working on modifying our current parser to accommodate the changes. Optional arguments in MatchPy will enable us to add all rules to <code class="highlighter-rouge">ManyToOneReplacer</code> without increasing the number of rules. Manuel has been helping us a lot in making Rubi work in SymPy. He has also found a way to add MatchPy expressions in SymPy. I will try to use it to implement <a href="http://reference.wolfram.com/language/ref/MatchQ.html.en">MatchQ</a> in SymPy.</p>
<h3 id="expandintegrand">ExpandIntegrand</h3>
<p>ExpandIntegrand takes up majority of time while integration. I have implemented <code class="highlighter-rouge">ExpandIntegrand</code> using SymPy’s <code class="highlighter-rouge">.match()</code>. However, <code class="highlighter-rouge">.match()</code> can give unwanted results such as:</p>
<div class="language-python highlighter-rouge"><pre class="highlight"><code><span class="o">>>></span> <span class="p">(</span><span class="n">x</span><span class="o">**</span><span class="n">a</span><span class="p">)</span><span class="o">.</span><span class="n">match</span><span class="p">((</span><span class="n">c_</span> <span class="o">+</span> <span class="n">d_</span><span class="o">*</span><span class="n">x</span><span class="p">)</span><span class="o">**</span><span class="n">n_</span><span class="p">)</span>
<span class="p">{</span><span class="n">d_</span><span class="p">:</span> <span class="mi">1</span><span class="p">,</span> <span class="n">c_</span><span class="p">:</span> <span class="mi">0</span><span class="p">,</span> <span class="n">n_</span><span class="p">:</span> <span class="n">a</span><span class="p">}</span>
</code></pre>
</div>
<p>In the above example, it assumes that c_ is an optional variable when we don’t want it to be. To orevent these situations, I used <code class="highlighter-rouge">exclude</code> attribute to avoid these situations:</p>
<div class="language-python highlighter-rouge"><pre class="highlight"><code><span class="o">>>></span> <span class="n">c_</span> <span class="o">=</span> <span class="n">Wild</span><span class="p">(</span><span class="s">'c'</span><span class="p">,</span> <span class="n">exclude</span><span class="o">=</span><span class="p">[</span><span class="mi">0</span><span class="p">])</span>
<span class="o">>>></span> <span class="n">d_</span> <span class="o">=</span> <span class="n">Wild</span><span class="p">(</span><span class="s">'d'</span><span class="p">,</span> <span class="n">exclude</span><span class="o">=</span><span class="p">[</span><span class="mi">0</span><span class="p">])</span>
<span class="o">>>></span> <span class="n">n_</span> <span class="o">=</span> <span class="n">Wild</span><span class="p">(</span><span class="s">'n'</span><span class="p">,</span> <span class="n">exclude</span><span class="o">=</span><span class="p">[</span><span class="mi">0</span><span class="p">])</span>
<span class="o">>>></span> <span class="p">(</span><span class="n">x</span><span class="o">**</span><span class="n">a</span><span class="p">)</span><span class="o">.</span><span class="n">match</span><span class="p">((</span><span class="n">c_</span> <span class="o">+</span> <span class="n">d_</span><span class="o">*</span><span class="n">x</span><span class="p">)</span><span class="o">**</span><span class="n">n_</span><span class="p">)</span>
<span class="bp">None</span>
</code></pre>
</div>
<p>I have used the above trick to prevent unnecessary matches in <code class="highlighter-rouge">ExpandIntegrand</code> and made it a bit faster.</p>
<h3 id="todo">TODO</h3>
<ul>
<li>Implement parser without <code class="highlighter-rouge">powerset</code> and parse all Rubi rules.</li>
<li>Fix failing tests.</li>
<li>Add all algebraic tests in Rubi.</li>
</ul>http://nesar2017.wordpress.com/?p=217Abdullah Javed Nesar (Abdullahjavednesar)Abdullah Javed Nesar (Abdullahjavednesar): GSoC Progess ReportWed, 12 Jul 2017 12:05:27 GMT
https://nesar2017.wordpress.com/2017/07/12/gsoc-progess-report/
<p>So far we have covered almost all the Utility Functions to support <strong>Algebraic Rules/Linear Products rules</strong>, Arihant had given the entire details of the first test set in his recent blog post once we are successfully done with the first set we have the other two test sets for Linear Products ready to work on.</p>
<p>Currently I’m work on implementation of <strong>Normalization functions</strong>, although I have implemented <code class="highlighter-rouge">NormalizeIntegrandFactorBase</code> using SymPy’s pattern matcher but that needs a bit improvisation. After that I’ll complete implementation of <code class="highlighter-rouge">SimpHelp</code>.<br />
May be a couple of weeks more and we’ll be done with the implementation of all the Utility Functions.</p>
<p> </p><br /> <a href="http://feeds.wordpress.com/1.0/gocomments/nesar2017.wordpress.com/217/" rel="nofollow"><img alt="" border="0" src="http://feeds.wordpress.com/1.0/comments/nesar2017.wordpress.com/217/" /></a> <img alt="" border="0" height="1" src="https://pixel.wp.com/b.gif?host=nesar2017.wordpress.com&blog=126779945&post=217&subd=nesar2017&ref=&feed=1" width="1" />https://gxyd.github.io/blogs/Gsoc2017-week-5Gaurav Dhingra (gxyd)Gaurav Dhingra (gxyd): GSoC 2017: Week 5Wed, 12 Jul 2017 00:00:00 GMT
https://gxyd.github.io/blogs/Gsoc2017-week-5/
<p>We started working on implementation of <a href="https://github.com/sympy/sympy/pull/12885">parametric logarithmic derivative problem using Risch structure Theorem</a>. First we implemented the function <code class="highlighter-rouge">basis_Q</code>, which seems like we wouldn’t be needing no-more. While doing that it seemed like there was problem with the <code class="highlighter-rouge">.is_algebraic</code> property, as it was returning <code class="highlighter-rouge">(pi**3).is_algebraic</code> as True. This bug was fixed in the pull request <a href="https://github.com/sympy/sympy/pull/12924">#12924</a>.</p>
<p>Also a few improvements to the <a href="https://gxyd.github.io/:/github.com/sympy/sympy/pull/12925">integral module pull request #12925</a> was also merged.</p>
<p>I don’t have much to say for now, until I complete the parametric logarithmic derivate PR.</p>