Planet SymPy
http://planet.sympy.org/
enPlanet SymPy - http://planet.sympy.org/http://ishanaj.wordpress.com/?p=60Ishan Joshi (ishanaj)Ishan Joshi (ishanaj): GSoC’19: Week-8- The draw() function in actionMon, 22 Jul 2019 04:50:39 GMT
https://ishanaj.wordpress.com/2019/07/22/gsoc19-week-8-the-draw-function-in-action/
<p>The 8<sup>th</sup> week has ended and we are now in the middle of phase –III.</p>
<p>Last week was a bit of research-based, understanding <strong>matplotlib </strong>and how it can be used to plot a beam diagram. I had a conversation with Jason Moore and Jashan where Jason shared a link of a <a href="https://github.com/alfredocarella/simplebendingpractice">repository</a>, which also was a bit of help as I took some hints from it for the <strong>draw() </strong>function. After a lot of investigation and analysis, I was finally able to make a draft <a href="https://github.com/sympy/sympy/pull/17240">PR # 17240</a> which did the work as we intended.</p>
<p>Here is an example of how it would function:</p>
<pre class="brush: python; collapse: false; title: ; wrap-lines: false; notranslate">
# This example has no prior logic involved. It just tests whether every functionality works or not
>>> E, I = symbols('E, I')
>>> b1 = Beam(50, E, I)
>>> b1.apply_load(-10, 0, -1)
>>> b1.apply_load(R1, 10, -1)
>>> b1.apply_load(R2, 30, -1)
>>> b1.apply_load(9, 5, 0, 23)
>>> b1.apply_load(9, 30, 1, 50)
>>> b1.apply_support(50, "pin")
>>> b1.apply_support(0, "fixed")
>>> b1.apply_support(20, "roller")
>>> b1.draw()
</pre>
<figure class="wp-block-image size-large is-resized .single-blog-image {display: none; }"><img alt="" class="wp-image-62" height="387" src="https://ishanaj.files.wordpress.com/2019/07/61594696-552b5900-ac0c-11e9-96f9-4ba257dbf92c-1.png?w=467&h=387" width="467" /></figure>
<p>Here we are using <strong>matplotlib</strong> and <strong>numpy</strong> by importing them as external modules. Of course, it would be better to have it done via <strong>SymPy’s</strong> own <strong>plot()</strong>, but I think that is something we could work on in later stages as<strong> SymPy’s plot()</strong> is limited to work on equations and stuff (although on can use <strong>_backend </strong>attribute for further functionalities).  Also to be noted here that <strong>SymPy’s plot()</strong> is not a replica of <strong>matplotib’s plot()</strong> but it makes it easier for SymPy equation to be plotted and it uses <strong>matplotlib</strong> to do so.</p>
<p>Following are the<strong> m</strong><strong>atplotlib</strong> modules/classes used:</p>
<ul><li><a href="https://matplotlib.org/api/_as_gen/matplotlib.patches.Rectangle.html">matplotlib.patches.Rectangle</a> -to draw the beam</li><li><a href="https://matplotlib.org/api/_as_gen/matplotlib.pyplot.annotate.html">matplotlib.pyplot.annotate</a> – to draw arrows of load</li><li><a href="https://matplotlib.org/3.1.1/api/markers_api.html">matplotlib.markers</a>– to draw supports</li></ul>
<p>Also, considering Jason’s <a href="https://github.com/sympy/sympy/pull/17240#issuecomment-513577696">comment</a> in the PR, I will have to work on making <strong>SymPy’s plot()</strong> to accept a singularity function, so that it would be easier to plot <strong>loads </strong>which are indeed equations of Singularity function. This is still in consideration, so I will have to look into it and of course will have a discussion on how it is to be done.</p>
<p>Currently, I am not able to determine how to plot parabolic loads. I think this could be added later as we should currently focus on plotting simple parts and certainly work on other complexities later. But we can have a discussion on it.</p>
<p>Other PR’s are still being parallelly worked on.</p>
<h2><strong>Next Week:</strong></h2>
<ul><li>Working on the idea of plotting singularity function via SymPy’s plot()</li><li>Plotting parabolic loads</li><li>Writing documentation and tests</li></ul>
<p>Will keep you updated!</p>
<p>Thanks!</p>https://divyanshu132.github.io//gsoc-week-8Divyanshu Thakur (divyanshu132)Divyanshu Thakur (divyanshu132): GSoC 2019 - Week 8 - Phase-II CompletionSat, 20 Jul 2019 00:00:00 GMT
https://divyanshu132.github.io//gsoc-week-8
<p>Phase-II has been completed and now it’s time to present all the work done during this phase. This week’s blog is little early in comparison to my previous blogs because I’ll not be active for next 2 upcoming days. In the whole phase we worked on <strong>Computations with Polycyclic Groups</strong> though the tasks mentioned in proposal for this phase were quite different. But let me tell you it worth that much time, Computation with Polycyclic groups(solvable groups) shows the actual development in computational group theory.</p>
<p>Below are the functioalities that were added to the polycyclic group in this phase, Here is the PR <a href="https://github.com/sympy/sympy/pull/16991">sympy/sympy#16991</a>.</p>
<p><strong>Testing Collector</strong></p>
<p>As discussed in <a href="https://divyanshu132.github.io/gsoc-week-5">week-5 blog</a> at the time of Collector implementation we did not have the implementation of polycyclic presentation so some hand made tests were used. Here is an example of <code class="highlighter-rouge">S(4)</code>.</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>>>> from sympy.combinatorics import *
>>> from sympy.combinatorics.free_groups import free_group
>>> F, x0, x1, x2, x3 = free_group("x0, x1, x2, x3")
>>> pc_relators = { x0**2: (), x1**3: (), x2**2: (), x3**2: (),
... x0**-1*x1*x0: x1**2, x0**-1*x2*x0: x2*x3,
... x0**-1*x3*x0: x3, x1**-1*x2*x1: x3,
... x1**-1*x3*x1: x2*x3, x2**-1*x3*x2: x3
... }
>>> word = x3*x2*x1*x0
>>> relative_order = [2, 3, 2, 2]
>>> group = word.group
>>> collector = Collector(pc_relators, relative_order, group)
>>> collector.collected_word(word)
x0*x1**2*x2*x3
</code></pre></div></div>
<p>The final word <code class="highlighter-rouge">x0*x1**2*x2*x3</code> is said to be collected. For more information about collected word please look into the docstrings of the method <code class="highlighter-rouge">Collector.collected_word()</code>.</p>
<p><strong>Computation of Polycyclic Sequence and Series</strong></p>
<p>Polycyclic sequence and series are the building blocks of polycyclic presentation (have a look at <a href="https://divyanshu132.github.io/gsoc-week-6">week-6 blog</a>) . One thing to note is that, the derived series of a group may change on different course of execution so we may have different pc sequence and series for the same group.</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>>>> from sympy.combinatorics import *
>>> G = SymmetricGroup(4)
>>> PcGroup = G.polycyclic_group()
>>> PcGroup.pcgs
[Permutation(0, 1, 2, 3), Permutation(3)(0, 2, 1), Permutation(0, 3)(1, 2), Permutation(0, 1)(2, 3)]
>>>
>>> PcGroup.pc_series[0] == G
True
>>> PcGroup.pc_series[1] == AlternatingGroup(4)
True
>>> PcGroup.relative_order()
[2, 3, 2, 2]
</code></pre></div></div>
<p><strong>Computation of Polycyclic Presentation</strong></p>
<p>Few approaches were used to compute polycyclic presentation, the current implementation is discussed in <a href="https://divyanshu132.github.io/gsoc-week-7">week-7 blog</a>. Below is a small example to show the functionality.</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>>>> from sympy.combinatorics import *
>>> G = SymmetricGroup(4)
>>> PcGroup = G.polycyclic_group()
>>> from sympy.combinatorics.free_groups import free_group
>>> len(PcGroup.pcgs)
4
>>> free_group, x0, x1, x2, x3 = free_group("x0, x1, x2, x3")
>>> PcGroup.pc_presentation(free_group)
{x3**2: (), x2**2: (), x2**-1*x3*x2: x3, x1**3: (), x1**-1*x3*x1: x2*x3, x1**-1*x2*x1: x3, x0**2: x2*x3, x0**-1*x3*x0: x2, x0**-1*x2*x0: x3, x0**-1*x1*x0: x1**2*x3}
</code></pre></div></div>
<p>As I mentioned above <code class="highlighter-rouge">pc_sequence</code> and <code class="highlighter-rouge">pc_series</code> may change on different course of execution and hence the <code class="highlighter-rouge">pc_presentation</code> changes accordingly.</p>
<p><strong>Testing Presentation</strong></p>
<p>Due to the changing <code class="highlighter-rouge">pc_presentation</code> initially, it was difficult to test presentation but later on a method has been developed and a good amount of code is introduced to test the presentation. The details can be found in the module <code class="highlighter-rouge">test_pc_groups.py</code> in the above PR.</p>
<p><strong>Additional methods for Polycyclic groups</strong></p>
<p>There were few additional methods added to the polycyclic group.</p>
<ul>
<li><code class="highlighter-rouge">exponent_vector()</code> :- It represents the given generator of a polycyclic group with the help of product of <code class="highlighter-rouge">pcgs</code>.</li>
<li><code class="highlighter-rouge">depth()</code> :- Depth of the first non-zero element in <code class="highlighter-rouge">exponent_vector</code>.</li>
<li><code class="highlighter-rouge">leading_exponent()</code> :- It represents the power of polycyclic generator at the above depth.</li>
</ul>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>>>> from sympy.combinatorics import *
>>> from sympy.combinatorics.free_groups import free_group
>>> G = SymmetricGroup(4)
>>> PcGroup = G.polycyclic_group()
>>> pcgs = PcGroup.pcgs
>>> len(pcgs)
4
>>> free_group, x0, x1, x2, x3 = free_group("x0, x1, x2, x3")
>>> PcGroup.exponent_vector(G[1], F)
[1, 1, 1, 1]
>>> G[1] == pcgs[0]*pcgs[1]*pcgs[2]*pcgs[3]
True
>>> PcGroup.depth(G[1], free_group) == 1
>>> PcGroup.leading_exponent(G[1], free_group) == 1
</code></pre></div></div>
<p>Currently, we are discussing about organizing above methods of polycyclic group. As Kalevi feels that the suitable place for <code class="highlighter-rouge">pc_presentation</code>(currently, it’s a method of <code class="highlighter-rouge">PolycyclicGroup class</code>) is the <code class="highlighter-rouge">Collector class</code>, Perhaps the structure of both the classes should be changed and the same will be reflected in the examples mentioned above.</p>https://jmig5776.github.io//gsoc-week-8Jogi Miglani (jmig5776)Jogi Miglani (jmig5776): GSoC 2019 - Week 6Sat, 20 Jul 2019 00:00:00 GMT
https://jmig5776.github.io//gsoc-week-8
<p>This was the eigth week meeting with the GSoC mentors which was scheduled on
Saturday 20th July, 2019 between 12:30 - 1:30 PM (IST). Me, Yathartha and Amit
were the attendees of the meeting.
Finally the PR <a href="https://github.com/sympy/sympy/pull/16890">#16890</a> is merged to
Sympy master and the work for Lambert has been completed. It was only possible
because of the mentors and especially @smichr for his great suggestions in code.</p>
<ul>
<li>Discussing previous week’s progress</li>
</ul>
<p>In this meeting the goals for the time left for GSoC were decided as follows:-</p>
<ol>
<li>
<p>Lambert:- Completed and merged.</p>
</li>
<li>
<p>Solve modular:-
What I experienced with lambert’s PR that got stretched so much which I was not
expecting. Algorithms made from heuristics takes so much time to be ready for
merging so I really don’t know how much time it will take. But It is sure that
it will be completed before the final evaluation.</p>
</li>
<li>
<p>ImageSet Union:- This task will be taken after the solve modular. This is a
very complex task and will need proper guidance and algorithm. I had searched
for some research papers, but what I found out was not that what we want.
Before GSoC final evaluation this task will be started to implement, but I am
not really sure if it would get merged before final evaluation.</p>
</li>
</ol>
<ul>
<li>
<p>Next week goals</p>
</li>
<li>
<p>Work upon <code class="highlighter-rouge">_solve_modular</code> PR</p>
</li>
<li>
<p>If time left then find plan for Imageset Union.</p>
</li>
</ul>
<p>Code improvement takes time!!</p>https://sc0rpi0n101.github.io/2019/07/week-8boys-we-got-a-plan./Nikhil Maan (Sc0rpi0n101)Nikhil Maan (Sc0rpi0n101): Week 8:Boys!! We got a Plan.Sat, 20 Jul 2019 00:00:00 GMT
https://sc0rpi0n101.github.io/2019/07/week-8boys-we-got-a-plan./
<p>“Those who plan do better than those who do not plan even though they rarely stick to their plan.” ― Winston Churchill
Welcome everyone, this is your host Nikhil Maan aka Sc0rpi0n101 and this week I have some good news for you all. We have got a few plans to get the progress of the project rolling as the second evaluation approaches. The meeting also took place this week, so, after waiting for so long, we have some good insights from the meeting this time.https://arighnaiitg.github.io/2019-07-15-gsoc-week7/Arighna Chakrabarty (arighnaiitg)Arighna Chakrabarty (arighnaiitg): GSoC Week 7 !!Mon, 15 Jul 2019 07:00:00 GMT
https://arighnaiitg.github.io/2019-07-15-gsoc-week7/
<p>Week 7 ends.. -
Phase 2 of the coding period is smoothly being traversed. I recently had a meeting with Sartaj on 11th of July, Thursday. Here were the minutes of the meeting, along with the deliverables completed over the week. The FiniteFormalPowerSeries class PR needs some changes. Currently, it is taking in an...http://ishanaj.wordpress.com/?p=58Ishan Joshi (ishanaj)Ishan Joshi (ishanaj): GSoC’19: Week-7- Starting with the phase-III draw() functionMon, 15 Jul 2019 03:02:10 GMT
https://ishanaj.wordpress.com/2019/07/15/gsoc19-week-7-starting-with-the-phase-iii-draw-function/
<p>The week was successfully completed as planned. The work on <a href="https://github.com/sympy/sympy/pull/17122">Column class</a> has been completed.</p>
<p>The documentation and tests have been written and with some changes in the <strong>solve_slope_deflection()</strong> and <strong>critical_load(),</strong> the <strong>Column</strong> class is now able to handle cases with trivial solutions of the constants ( C1 & C2) which made the deflection equation zero.</p>
<p>Apart from this, another problem that we had with the <strong>pinned-fixed</strong> end condition, where <strong>solve()</strong> wasn’t giving the output in the required form, has temporary been handled by making an <strong>XFAIL </strong>test against it. We can work on it later. Either there has to be some changes in <strong>solve()</strong> so that we would be able to handle our case or we might have to figure out a way to rewrite it into the desired form.</p>
<p>With the end of this week, <a href="https://github.com/sympy/sympy/pull/17122">PR #17122</a> and <a href="https://github.com/sympy/sympy/pull/17153">PR #17153</a> are complete and ready for review. I have made some changes addressing some of the reviews, and we can have further discussions on it.</p>
<p>Now, also moving on to the next phase, I have done a bit of research on it. I will most probably open a discussion to have an initial discussion regarding how work will progress in this stage. This phase is regarding plotting the beam diagrams using <a href="https://matplotlib.org/">matplotlib</a>. I have also considered <strong>pyglet</strong> plotting module of SymPy, which according to the <a href="https://docs.sympy.org/latest/modules/plotting.html#plotting-geometric-entities">documentation</a> is capable of plotting geometries, but there has been some problems in this module and it doesn’t seem to be working well. I had earlier made an <a href="https://github.com/sympy/sympy/issues/16537">issue #16537</a> regarding the same, but there seems to be no improvement here.</p>
<p>So, we will be discussing the rest in an issue-cum-discussion, in the upcoming week.</p>
<p><strong>Next week:</strong></p>
<ul>
<li>Working on the Stage-III</li>
<li>Simultaneously, discussing the leftover PR’s and trying to finish them and make a merge.</li>
</ul>
<p>Most probably, on successful discussion and planning, I will be opening a draft work-in-progress PR for the <strong>draw()</strong> function in stage –III.</p>
<p>Will keep you updated!</p>
<p>Thanks!</p>https://czgdp1807.github.io/week_7Gagandeep Singh (czgdp1807)Gagandeep Singh (czgdp1807): Week 7 - All about logics and algorithmsMon, 15 Jul 2019 00:00:00 GMT
https://czgdp1807.github.io/week_7/
<p>This week required a lot of thinking before jumping to code the stuff. Interested? Okay move on to next paragraph.</p>
<p>Basically, I worked on three PRs, <a href="https://github.com/sympy/sympy/pull/17163">#17163</a> for continuous time Markov chains, <a href="https://github.com/sympy/sympy/pull/17174">#17174</a> for random matrices and <a href="https://github.com/sympy/sympy/pull/17146">#17146</a> for symbolic Ranges. The first and the last PRs are very much intensive. I developed a new algorithm for the query handler of <code class="highlighter-rouge">ContinuousMarkovChain.probability</code> method, because the previous one which I implemented in <code class="highlighter-rouge">DiscreteMarkovChain.probability</code>, was not easy to maintain, quite ad-hoc, rigid and difficult to extend. The philosophy behind the algorithm is recursion i.e., boil everything down to <code class="highlighter-rouge">Relational</code> query, convert them to sets and then calculate the probability. You can find the complete description <a href="https://github.com/sympy/sympy/pull/17163#issuecomment-510939984">here</a>. I am waiting for any critical objections from my mentors and after that I will refactor the code as suggested by <a href="https://github.com/oscarbenjamin">oscarbenjamin</a> and <a href="https://github.com/jksuom">jksuom</a>. So, now let’s move on to random matrices. As it was to be implemented from scratch, it required a bit of thinking to reach a decent architecture. Currently, the PR is at a basic level, and some more testing is to be done. Now, coming on to symbolic <code class="highlighter-rouge">Range</code>. Let me tell you, it requires a lot of logical thinking to make <code class="highlighter-rouge">Range</code> accept symbolic parameters. A lot of tests fail, and a lot of debugging has to be done to make a method work. In fact, we might deprecate <code class="highlighter-rouge">xrange</code> support from <code class="highlighter-rouge">Range</code> because we are going to drop <code class="highlighter-rouge">Python 2</code> support from <code class="highlighter-rouge">SymPy</code>.</p>
<p>This week I learnt to combine the concepts from algorithms and software engineering to develop the stuff I mentioned above. This was the best week of my overall GSoC experience till now.</p>
<p>A lot more lies ahead. Bye!!</p>https://divyanshu132.github.io//gsoc-week-7Divyanshu Thakur (divyanshu132)Divyanshu Thakur (divyanshu132): GSoC 2019 - Week 7 - Modify Presentation and Addition of MethodsMon, 15 Jul 2019 00:00:00 GMT
https://divyanshu132.github.io//gsoc-week-7
<p>The seventh week of coding period has ended and a few methods has been introduced to polycyclic groups, also pc presentation has been modified. Previously for pc presentation we were computing the LHS for both power and conjugate relators via separate methods and then finally their RHS was computed.</p>
<p>Now, the computation of presentation starts from the bottom of the polycyclic generating sequence(pcgs) and polycyclic series. Storing all the previous generators from pcgs and then taking the last generator as the generator which acts as a conjugator and conjugates all the previous generators in the list.</p>
<p>To get a clear picture let’s take an example of <code class="highlighter-rouge">S(4)</code>
For S(4) we’ll have 4 generators in pcgs say <code class="highlighter-rouge">[x0, x1, x2, x3]</code> and the <code class="highlighter-rouge">relative_order vector as [2, 3, 2, 2]</code>. Starting from bottom of this sequence the presentation is computed in order as below.</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>x3**2 ---| ---> using only [x3] from pcgs and pc_series[1]
x2**2 |
x2**-1*x3*x2 ---| from bottom up because pc_series[0] is an identity.
x1**3 ---| ---> using [x3, x2] from pcgs and pc_series[2]
x1**-1*x3*x1 |
x1**-1*x2*x1 ---| from bottom up(which have both the gens).
x0**2 ---| ---> using [x3, x2, x1] from pcgs and pc_series[3]
x0**-1*x3*x0 |
x0**-1*x2*x0 | from bottom up(which have all three gens).
x0**-1*x1*x0 ---|
</code></pre></div></div>
<p>There were 3-methods which were added namely:</p>
<ul>
<li>Exponent vector</li>
<li>Depth</li>
<li>Leading Exponent</li>
</ul>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>>>> from sympy.combinatorics import *
>>> from sympy.combinatorics.free_groups import free_group
>>> G = SymmetricGroup(4)
>>> PcGroup = G.polycyclic_group()
>>> pcgs = PcGroup.pcgs
>>> group, x0, x1, x2, x3 = free_group("x0, x1, x2, x3")
>>> PcGroup.exponent_vector(G[0], group)
[1, 0, 0, 0]
>>> exp = PcGroup.exponent_vector(G[1], group)
>>> g = Permutation()
>>> for i in range(len(exp)):
... g = g*pcgs[i] if exp[i] else g
...
>>> g == G[1]
True
>>>
</code></pre></div></div>
<p>For the details of these methods one can look into the docstrings and doctests of these methods in the PR <a href="https://github.com/sympy/sympy/pull/16991">sympy/sympy#16991</a>.</p>
<p>Tasks I hope to complete next week:</p>
<ul>
<li>Get the polycyclic group pr ready to be merged.</li>
<li>Get started with quotient groups.</li>
</ul>
<p>Till then good byee..</p>https://jmig5776.github.io//gsoc-weel-7Jogi Miglani (jmig5776)Jogi Miglani (jmig5776): Lambert Solver Of Sympy (GSoC 2019 - Week 7)Mon, 15 Jul 2019 00:00:00 GMT
https://jmig5776.github.io//gsoc-weel-7
<p>This was the seventh week meeting with the GSoC mentors which was scheduled on
Monday 15th July, 2019 between 6:00 - 7:00 PM (IST). Me and Yathartha
were the attendees of the meeting. In this blog I will be describing the lambert
equation solver for Sympy and what problems it faced before and how PR
<a href="https://github.com/sympy/sympy/pull/16890">#16890</a> will solve the problems.
It is preassumed that you know what lambert type equations are, so I will not be
explaining that.</p>
<h2 id="explaining-the-function-_solve_lambert-main-function-to-solve-lambert-equations">Explaining the function <code class="highlighter-rouge">_solve_lambert</code> (main function to solve lambert equations)</h2>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>Input - f, symbol, gens
OutPut - Solution of f = 0 if its lambert type expression else NotImplementedError
</code></pre></div></div>
<p>This function separates out cases as below based on the main function present in
the main equation.</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>For the first ones:
1a1) B**B = R != 0 (when 0, there is only a solution if the base is 0,
but if it is, the exp is 0 and 0**0=1
comes back as B*log(B) = log(R)
1a2) B*(a + b*log(B))**p = R or with monomial expanded or with whole
thing expanded comes back unchanged
log(B) + p*log(a + b*log(B)) = log(R)
lhs is Mul:
expand log of both sides to give:
log(B) + log(log(B)) = log(log(R))
1b) d*log(a*B + b) + c*B = R
lhs is Add:
isolate c*B and expand log of both sides:
log(c) + log(B) = log(R - d*log(a*B + b))
</code></pre></div></div>
<p>If the equation are of type 1a1, 1a2 and 1b then the mainlog of the equation is
taken into concern as the deciding factor lies in the main logarithmic term of equation.</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>For the next two,
collect on main exp
2a) (b*B + c)*exp(d*B + g) = R
lhs is mul:
log to give
log(b*B + c) + d*B = log(R) - g
2b) -b*B + g*exp(d*B + h) = R
lhs is add:
add b*B
log and rearrange
log(R + b*B) - d*B = log(g) + h
</code></pre></div></div>
<p>If the equation are of type 2a and 2b then the mainexp of the equation is
taken into concern as the deciding factor lies in the main exponential term of equation.</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>3) d*p**(a*B + b) + c*B = R
collect on main pow
log(R - c*B) - a*B*log(p) = log(d) + b*log(p)
</code></pre></div></div>
<p>If the equation are of type 3 then the mainpow of the equation is
taken into concern as the deciding factor lies in the main power term of equation.</p>
<p>Eventually from all of the three cases the equation is meant to be converted to this form:-</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>f(x, a..f) = a*log(b*X + c) + d*X - f = 0 which has the
solution, X = -c/b + (a/d)*W(d/(a*b)*exp(c*d/a/b)*exp(f/a)).
</code></pre></div></div>
<p>And the solution calculation process is done by <code class="highlighter-rouge">_lambert</code> function.</p>
<p>Everything seems flawless?? You might be thinking no modification is required. Lets
see what loopholes are there in it.</p>
<h2 id="what-does-pr-16890-do">What does PR <a href="https://github.com/sympy/sympy/pull/16890">#16890</a> do?</h2>
<p>There are basically two flaws present with the this approach.</p>
<ol>
<li>Not considering all branches of equation while taking log both sides.</li>
<li>Calculation of roots should consider all roots in case having rational power.</li>
</ol>
<h3 id="1-not-considering-all-branches-of-equation-while-taking-log-both-sides">1. Not considering all branches of equation while taking log both sides.</h3>
<p>Let us consider this equation to be solved by <code class="highlighter-rouge">_solve_lambert</code> function.</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>-1/x**2 + exp(x/2)/2 = 0
</code></pre></div></div>
<p>So what the old <code class="highlighter-rouge">_solve_lambert</code> do is to convert this equation to following.</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>2*log(x) + x/2 = 0
</code></pre></div></div>
<p>and calculates its roots from <code class="highlighter-rouge">_lambert</code>.
But it missed this branch of equation while taking log on main equation.</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>2*log(-x) + x/2 = 0
</code></pre></div></div>
<p>Yeah you can reproduce the original equation from this equation.So basically the problem
was that it missed the branches of equation while taking log. And when does the
main equation have more than one branch?? The terms having even powers of variable x
leads to two different branches of equation.</p>
<p>So how it is solved?
What I has done is that before actually gets into solving I preprocess the main equation
and if it has more than one branches of equation while converting taking log then I consider
all the equations generated from them.(with the help of <code class="highlighter-rouge">_solve_even_degree_expr</code>)</p>
<p>How I preprocess the equation?
So what I do is I replace all the even powers of x present with even powers of t(dummy variable).</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>Code for targeted replacement
lhs = lhs.replace(
lambda i: # find symbol**even
i.is_Pow and i.base == symbol and i.exp.is_even,
lambda i: # replace t**even
t**i.exp)
Example:-
Main equation -> -1/x**2 + exp(x/2)/2 = 0
After replacement -> -1/t**2 + exp(x/2)/2 = 0
</code></pre></div></div>
<p>Now I take logarithms on both sides and simplify it.</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>After simplifying -> 2*log(t) + x/2 = 0
</code></pre></div></div>
<p>Now I call function <code class="highlighter-rouge">_solve_even_degree_expr</code> to replace the t with +/-x to generate two equations.</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>Replacing t with +/-x
1. 2*log(x) + x/2 = 0
2. 2*log(-x) + x/2 = 0
</code></pre></div></div>
<p>And consider the solutions of both of the equations to return all lambert real solutions
of <code class="highlighter-rouge">-1/x**2 + exp(x/2)/2 = 0</code>.</p>
<p>Hope you could understand the logic behind this work.</p>
<h3 id="2-calculation-of-roots-should-consider-all-roots-in-case-having-rational-power">2. Calculation of roots should consider all roots in case having rational power.</h3>
<p>This flaw is in the calculation of roots in function <code class="highlighter-rouge">_lambert</code>.
Earlier the function_lambert has the working like :-</p>
<ol>
<li>Find all the values of a, b, c, d, e in the required loagrithmic equation</li>
<li>Then it defines a solution of the form
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>-c/b + (a/d)*l where l = LambertW(d/(a*b)*exp(c*d/a/b)*exp(-f/a), k)
</code></pre></div> </div>
<p>and then it included that solution.
I agree everything seems flawless here. but try to see the step where we are defining l.</p>
</li>
</ol>
<p>Let us suppose a hypothetical algorithm just like algorithm used in <code class="highlighter-rouge">_lambert</code>
in which equation to be solved is</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>x**3 - 1 = 0
</code></pre></div></div>
<p>and in which we define solution of the form</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>x = exp(I*2*pi/n) where n is the power of x in equation
</code></pre></div></div>
<p>so the algorithm will give solution</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>x = exp(I*2*pi/3) # but expected was [1, exp(I*2*pi/3), exp(-I*2*pi/3)]
</code></pre></div></div>
<p>which can be found by finding all solutions of</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>x**n - exp(2*I*pi) = 0
</code></pre></div></div>
<p>by a different correct algorithm. Thats y it was wrong.
The above algorithm would have given correct values for <code class="highlighter-rouge">x - 1 = 0</code>.</p>
<p>And the question in your mind may arise that why only exp() because the
possiblity of having more than one roots is in exp(), because if the algorithm
would have been like <code class="highlighter-rouge">x = a</code>, where a is some real constant then there is not
any possiblity of further roots rather than solution like <code class="highlighter-rouge">x = a**(1/n)</code>.
And its been done in code like this:</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>code
num, den = ((c*d-b*f)/a/b).as_numer_denom()
p, den = den.as_coeff_Mul()
e = exp(num/den)
t = Dummy('t')
args = [d/(a*b)*t for t in roots(t**p - e, t).keys()]
</code></pre></div></div>
<p>Thank you! Thats all it was!!.</p>https://shubhamkjha.github.io/2019/07/15/GSoC-2019-Week-6-and-7Shubham Kumar Jha (ShubhamKJha)Shubham Kumar Jha (ShubhamKJha): GSoC 2019: Week 6 and 7Mon, 15 Jul 2019 00:00:00 GMT
https://shubhamkjha.github.io/2019/07/15/GSoC-2019-Week-6-and-7.html
<p>With this ends the seventh week of the official coding period. During the end of 6th week and the beginning of 7th week, I was mostly travelling, so I was not able to write a blog for the sixth week. Instead, I will try to summarize my work during the last two weeks here.</p>
<p>For the last few weeks, I have been focused on optimizing the code of new assumptions to enhance its performance. Most of my work has been exploratory, as Aaron says 😅. Indeed I have dry-run, backtracked, profiled, and ran the same code with a debugger too many times to understand the slow parts and the improvements I can make here and there. Mostly the code is optimized given the class structure of SymPy. But it is also the class structure that is adding up to the performance issues. Already noted in my last blog, classes like <code class="highlighter-rouge">And</code> and <code class="highlighter-rouge">Or</code> sorts their <em>args</em>, hence take a great amount of time. But other SymPy class constructors also take significant time.</p>
<p>With the success of fifth week’s attempt, I have been desperate to bring down the execution time 😅. Some of the attempts I have made, which are included in <a href="https://github.com/sympy/sympy/pull/17144">#17144</a>, are:</p>
<ul>
<li>I have modified <strong>CNF</strong> class, which essentially is a low-level implementation for the <a href="https://en.wikipedia.org/wiki/Conjunctive_normal_form">cnf</a> of any boolean expression. <strong>CNF</strong> object holds a set of clauses. These clauses are themselves <code class="highlighter-rouge">frozenset</code> of <strong>Literal</strong> objects. <strong>Literal</strong> class is being implemented just to reduce the unnecessary creation of <code class="highlighter-rouge">Not</code> objects (It takes significant execution time and is called many times).</li>
<li>I have also modified the code of <em>sympify()</em>, it appeared to take more time than expected when the argument is a SymPy object already. Consider this, almost one-third execution time.</li>
</ul>
<div class="language-python highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="n">In</span> <span class="p">[</span><span class="mi">2</span><span class="p">]:</span> <span class="n">x</span> <span class="o">=</span> <span class="n">Symbol</span><span class="p">(</span><span class="s">'x'</span><span class="p">)</span>
<span class="n">In</span> <span class="p">[</span><span class="mi">3</span><span class="p">]:</span> <span class="n">timeit</span> <span class="n">sympify</span><span class="p">(</span><span class="n">x</span><span class="p">)</span> <span class="c"># before change</span>
<span class="mi">601</span> <span class="n">ns</span> <span class="err">±</span> <span class="mf">14.6</span> <span class="n">ns</span> <span class="n">per</span> <span class="n">loop</span> <span class="p">(</span><span class="n">mean</span> <span class="err">±</span> <span class="n">std</span><span class="o">.</span> <span class="n">dev</span><span class="o">.</span> <span class="n">of</span> <span class="mi">7</span> <span class="n">runs</span><span class="p">,</span> <span class="mi">1000000</span> <span class="n">loops</span> <span class="n">each</span><span class="p">)</span>
<span class="n">In</span> <span class="p">[</span><span class="mi">3</span><span class="p">]:</span> <span class="n">timeit</span> <span class="n">sympify</span><span class="p">(</span><span class="n">x</span><span class="p">)</span> <span class="c"># after change</span>
<span class="mi">239</span> <span class="n">ns</span> <span class="err">±</span> <span class="mf">11.8</span> <span class="n">ns</span> <span class="n">per</span> <span class="n">loop</span> <span class="p">(</span><span class="n">mean</span> <span class="err">±</span> <span class="n">std</span><span class="o">.</span> <span class="n">dev</span><span class="o">.</span> <span class="n">of</span> <span class="mi">7</span> <span class="n">runs</span><span class="p">,</span> <span class="mi">1000000</span> <span class="n">loops</span> <span class="n">each</span><span class="p">)</span>
</code></pre></div></div>
<ul>
<li>Finally, I rewrote <code class="highlighter-rouge">to_cnf()</code> for <strong>CNF</strong> objects. By using mostly Python’s built-ins and removing any SymPy object construction during its execution. The performance gain is quite subtle 😎.</li>
</ul>
<div class="language-python highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="n">In</span> <span class="p">[</span><span class="mi">1</span><span class="p">]:</span> <span class="kn">from</span> <span class="nn">sympy</span> <span class="kn">import</span> <span class="o">*</span>
<span class="n">In</span> <span class="p">[</span><span class="mi">2</span><span class="p">]:</span> <span class="kn">from</span> <span class="nn">sympy.abc</span> <span class="kn">import</span> <span class="n">a</span><span class="p">,</span><span class="n">b</span><span class="p">,</span><span class="n">c</span><span class="p">,</span><span class="n">x</span><span class="p">,</span><span class="n">y</span><span class="p">,</span><span class="n">z</span>
<span class="n">In</span> <span class="p">[</span><span class="mi">3</span><span class="p">]:</span> <span class="n">k</span> <span class="o">=</span> <span class="p">(</span><span class="n">x</span> <span class="o">&</span> <span class="n">y</span> <span class="o">&</span> <span class="n">z</span><span class="p">)</span> <span class="o">|</span> <span class="p">(</span> <span class="n">a</span> <span class="o">&</span> <span class="n">b</span> <span class="o">&</span> <span class="n">c</span><span class="p">)</span>
<span class="n">In</span> <span class="p">[</span><span class="mi">4</span><span class="p">]:</span> <span class="kn">from</span> <span class="nn">sympy.logic.boolalg</span> <span class="kn">import</span> <span class="n">CNF</span>
<span class="c"># Before</span>
<span class="n">In</span> <span class="p">[</span><span class="mi">5</span><span class="p">]:</span> <span class="n">timeit</span> <span class="n">CNF</span><span class="o">.</span><span class="n">from_prop</span><span class="p">(</span><span class="n">k</span><span class="p">)</span> <span class="c"># It is using to_cnf()</span>
<span class="mf">1.41</span> <span class="n">ms</span> <span class="err">±</span> <span class="mi">18</span> <span class="err">µ</span><span class="n">s</span> <span class="n">per</span> <span class="n">loop</span> <span class="p">(</span><span class="n">mean</span> <span class="err">±</span> <span class="n">std</span><span class="o">.</span> <span class="n">dev</span><span class="o">.</span> <span class="n">of</span> <span class="mi">7</span> <span class="n">runs</span><span class="p">,</span> <span class="mi">1000</span> <span class="n">loops</span> <span class="n">each</span><span class="p">)</span>
<span class="c"># after</span>
<span class="n">In</span> <span class="p">[</span><span class="mi">5</span><span class="p">]:</span> <span class="n">timeit</span> <span class="n">CNF</span><span class="o">.</span><span class="n">from_prop</span><span class="p">(</span><span class="n">k</span><span class="p">)</span> <span class="c"># It is using the new to_CNF()</span>
<span class="mf">31.5</span> <span class="err">µ</span><span class="n">s</span> <span class="err">±</span> <span class="mf">1.48</span> <span class="err">µ</span><span class="n">s</span> <span class="n">per</span> <span class="n">loop</span> <span class="p">(</span><span class="n">mean</span> <span class="err">±</span> <span class="n">std</span><span class="o">.</span> <span class="n">dev</span><span class="o">.</span> <span class="n">of</span> <span class="mi">7</span> <span class="n">runs</span><span class="p">,</span> <span class="mi">10000</span> <span class="n">loops</span> <span class="n">each</span><span class="p">)</span>
</code></pre></div></div>
<p>There is definitely a limit to performance we can get with Python. But implementing most of the things in Python built-ins we can definitely make things much faster.</p>
<p>For the upcoming week, I will try to complete the following:</p>
<ul>
<li>The CNF objects are still not simplified. I have to implement simplification to reduce the number of clauses. These have to be fed into <code class="highlighter-rouge">satisfiable</code> at the end, which can benefit from lesser number of clauses.</li>
<li><code class="highlighter-rouge">rcall</code> used with <strong>sathandlers</strong> is another major portion having high execution time. I will try to work it out.</li>
<li>Clean up the code and make it ready for reviewing.</li>
</ul>
<p>Apart from that, I will also try to shift my focus towards the other part of my project and write some theory solvers. After all, I need to enhance the assumptions not just make it faster 😎.</p>
<p><em>Peace</em></p>https://anpandey.github.io/posts/sympy/2019-07-14-week-7.htmlAnkit Pandey (anpandey)Ankit Pandey (anpandey): Google Summer of Code Week 7: Matrix WildcardsSun, 14 Jul 2019 00:00:00 GMT
https://anpandey.github.io/posts/sympy/2019-07-14-week-7.html
<p>I spent most of this week on extending wildcard support for matrix expressions, along with some more explorations in printing array contractions.</p>
<h3 id="matrices-and-wildcards">Matrices and Wildcards</h3>
<p>As I’ve probably mentioned in the last two blog posts, SymPy’s support for matching matrix expressions through the <code>Wild</code> class is currently severely limited (<a href="https://github.com/sympy/sympy/issues/17172">when it works</a>). While it is possible to construct a non-commutative <code>Wild</code>, it isn’t able to match expressions in a matrix multiplication:</p>
<div class="sourceCode" id="cb1"><pre class="sourceCode python"><code class="sourceCode python"><a class="sourceLine" id="cb1-1" title="1"><span class="op">>>></span> W, X <span class="op">=</span> symbols(<span class="st">'W, X'</span>, cls<span class="op">=</span>Wild, commutative<span class="op">=</span><span class="va">False</span>)</a>
<a class="sourceLine" id="cb1-2" title="2"><span class="op">>>></span> <span class="im">from</span> sympy.abc <span class="im">import</span> N</a>
<a class="sourceLine" id="cb1-3" title="3"><span class="op">>>></span> A, B <span class="op">=</span> MatrixSymbol(<span class="st">'A'</span>, N, N), MatrixSymbol(<span class="st">'B'</span>, N, N)</a>
<a class="sourceLine" id="cb1-4" title="4"><span class="op">>>></span> <span class="bu">type</span>((A <span class="op">*</span> B).match(W <span class="op">*</span> X))</a>
<a class="sourceLine" id="cb1-5" title="5"><span class="op"><</span><span class="kw">class</span> <span class="st">'NoneType'</span><span class="op">></span></a></code></pre></div>
<p>It’s also currently not possible to combine matrices and wildcards in expressions, since wildcards don’t have a defined shape and so may only function as scalars:</p>
<div class="sourceCode" id="cb2"><pre class="sourceCode python"><code class="sourceCode python"><a class="sourceLine" id="cb2-1" title="1"><span class="op">>>></span> W <span class="op">+</span> A</a>
<a class="sourceLine" id="cb2-2" title="2"><span class="pp">TypeError</span>: Mix of Matrix <span class="kw">and</span> Scalar symbols</a>
<a class="sourceLine" id="cb2-3" title="3"><span class="op">>>></span> W <span class="op">*</span> A</a>
<a class="sourceLine" id="cb2-4" title="4"><span class="pp">NotImplementedError</span>: noncommutative scalars <span class="kw">in</span> MatMul are <span class="kw">not</span> supported.</a></code></pre></div>
<h3 id="matrixwild"><code>MatrixWild</code></h3>
<p>I spent most of this week working on <a href="https://github.com/sympy/sympy/pull/17177">#17177</a>, which implements a <code>MatrixWild</code> class that functions as both a wildcard and a matrix expression. In order to construct the wildcard, we need to give it a shape:</p>
<div class="sourceCode" id="cb3"><pre class="sourceCode python"><code class="sourceCode python"><a class="sourceLine" id="cb3-1" title="1"><span class="op">>>></span> <span class="im">from</span> sympy.abc <span class="im">import</span> N</a>
<a class="sourceLine" id="cb3-2" title="2"><span class="op">>>></span> <span class="im">from</span> sympy.matrices.expressions.matexpr <span class="im">import</span> MatrixWild</a>
<a class="sourceLine" id="cb3-3" title="3"><span class="op">>>></span> W, X <span class="op">=</span> MatrixWild(<span class="st">'W'</span>, N, N), MatrixWild(<span class="st">'X'</span>, N, N)</a></code></pre></div>
<p>Unlike in the example above using <code>Wild</code>, compound expressions are able to match against a matrix multiplication:</p>
<div class="sourceCode" id="cb4"><pre class="sourceCode python"><code class="sourceCode python"><a class="sourceLine" id="cb4-1" title="1"><span class="op">>>></span> A, B <span class="op">=</span> MatrixSymbol(<span class="st">'A'</span>, N, N), MatrixSymbol(<span class="st">'B'</span>, N, N)</a>
<a class="sourceLine" id="cb4-2" title="2"><span class="op">>>></span> (A <span class="op">*</span> B).match(W <span class="op">*</span> X)</a>
<a class="sourceLine" id="cb4-3" title="3">{W_: A, X_: B}</a></code></pre></div>
<p>Note that in order for matrix wildcards to match, their shape must match with the target expression:</p>
<div class="sourceCode" id="cb5"><pre class="sourceCode python"><code class="sourceCode python"><a class="sourceLine" id="cb5-1" title="1"><span class="op">>>></span> x <span class="op">=</span> MatrixSymbol(<span class="st">'x'</span>, N, <span class="dv">1</span>)</a>
<a class="sourceLine" id="cb5-2" title="2"><span class="op">>>></span> e <span class="op">=</span> A <span class="op">*</span> x</a>
<a class="sourceLine" id="cb5-3" title="3"><span class="op">>>></span> e.shape</a>
<a class="sourceLine" id="cb5-4" title="4">(N, <span class="dv">1</span>)</a>
<a class="sourceLine" id="cb5-5" title="5"><span class="op">>>></span> <span class="bu">type</span>(e.match(W))</a>
<a class="sourceLine" id="cb5-6" title="6"><span class="op"><</span><span class="kw">class</span> <span class="st">'NoneType'</span><span class="op">></span></a></code></pre></div>
<p>However, if we don’t care about dimension, we can include another wildcard in the matrix wildcard’s shape:</p>
<div class="sourceCode" id="cb6"><pre class="sourceCode python"><code class="sourceCode python"><a class="sourceLine" id="cb6-1" title="1"><span class="op">>>></span> M <span class="op">=</span> MatrixSymbol(<span class="st">'M'</span>, <span class="dv">3</span>, <span class="dv">3</span>)</a>
<a class="sourceLine" id="cb6-2" title="2"><span class="op">>>></span> w <span class="op">=</span> Wild(<span class="st">'w'</span>)</a>
<a class="sourceLine" id="cb6-3" title="3"><span class="op">>>></span> Y <span class="op">=</span> MatrixWild(<span class="st">'Y'</span>, w, w)</a>
<a class="sourceLine" id="cb6-4" title="4"><span class="op">>>></span> M.match(Y)</a>
<a class="sourceLine" id="cb6-5" title="5">{w_: <span class="dv">3</span>, Y_: M}</a></code></pre></div>
<p>While this is a good first step to the matching functionality I was looking for with <code>unify</code> for rewriting matrix expressions, there is still quite a bit of functionality (and tests) to be implemented, along with an unknown number of bugs to fix.</p>
<h2 id="printing-indexed-bases">Printing Indexed Bases</h2>
<p>I’ve also been working on a small pull request to improve the functionality the printing <code>IndexedBases</code> so that it instead uses intermediate values (represented through the new code generation classes) to accumulate the values of contractions. Currently, this does nothing but break existing compatibility (Fortran versions older than Fortran 95 don’t support variable declarations in arbitrary locations, and the variable currently defaults to a 32-bit floating point number), though I think this is a good first step for supporting the printing of more complex contractions.</p>
<h2 id="next-steps">Next Steps</h2>
<p>For this week, I plan to finish with the implementation of<code>MatrixWild</code> (and hopefully get started with using it for rewriting matrix expressions), along with making some more progress on the indexed bases pull request.</p>https://sc0rpi0n101.github.io/2019/07/week-7a-little-step-towards-consistency/Nikhil Maan (Sc0rpi0n101)Nikhil Maan (Sc0rpi0n101): Week 7:A Little Step Towards ConsistencySat, 13 Jul 2019 00:00:00 GMT
https://sc0rpi0n101.github.io/2019/07/week-7a-little-step-towards-consistency/
<p>“It’s not what we do once in a while that shapes our lives. It’s what we do consistently.” ― Anthony Robbins
Welcome everyone, this is your host Nikhil Maan aka Sc0rpi0n101 and this week I’ve tried to be more consistent with my schedule, work and communications with the Organization. I’ve taken a few small steps and plan to improve as I keep working.
Consistency!? Merging the Pull Requests?http://ishanaj.wordpress.com/?p=56Ishan Joshi (ishanaj)Ishan Joshi (ishanaj): GSoC’19: Week-6-Completing the Column class.Mon, 08 Jul 2019 04:44:15 GMT
https://ishanaj.wordpress.com/2019/07/08/gsoc19-week-6-completing-the-column-class/
<p>The sixth week has ended with a lot of work to be done ahead.</p>
<p>Last week the work was majorly focused on the work in progress <a href="https://github.com/sympy/sympy/pull/17122">PR #17122</a>. I have included the critical load function which makes the Column class capable of determining the critical load. Some problems still came up in solving some equations. I have made an <a href="https://github.com/sympy/sympy/issues/17162">issue</a> related to those.</p>
<p>An equation similar to <strong>tan(x) – x</strong> comes up while determining the critical load for the <strong>pinned-fixed</strong> end-condition. SymPy’s <strong>solve() </strong>won’t be able to solve such an equation, and as per the solution given in the <a href="https://github.com/sympy/sympy/issues/17162">issue</a>, I think that <strong>nsolve()</strong> would surely help in this case. So I will be going ahead to solve it using the approximation returned by <strong>nsolve()</strong> to handle this condition.</p>
<p>Another problem that I faced was determining deflection and critical load for the <strong>pinned-pinned</strong> end-condition. Here, the deflection comes out to be:</p>
<p><strong>C1*sin(sqrt(P)*x/(sqrt(E)*sqrt(I)))</strong> +<strong> C2*cos(sqrt(P)*x/(sqrt(E)*sqrt(I)))</strong></p>
<p>Now on solving it for constants <strong>C1</strong> and <strong>C2, </strong>using initial boundary conditions, both come out to be <strong>0</strong>, making the deflection <strong>zero</strong>. This implies that no buckling occurs, which is not the case.</p>
<p>Even when solving it manually, this situation occurs, we deal with it by putting <strong>C2 = 0 </strong>and instead of putting <strong>C1 = 0,</strong> we consider the <strong>sin </strong>term equal to zero and then solve for <strong>P (critical load). </strong>So, I will be adding a few more lines of code to deal with this situation.</p>
<p>Apart from working on this module, I have also opened another <a href="https://github.com/sympy/sympy/pull/17153">PR #17153</a> which implement methods to determine <strong>section modulus</strong> and <strong>polar modulus</strong> of any polygon (more precisely a cross-section). Initially it was a draft PR, but now the work has been completed on it. Once I get the approval, I will also be adding the same for the Ellipses module. Also, if <strong><a href="https://github.com/sympy/sympy/pull/17001">cut_section()</a> </strong>gets successfully implemented I will be adding another method to determine the first moment.</p>
<p>I am pretty sure the work on <strong>Column class</strong> will be successfully completed before the end of the next week. Also, we will be heading towards the next stage which intends to plot beam diagrams using matplotlib. Till then we can have an initial discussion regarding the same.</p>
<h2><strong>Next Week:</strong></h2>
<ul>
<li>Improving the <strong>critical_load()</strong> to handle the above problems</li>
<li>Completing the Column class (documentation and tests)</li>
<li>Starting with the next phase</li>
</ul>
<p>Will keep you updated!</p>
<p>Thanks!</p>https://czgdp1807.github.io/week_6Gagandeep Singh (czgdp1807)Gagandeep Singh (czgdp1807): Week 6 - Some extensionsMon, 08 Jul 2019 00:00:00 GMT
https://czgdp1807.github.io/week_6/
<p>This week was a mix of discussion on design and extending previous work. I also got to know about some new cool features of <code class="highlighter-rouge">SymPy</code>.</p>
<p>According to the plan proposed in <a href="https://czgdp1807.github.io/week_4/">Week 4</a>, I have completed my work on <code class="highlighter-rouge">DiscreteMarkovChain</code> via <a href="https://github.com/sympy/sympy/pull/17083">PR #17083</a>. I used the <code class="highlighter-rouge">as_set</code> and <code class="highlighter-rouge">as_relational</code> methods which helped me to cover many miscellaneous cases and probably, now <code class="highlighter-rouge">DiscreteMarkovChain</code> is quite dynamic and can handle various generic <code class="highlighter-rouge">probability</code> and <code class="highlighter-rouge">expectation</code> queries. I have also started the <a href="https://github.com/sympy/sympy/pull/17163">PR #17163</a> for adding <code class="highlighter-rouge">ContinuousMarkovChain</code> and I am observing that it’s a bit tricky to maintain both the performance and result quality while working on it. Now, moving on to symbolic <code class="highlighter-rouge">Range</code>,well, the work has been started in the <a href="https://github.com/sympy/sympy/pull/17146">PR #17146</a> and I have figured out one disparity between <code class="highlighter-rouge">Range</code> and python’s <code class="highlighter-rouge">range</code>(details available at <a href="https://github.com/sympy/sympy/pull/17146#discussion_r300162219">this thread</a>). I will try to fix it by making minimal changes to the code. The tensorflow related <a href="https://github.com/sympy/sympy/pull/17103">PR #17103</a> which I started in the previous week is also almost complete and is waiting for <code class="highlighter-rouge">Tensorflow 2.0</code> release. I am also studying a bit about the architecture of the above framework to make changes to <code class="highlighter-rouge">lambdify</code>. Regarding random matrices, I believe that discussion has reached its final stages and I am waiting for the comments from Francesco for improvements at the issue <a href="https://github.com/sympy/sympy/issues/17039">#17039</a>.</p>
<p>Let me share with you about my discoveries and learnings in this week. Well, thanks to Francesco for telling me about, <code class="highlighter-rouge">sympy.multipledispatch</code>. It helps in implementing operator overloading like in C/C++. I liked it very much. I also read about continuous Markov chain and discovered about generator matrix, forward and backward equations. Adding one interesting fact, that Poisson process and continuous Markov chain are very closely related via generator matrices it will make the implementation of the former much easier :D.</p>
<p>Leaving you for now, Bye!!</p>https://divyanshu132.github.io//gsoc-week-6Divyanshu Thakur (divyanshu132)Divyanshu Thakur (divyanshu132): GSoC 2019 - Week 6 - Computation of Polycyclic presentationMon, 08 Jul 2019 00:00:00 GMT
https://divyanshu132.github.io//gsoc-week-6
<p>The sixth week of coding period has ended and a good amount of work has been done on polycyclic groups. Polycyclic presentation, Polycyclic generating sequence(pcgs) and it’s series is implemented which for sure need some improvement <a href="https://github.com/sympy/sympy/pull/16991">sympy/sympy#16991</a>.</p>
<p>The polycyclic series is computed starting from the bottom of the derived series of a group by adding the missing generators in the subgroups, and collecting these missing generators provide us the polycyclic generating sequence.</p>
<p>As we discussed last week <a href="https://divyanshu132.github.io/gsoc-week-5">here</a> that to compute conjugate relators of a polycyclic group we were missing the <code class="highlighter-rouge">RHS</code> term, which was of the form <code class="highlighter-rouge">x[i]**-1*x[i+1]*x[i] == RHS</code>. So, starting from the bottom of the polycyclic generating sequence forming the subgroup and finding all the generators of the RHS using <code class="highlighter-rouge">generator_product</code>, mapping these generators with the free group elements and forming a word, finally collect the above formed word which will give us the collected RHS.</p>
<p>Below is an example to compute polycyclic presentation for S(9).sylow_subgroup(3)</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>>>> from sympy.combinatorics import *
>>> from sympy.combinatorics.free_groups import free_group
>>> F, x0, x1, x2, x3 = free_group("x0, x1, x2, x3")
>>> S = SymmetricGroup(9)
>>> G = S.sylow_subgroup(3)
>>> pc_group = G.polycyclic_group()
>>> group = F
>>> pc_group.pc_presentation(group)
{x3**3: (), x2**3: (), x1**3: (), x0**3: (), x2**-1*x3*x2: x3, x1**-1*x3*x1: x3, x1**-1*x2*x1: x2, x0**-1*x3*x0: x2**2*x3**2, x0**-1*x2*x0: x3, x0**-1*x1*x0: x1*x3}
</code></pre></div></div>
<p>One problem that we’ve encountered is that the generators in pcgs may change for the same group on executing it several times which makes it difficult to test pc_presentation but, Kalevi advised me to initalize <code class="highlighter-rouge">random.seed</code> with some chosen value and then it will result in the same repeatable result, will try it by today!</p>
<p>The tasks that I’m hopping to accomplish next week are</p>
<ul>
<li>Add tests for plycyclic presentation and be sure that it works properly.</li>
<li>Include more functionalities to pc groups like <code class="highlighter-rouge">exponent_vector</code>, <code class="highlighter-rouge">element_depth</code>, <code class="highlighter-rouge">leading_coefficient</code>.</li>
<li>Add documentation for all the functions.</li>
</ul>
<p>Till then, good byee..</p>https://arighnaiitg.github.io/2019-07-07-gsoc-week6/Arighna Chakrabarty (arighnaiitg)Arighna Chakrabarty (arighnaiitg): GSoC Week 6 !!Sun, 07 Jul 2019 07:00:00 GMT
https://arighnaiitg.github.io/2019-07-07-gsoc-week6/
<p>Week 6 ends.. -
Phase 2 of the coding period is smoothly being traversed. I recently had a meeting with Sartaj on 4th of July, Thursday. Here were the minutes of the meeting, along with the deliverables completed over the week. The meeting commenced with the discussion that we need to wrap up the...https://anpandey.github.io/posts/sympy/2019-07-07-week-6.htmlAnkit Pandey (anpandey)Ankit Pandey (anpandey): Google Summer of Code Week 6: Unification and Tensors ContinuedSun, 07 Jul 2019 00:00:00 GMT
https://anpandey.github.io/posts/sympy/2019-07-07-week-6.html
<p><em>See the <a href="https://anpandey.github.io/2019-06-28-week-5.html">previous post</a> for Week 5</em>.</p>
<p>This week I’ve made some progress on matching and tensors, though I haven’t filed any pull requests.</p>
<h2 id="unification">Unification</h2>
<p>I have a working implementation of rewriting non-commutative expressions using SymPy’s unify. It works by generating a <code>ReplaceOptim</code> object that applies the rewriting rules to any term it’s called with. Here’s how we specify the rewriting rules:</p>
<div class="sourceCode" id="cb1"><pre class="sourceCode python"><code class="sourceCode python"><a class="sourceLine" id="cb1-1" title="1"><span class="op">>>></span> <span class="im">from</span> sympy <span class="im">import</span> Symbol, MatrixSymbol</a>
<a class="sourceLine" id="cb1-2" title="2"><span class="op">>>></span> n <span class="op">=</span> Symbol(<span class="st">'N_matcher'</span>, integer<span class="op">=</span><span class="va">True</span>)</a>
<a class="sourceLine" id="cb1-3" title="3"><span class="op">>>></span> X <span class="op">=</span> MatrixSymbol(<span class="st">'X_matcher'</span>, n, n)</a>
<a class="sourceLine" id="cb1-4" title="4"><span class="op">>>></span> Y <span class="op">=</span> MatrixSymbol(<span class="st">'Y_matcher'</span>, n, <span class="dv">1</span>)</a>
<a class="sourceLine" id="cb1-5" title="5"><span class="op">>>></span> variables <span class="op">=</span> [n, X, Y]</a>
<a class="sourceLine" id="cb1-6" title="6"><span class="op">>>></span> matcher <span class="op">=</span> X<span class="op">**</span>(<span class="op">-</span><span class="dv">1</span>) <span class="op">*</span> Y</a>
<a class="sourceLine" id="cb1-7" title="7"><span class="op">>>></span> goal <span class="op">=</span> MatrixSolve(X, Y)</a></code></pre></div>
<p>Here, the combination of <code>matcher</code> and <code>variables</code> specifies that we’re looking for any expression of the form <span class="math inline"><em>X</em><sup> − 1</sup><em>Y</em></span>, where both <span class="math inline"><em>X</em></span> and <span class="math inline"><em>Y</em></span> can be any compound matrix expression. The inclusion of <code>n</code> in <code>variables</code> imposes the additional restriction that the matrix expression matched by <span class="math inline"><em>X</em></span> must be square (i.e. <span class="math inline"><em>n</em> × <em>n</em></span>) while the expression matched by <span class="math inline"><em>Y</em></span> must be a vector (i.e. <span class="math inline"><em>n</em> × 1</span>). <code>goal</code> specifies what the matched expression should be replaced with, where <code>X</code> and <code>Y</code> serve as stand-ins for the matched terms.</p>
<p>After specifying our goals, we can construct the object and apply the replacement to some expressions:</p>
<div class="sourceCode" id="cb2"><pre class="sourceCode python"><code class="sourceCode python"><a class="sourceLine" id="cb2-1" title="1"><span class="op">>>></span> replacer <span class="op">=</span> gen_replacement_operator(matcher, goal, variables)</a>
<a class="sourceLine" id="cb2-2" title="2"><span class="op">>>></span> A, B, x <span class="op">=</span> MatrixSymbol(<span class="st">'A'</span>, <span class="dv">3</span>, <span class="dv">3</span>), MatrixSymbol(<span class="st">'B'</span>, <span class="dv">3</span>, <span class="dv">3</span>), MatrixSymbol(<span class="st">'x'</span>, <span class="dv">3</span>, <span class="dv">1</span>)</a>
<a class="sourceLine" id="cb2-3" title="3"><span class="op">>>></span> replacer(A <span class="op">**</span> (<span class="op">-</span><span class="dv">1</span>) <span class="op">*</span> x)</a>
<a class="sourceLine" id="cb2-4" title="4">(MatrixSolve(A, vector<span class="op">=</span>x))</a>
<a class="sourceLine" id="cb2-5" title="5"><span class="op">>>></span> replacer(A <span class="op">**</span> (<span class="op">-</span><span class="dv">1</span>) <span class="op">*</span> B)</a>
<a class="sourceLine" id="cb2-6" title="6">A <span class="op">**</span> (<span class="op">-</span><span class="dv">1</span>) <span class="op">*</span> B</a></code></pre></div>
<p>The first term was replaced since the dimensions of <code>A</code> and <code>x</code> agreed with what was specified in matcher, while the second expression was left untouched since <code>B</code> is not a vector.</p>
<p>While the matcher does work, I haven’t filed a pull request because of some problems which don’t seem like they could be easily addressed:</p>
<ul>
<li>I had to give add the suffix <code>_matcher</code> to the variable names to avoid variable capture, since SymPy symbols are considered equal if they have the same name. <code>unify</code> does not support <code>Dummy</code> symbols as variables.</li>
<li>Some compound expressions are not matched. I’ve narrowed this down to the way the variables are being passed to <code>unify</code>, since they need to be converted to symbols. It seems like this conversion sometimes causes expressions to no longer be unifiable.</li>
<li>Unification doesn’t seem to work for a mixture of commutative and non-commutative expressions. I’m not sure if this is a problem with <code>unify</code> itself or the way that I’m using it, since the only test of <code>unify</code> in the SymPy codebase involving matrix expressions is on matrix multiplication.</li>
</ul>
<p>As I mentioned in my last blog post, SymPy already supports this sort of pattern matching through <code>Wild</code>, though it currently does not support expressions involving matrices. Before trying to address these issues, I think it would be worthwhile to look into extending the functionality of <code>Wild</code> as an alternative.</p>
<h2 id="tensors">Tensors</h2>
<p>I’ve made some progress in low-level code generation of matrix expressions. I tried seeing if instances of classes in the <code>array_utils</code> module could be converted to SymPy’s AST representation before being passed off to the code generators. This doesn’t seem possible at the moment, since the AST has a number of limitations (such as not supporting variables in <code>for</code> loop ranges). The <code>IndexedBase</code> printer already has some of the functionality that I’m trying to implement, so I’ve settled on extending the printer to support arbitrary contractions. This same functionality can probably be reused for the <code>array_utils</code> printers. The implementation will hopefully be straightforward.</p>
<h2 id="next-steps">Next steps</h2>
<p>My goal for this week is to have a pull request for the tensor code generation ready, along with a plan for what to do with matching.</p>https://jmig5776.github.io//gsoc-week-6Jogi Miglani (jmig5776)Jogi Miglani (jmig5776): GSoC 2019 - Week 6Sun, 07 Jul 2019 00:00:00 GMT
https://jmig5776.github.io//gsoc-week-6
<p>This was the sixth week meeting with the GSoC mentors which was scheduled on
Sunday 7th July, 2019 between 1:45 - 2:45 PM (IST). Me, Yathartha and Amit
were the attendees of the meeting. This meeting was short.</p>
<ul>
<li>Discussing previous week’s progress</li>
</ul>
<p>In this meeting both the mentors were convinced by the code for Lambert’s.
And few modifications in documentation and code clean up were suggested by them.
In this week the whole idea of power_list was droppped because @smichr suggested
code for replacing the symbol more targetted as we wanted by which the whole code
was improved. And it was decided to work upon on <code class="highlighter-rouge">_solve_modular</code> mainly now
onwards.</p>
<ul>
<li>
<p>Next week goals</p>
</li>
<li>
<p>Getting merge existing PR for Lambert</p>
</li>
<li>
<p>Work upon <code class="highlighter-rouge">_solve_modular</code> PR</p>
</li>
<li>
<p>If time left then find plan for Imageset Union.</p>
</li>
</ul>
<p>Code improvement takes time!!</p>https://sc0rpi0n101.github.io/2019/07/week-6-the-most-chaotic-week-ever/Nikhil Maan (Sc0rpi0n101)Nikhil Maan (Sc0rpi0n101): Week 6: The Most Chaotic Week Ever!!Sat, 06 Jul 2019 00:00:00 GMT
https://sc0rpi0n101.github.io/2019/07/week-6-the-most-chaotic-week-ever/
<p>“A language that doesn’t affect the way you think about programming is not worth knowing.” ― Alan J. Perlis
Welcome everyone, this is your host Nikhil Maan aka Sc0rpi0n101 and this week was one of the most chaotic weeks till now if not the most chaotic. I had to move places as the Uni opens next week, had the summer classes exams and had to convert the C parser to use SymPy’s Codegen AST from Python AST all in one week.https://shubhamkjha.github.io/2019/07/03/GSoC-2019-Week-5Shubham Kumar Jha (ShubhamKJha)Shubham Kumar Jha (ShubhamKJha): GSoC 2019: Week 5Wed, 03 Jul 2019 00:00:00 GMT
https://shubhamkjha.github.io/2019/07/03/GSoC-2019-Week-5.html
<p>With this the fifth week and the first phase of the official coding period has ended. I will try to give a brief summary of my work during this week.</p>
<p>I spent most of this week learning the inner working of <strong>satask</strong> module. It took a lot of debugging to understand the on-going processes efficiently 😅 . My major job was to reduce the unwanted slowing portions in the code. I had <a href="https://github.com/sympy/sympy/pull/11789">#11789</a> for reference. Some of such performance reducing portions of code were:</p>
<ul>
<li>A major segment of code was creating <strong>And</strong> objects unnecessarily. As suggested in <a href="https://github.com/sympy/sympy/issues/17087">#17087</a> the sorting in the <strong>And</strong> constructor takes up a significant amount of time. These have to be reduced.</li>
<li>Using SymPy objects is itself a bottleneck for performance. Having a system built over SymPy objects slows things down. Python’s built-in types should be used as much as possible.</li>
<li>A specific segment (used many times in the code) calls <code class="highlighter-rouge">rcall</code> over propositions. The <code class="highlighter-rouge">rcall</code> which is a recursive process also takes a significant of time.</li>
<li>Also, I have tried to pre-compile results as much as possible.</li>
</ul>
<p>With the above and some other changes, the overall performance of <code class="highlighter-rouge">satask</code> has improved much. I have made a PR over this <a href="https://github.com/sympy/sympy/pull/17144">#17144</a>. For an instance,</p>
<table style="padding: 15px;">
<thead>
<th>Tests</th>
<th>After this PR</th>
<th>In master</th>
</thead>
<tbody>
<tr>
<td>test_satask</td>
<td>2.39 s</td>
<td>36.26 s</td>
</tr>
<tr>
<td>assumptions/tests</td>
<td>16.74 s</td>
<td>127.21 s</td>
</tr>
</tbody>
</table>
<p><br />
There is still scope for improvement in performance. In the coming week, I will try to work these out. I will also try to improve the performance of <strong>ask</strong> module.</p>
<p>Also, the first evaluations are over now and I feel happy to announce that I passed it. During the first phase I learnt a lot. In last few weeks I got to explore profiling and got to understand how small segments can influence performance. Before this I felt that I already know the codebase, but in reality I had much to explore. My mentors always gave me a good starting point and a direction over the course of this phase. With the hope to work much better in the coming phases, I take your leave now 😄 .</p>https://czgdp1807.github.io/week_5Gagandeep Singh (czgdp1807)Gagandeep Singh (czgdp1807): Week 5 - Transition towards Phase 2Tue, 02 Jul 2019 00:00:00 GMT
https://czgdp1807.github.io/week_5/
<p>The evaluation results for phase 1 are out, and I am very glad to share with you that I have passed with flying colors. I received, “Well done so far.” as the feedback for my work till now.</p>
<p>So now let us move to the work done in the gap between phase 1 and phase 2. Firstly, both of my open PRs of the previous phase, i.e., <a href="https://github.com/sympy/sympy/pull/16962">#16962</a> and <a href="https://github.com/sympy/sympy/pull/16934">#16934</a> have been merged. Though for symbolic dimensions some more work has to be done to make <code class="highlighter-rouge">sympy.stats.frv</code> more efficient and maintainable. I have also started my work, PR <a href="https://github.com/sympy/sympy/pull/17083">#17083</a>, to extend the scope of queries for <code class="highlighter-rouge">DiscreteMarkovChain</code> and the system has become a bit smarter. In fact, during this week, while working on the PR, <a href="https://github.com/sympy/sympy/pull/17103">#17103</a>, I came across the news that Tensorflow has changed a lot of APIs while migrating from 1.x to 2.x. AFAIK, they are moving towards <code class="highlighter-rouge">Function</code> approach from the previous <code class="highlighter-rouge">Session</code> approach, and due to that, SymPy’s <code class="highlighter-rouge">lambdify</code> faced some issues which I will be fixing soon with the help of other members. The Tensorflow details can be seen <a href="https://github.com/tensorflow/community/blob/b1d83bf2ee3fc72650140b89656e29932db36226/rfcs/20180918-functions-not-sessions-20.md">here</a>.</p>
<p>Now, let’s move to the learning part. During the transition period I learnt about the dependencies of <code class="highlighter-rouge">SymPy</code>. Moreover, I came across, how, some bugs can be unnoticed when left untested. Thanks again to <a href="https://github.com/oscarbenjamin">oscarbenjamin</a> for letting me know about the bugs related to variance of finite random variables. I also got to know that, how bare <code class="highlighter-rouge">except</code> can even catch keyboard interrupt and that’s what makes it quite vulnerable. Thanks to <a href="https://github.com/sidhantnagpal">sidhantnagpal</a> for helping me with this.</p>
<p>So, that’s all for this, see you next week. Bye!!</p>https://divyanshu132.github.io//gsoc-week-5Divyanshu Thakur (divyanshu132)Divyanshu Thakur (divyanshu132): GSoC 2019 - Week 5 - Hand-made tests for CollectorMon, 01 Jul 2019 00:00:00 GMT
https://divyanshu132.github.io//gsoc-week-5
<p>This week was mostly about testing the collection of a word and fixing small bugs in the implementation pointed out by Kalevi. The major challenge was to construct the polycyclic presentation of a group to test the Collector since we don’t have the implementation of polycyclic presentation and it’s generating sequence yet. So, we decided to form some hand made tests and we started with SymmetricGroup(4) and further we also tried with S(3) the details can be found in the test file of the PR(<a href="https://github.com/sympy/sympy/pull/16991">here</a>).</p>
<p>Now, the next step is to implement polycyclic presentation and polycyclic sequence. In the presentation we’ll need generators which we can easily get and the relators. There are two types of relators needed for the presentation:</p>
<ul>
<li>Power relations (ex. <code class="highlighter-rouge">x^re = x'</code>)</li>
<li>Conjugate relations (ex. <code class="highlighter-rouge">x[i]**-1*x[i+1]*x[i] = RHS and x[i]*x[i+1]*x[i]**-1 = RHS</code>)</li>
</ul>
<p>For every pair of generators we’ll form above conjugate relations but the tough part is computing that <code class="highlighter-rouge">RHS</code> which should be collected and for now we don’t have that much idea about how to get that RHS.</p>
<p>But, let’s hope that in upcoming days we’ll be able to figure it out, till then Good byeee…</p>http://ishanaj.wordpress.com/?p=54Ishan Joshi (ishanaj)Ishan Joshi (ishanaj): GSoC’19: Week-5 – Moving on with a Non-mutable Column classSun, 30 Jun 2019 18:52:29 GMT
https://ishanaj.wordpress.com/2019/07/01/gsoc19-week-5-moving-on-with-a-non-mutable-column-class/
<p>A lot of things happened this week and I am happy to inform you that <a href="https://github.com/sympy/sympy/pull/17055">PR #17055</a> has been successfully merged. The beam module now supports the cross-sectional shape of the beam as an alternative parameter to the second moment. With this, the aim of the stage-I to integrate the geometry module with beam module has been accomplished.</p>
<p>Although we need to add some examples in the docs, to make it easier for the user to understand how to use this new feature.</p>
<p>Coming on to stage-II, I had already, initiated a <a href="https://github.com/sympy/sympy/issues/17072">discussion</a> to finalize the API of the new Column class that is to be implemented as a part of the continuum mechanics module in this stage.</p>
<p>We concluded that it would be much better if the Column class remains non-mutable i.e. unlike the beam class where a beam is formed in a piecewise form, the new Column class would take all its required input data during the declaration and then one can call different methods to calculate different things.</p>
<p>I have made a <a href="https://github.com/sympy/sympy/pull/17122">work-in-progress PR #17122</a> implementing the Column class which performs the required buckling calculations. Currently, I have not included a method to calculate the critical load as there was a bit of problem with the form of the equation which the <strong>dsolve() </strong>returns after solving the differential equation of buckling. <a href="https://docs.sympy.org/latest/modules/solvers/ode.html" rel="noopener" target="_blank"><strong>dsolve(</strong>)</a> is SymPy’s differential equation solver.</p>
<p>In general, if we solve the general equation of buckling manually, we might apply the <strong>method of undetermined coefficients</strong>, which of course even <strong>dsolve() </strong> is capable to apply, but it gives the answer in an exponent form, while we need it in a trigonometric form (for ease of further calculations). So after seeking different methods trying to convert this equation in terms of <strong>sin(x)</strong> and <strong>cos(x), </strong>I finally had to put that problem in the discussion, where Oscar Benjamin, gave an idea to declare the variables as positive in order to get it in terms of <strong>sin </strong>and<strong> cos. </strong>I tried that it works well for our case. I will have to figure out the further calculation of the critical load.</p>
<p>Hopefully will be updating the code with a new method to calculate critical load, soon.</p>
<p>Also, I have planned to have a method to solve the <strong>unknown reactions</strong> and <strong>reaction moments</strong>, which would use the <strong>boundary conditions</strong> to get their values.</p>
<p>With all these things going on, this week we also had our first evaluations, and I am very happy to say that I have passed it. <strong>Thanks to the mentors!</strong></p>
<h2><strong> </strong><strong>Next Week:</strong></h2>
<ul>
<li>Completing Column class with all its methods</li>
<li>Adding tests and documentation.</li>
<li>Starting discussions for the next stage.</li>
</ul>
<p>I will try to finish working on the Column class this weekend.</p>
<p>Will keep you updated!</p>
<p>Thanks!</p>
<p> </p>https://arighnaiitg.github.io/2019-06-30-gsoc-week5/Arighna Chakrabarty (arighnaiitg)Arighna Chakrabarty (arighnaiitg): GSoC Week 5 !!Sun, 30 Jun 2019 07:00:00 GMT
https://arighnaiitg.github.io/2019-06-30-gsoc-week5/
<p>Week 5 ends.. -
Phase 2 of the coding period has started. This week has gone in wrapping up the left-over work of FormalPowerSeries. I had a meeting with Sartaj on Tuesday 25th of June, about the work left to be done on FormalPowerSeries module. We agreed that some minor changes need to be...https://www.kangzhiq.com/?p=24Zhiqi KANG (kangzhiq)Zhiqi KANG (kangzhiq): [GSoC 2019] WEEK 4 and 5!Sat, 29 Jun 2019 02:40:07 GMT
https://www.kangzhiq.com/2019/06/29/gsoc-2019-week-4-and-5/
<p>Hello, the first phase is ended and I am happy to pass the first evaluation. I was struggling with my academic projects and final exams during the last two weeks. After talking about my difficulty of spending time contributing on my project with my mentors, Francesco allowed me to have a one-week break in condition that I should make up one week in the next phases. The goal is to have 40 hours work per week on average by the end of this program.</p>
<p>Thanks to the comprehension of my mentor, I could successfully pass the exams. I am going to work more over the second phase in order to have more contributions to the community. <img alt="🙂" class="wp-smiley" src="https://s.w.org/images/core/emoji/12.0.0-1/72x72/1f642.png" style="height: 1em;" /></p>https://jmig5776.github.io//gsoc-week-5Jogi Miglani (jmig5776)Jogi Miglani (jmig5776): GSoC 2019 - Week 5Sat, 29 Jun 2019 00:00:00 GMT
https://jmig5776.github.io//gsoc-week-5
<p>This was the fifth week meeting with the GSoC mentors which was scheduled on
Saturday 29th June, 2019 between 11:30 - 12:30 PM (IST). Me, Yathartha and Amit
were the attendees of the meeting. I passed my first evaluation, Amit gave his
feedback and told me some very important points to take notes on. I do personally
believe that his suggestions are the best a mentor could gave to his student after
practicing his suggestions in my real life.</p>
<ul>
<li>Discussing previous week’s progress</li>
</ul>
<p>In this meeting both mentors suggested me to work upon the code improvements and
documentation improvement. And make it more readable to user. ALthough somehow
@smichr had some doubts on the logic that we were implementing. Although a lot
of progress has been there. So I decided to create and discussion for thinking
new logic for implementing Lambert all solutions and work on the current PR as
goes on.</p>
<ul>
<li>
<p>Next week goals</p>
</li>
<li>
<p>Improving existing PR for Lambert</p>
</li>
<li>
<p>Improving <code class="highlighter-rouge">_solve_modular</code> PR also</p>
</li>
<li>
<p>If time left then find plan for Imageset Union.</p>
</li>
</ul>
<p>Code improvement takes time!!</p>https://sc0rpi0n101.github.io/2019/06/week-5-the-evaluation-is-here-end-of-phase-1/Nikhil Maan (Sc0rpi0n101)Nikhil Maan (Sc0rpi0n101): Week 5: The Evaluation is here: End of Phase 1Sat, 29 Jun 2019 00:00:00 GMT
https://sc0rpi0n101.github.io/2019/06/week-5-the-evaluation-is-here-end-of-phase-1/
<p>“On two occasions I have been asked [by members of Parliament!]: ‘Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out ?’ I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.” — Charles Babbage
Welcome everyone, this is your host Nikhil Maan aka Sc0rpi0n101 and this week was the last week of Phase-1 and the evaluations for the first phase.https://anpandey.github.io/posts/sympy/2019-06-28-week-5.htmlAnkit Pandey (anpandey)Ankit Pandey (anpandey): Google Summer of Code Week 5: Unification and TensorsFri, 28 Jun 2019 00:00:00 GMT
https://anpandey.github.io/posts/sympy/2019-06-28-week-5.html
<p><em>See the <a href="https://anpandey.github.io/2019-06-21-weeks-3-and-4.html">previous post</a> for Weeks 3 and 4</em>.</p>
<p>This week I’ve been mostly doing background reading. This post is mostly a summary of what I learned.</p>
<h2 id="unification">Unification</h2>
<p>In short, unification is the process of finding substitutions of variables within two terms two terms to make them identical. For example, if we have the expressions <span class="math inline"><em>x</em> + 2<em>y</em></span> and <span class="math inline"><em>a</em> + 3<em>b</em></span>, the substitution <span class="math inline">{<em>x</em> ↦ <em>a</em>, <em>y</em> ↦ 3, <em>b</em> ↦ 2}</span> is a unifier, since applying the substitution to both expressions makes gives us the identical expression of <span class="math inline"><em>a</em> + 3 ⋅ 2</span>. While this particular substitution includes variables from both expressions, we’re mostly interested in rules involving substitutions of variables from just one expression (a case of unification known as matching). Several well-known algorithms for unification already exist.</p>
<h3 id="unification-in-sympy">Unification in SymPy</h3>
<p>SymPy also has an implementation of a unification algorithm that is able to take the commutativity of operations into account. Suppose we wanted to unify the matrix expressions <span class="math inline"><em>A</em><sup><em>T</em></sup><em>B</em><sup>2</sup><em>C</em><sup> − 1</sup></span> and <span class="math inline"><em>X</em><em>Y</em><sup> − 1</sup></span>. This is essentially the problem of finding a substitution that makes these two expressions equal. Using the <code>sympy.unify.usympy</code> module, we can discover what this substitution is:</p>
<div class="sourceCode" id="cb1"><pre class="sourceCode python"><code class="sourceCode python"><a class="sourceLine" id="cb1-1" title="1"><span class="op">>>></span> <span class="im">from</span> sympy.unify.usympy <span class="im">import</span> <span class="op">*</span></a>
<a class="sourceLine" id="cb1-2" title="2"><span class="op">>>></span> <span class="im">from</span> sympy.abc <span class="im">import</span> N</a>
<a class="sourceLine" id="cb1-3" title="3"><span class="op">>>></span> m <span class="op">=</span> <span class="kw">lambda</span> x: MatrixSymbol(x, N, N)</a>
<a class="sourceLine" id="cb1-4" title="4"><span class="op">>>></span> A, B, C, X, Y <span class="op">=</span> <span class="bu">map</span>(m, [<span class="st">'A'</span>, <span class="st">'B'</span>, <span class="st">'X'</span>, <span class="st">'Y'</span>])</a>
<a class="sourceLine" id="cb1-5" title="5"><span class="op">>>></span> e1 <span class="op">=</span> A.T <span class="op">*</span> B<span class="op">**</span><span class="dv">2</span> <span class="op">*</span> C.I</a>
<a class="sourceLine" id="cb1-6" title="6"><span class="op">>>></span> e2 <span class="op">=</span> X <span class="op">*</span> Y <span class="op">**</span>(<span class="op">-</span><span class="dv">1</span>)</a>
<a class="sourceLine" id="cb1-7" title="7"><span class="op">>>></span> <span class="bu">next</span>(unify(e1, e2, variables<span class="op">=</span>[X, Y]))</a>
<a class="sourceLine" id="cb1-8" title="8">{X: A.T<span class="op">*</span>B<span class="op">**</span><span class="dv">2</span>, Y: C}</a></code></pre></div>
<p>We’ve reduced this to a matching problem in which the variables are specified only in <code>e2</code>. What’s important to note here is that the matching rule within <code>e2</code> we specified (<span class="math inline"><em>X</em><em>Y</em><sup> − 1</sup></span>) was a compound expression. This is something that is currently not possible for non-commutative expressions (such as matrix multiplication) using SymPy’s <code>Wild</code> interface. <code>unify</code> allows use to express substitution rules that are able to match across sub-expressions in matrix multiplication.</p>
<p>Through unification, we can express substitution rules for optimization as a simple term-rewriting rule. In my previous blog post, I mentioned rewriting the matrix multiplication <span class="math inline"><em>A</em><em>x</em></span> as a solving operation of <code>MatSolve(A, x)</code> under certain assumptions. The actual implementation is restricted to cases where both the <code>A</code> and the <code>x</code> are matrix symbols, and the optimization can’t identify cases where either the <code>A</code> or the <code>x</code> is a compound expression. With unification, we can identify the same pattern in more complex subexpressions. If we’re given the matrix expression <span class="math inline"><em>A</em><sup><em>T</em></sup>(<em>A</em><em>B</em>)<sup> − 1</sup><em>x</em><em>y</em></span>, a unification based transformer can produce <code>MatSolve(AB, x)</code>, provided that the shapes of the matrices match the given rule.</p>
<h2 id="codegen-tensors">Codegen Tensors</h2>
<p>I also looked into generating C and Fortran code from SymPy matrix expressions. For the purposes of code generation, SymPy has a relatively new <code>array_utils</code> module. The AST nodes in this module express generalizations of operations on matrices, which require a bit of background in tensors.</p>
<p>Many array operations (including matrix multiplication) involve <em>contraction</em> along an axis. Contractions are a combination of multiplication and summation along certain axis of a tensor<a class="footnote-ref" href="https://anpandey.github.io/atom-sympy.xml#fn1" id="fnref1"><sup>1</sup></a>. In assigning the matrix multiplication <span class="math inline"><em>A</em><em>B</em></span> to the <span class="math inline"><em>n</em> × <em>n</em></span> matrix <span class="math inline"><em>C</em></span>, we can explicitly write the summations (using subscripts for indexing matrix elements) as</p>
<p><br /><span class="math display">$$C_{ik} = \sum_{j = 1}^{n} A_{ij} B_{jk}$$</span><br /></p>
<p>The index <span class="math inline"><em>j</em></span> is contracted, as it is shared between both <span class="math inline"><em>A</em></span> and <span class="math inline"><em>B</em></span>, and describing this summation operation as a whole boils down to which indices are shared between the matrices. This is essentially what the <code>array_utils</code> classes do. This is what happens when we use <code>array_utils</code> to convert the matrix multiplication to an equivalent contraction operation:</p>
<div class="sourceCode" id="cb2"><pre class="sourceCode python"><code class="sourceCode python"><a class="sourceLine" id="cb2-1" title="1"><span class="op">>>></span> <span class="im">from</span> sympy.codegen.array_utils <span class="im">import</span> CodegenArrayContraction</a>
<a class="sourceLine" id="cb2-2" title="2"><span class="op">>>></span> <span class="im">from</span> sympy.abc <span class="im">import</span> N</a>
<a class="sourceLine" id="cb2-3" title="3"><span class="op">>>></span> A <span class="op">=</span> MatrixSymbol(<span class="st">'A'</span>, N, N)</a>
<a class="sourceLine" id="cb2-4" title="4"><span class="op">>>></span> B <span class="op">=</span> MatrixSymbol(<span class="st">'B'</span>, N, N)</a>
<a class="sourceLine" id="cb2-5" title="5"><span class="op">>>></span> CodegenArrayContraction.from_MatMul(A <span class="op">*</span> B)</a>
<a class="sourceLine" id="cb2-6" title="6">CodegenArrayContraction(CodegenArrayTensorProduct(A, B), (<span class="dv">1</span>, <span class="dv">2</span>))</a></code></pre></div>
<p>We’re given a new<code>CodegenArrayContraction</code> object that stores, along with the variables <code>A</code> and <code>B</code>, tuples of integers representing contractions along certain indices. Here, the <code>(1, 2)</code> means that the variable at index 1 and index 2 (indices start at 0) are shared. We can confirm this by looking at the above summation, since both the second and third indices out of all indices that appear in the expression are <span class="math inline"><em>j</em></span>.</p>
<h2 id="next-steps">Next Steps</h2>
<p>For next week, I’ll try to re-implement the rewriting optimization in terms of <code>unify</code>. This will both make it easier to express rules and extend to sub-expressions as well. I’ll also start with implementing additional printers for the C and Fortran printers. The printer will probably just print naive <code>for</code> loops to keep things simple (and it would probaly be better to use something like Theano for highly optimized code).</p>
<section class="footnotes">
<hr />
<ol>
<li id="fn1"><p>For our purposes, we can think of tensors as just <span class="math inline"><em>n</em></span>-dimensional arrays. Most of my reading on tensors was Justin C. Feng’s <a href="https://justincfeng.github.io/Tensors_Poor_Man.pdf">The Poor Man’s Introduction to Tensors</a>.<a class="footnote-back" href="https://anpandey.github.io/atom-sympy.xml#fnref1">↩</a></p></li>
</ol>
</section>https://divyanshu132.github.io//gsoc-week-4Divyanshu Thakur (divyanshu132)Divyanshu Thakur (divyanshu132): GSoC 2019 - Week 4 - Phase-I CompletionMon, 24 Jun 2019 00:00:00 GMT
https://divyanshu132.github.io//gsoc-week-4
<p>The fourth week of coding period has ended and now it’s time for phase-I evaluations. Below, is a brief progress report of the project.</p>
<p>The tasks that were proposed in the proposal for phase-I consists of:</p>
<ul>
<li>Implementation of Abelian Invariants</li>
<li>Implementation of Composition Series</li>
<li>Computation with Polycyclic groups</li>
</ul>
<p><strong>Abelian Invariants</strong></p>
<p>Implemented a function to compute the abelian invariants for a given permutation or free group. These are given as a list of prime-powers and describe the stucture of <code class="highlighter-rouge">G/G'</code> as a direct product of cyclic groups of prime power order.</p>
<ul>
<li>PR link <a href="https://github.com/sympy/sympy/pull/16670">Added method to calculate Abelian Invariants</a></li>
</ul>
<p><strong>Composition Series</strong></p>
<p>Implemented a function to compute the composition series. It provides a way to break up a group into simple pieces. Composition series of a group <code class="highlighter-rouge">G</code> is defined as the maximal subnormal series <code class="highlighter-rouge">G = H_0 > H_1 > H_2 ... > H_k = 1</code> where every factor group <code class="highlighter-rouge">H(i+1)/H(i)</code> is simple.</p>
<ul>
<li>PR link <a href="https://github.com/sympy/sympy/pull/16881">Added method for Composition Series computation</a></li>
</ul>
<p><strong>Polycyclic Groups</strong></p>
<p>The work on polycyclic group is in progress. For now, collection algorithm has been implemented which needs to be tested and a lot of discussions were made on the polycyclic generating sequence and its presentation and may be in a week we’ll be ready with the stucture of polycyclic groups and collection of words.</p>
<ul>
<li>PR link <a href="https://github.com/sympy/sympy/pull/16991">Added Polycyclic Group Class</a></li>
</ul>
<p><strong>Documentation</strong></p>
<p>Some documentation is done to increase the sphinx coverage of SymPy.</p>
<ul>
<li>PR link <a href="https://github.com/sympy/sympy/pull/16809">Increase Accessibility of docstrings from Sphinx</a></li>
</ul>
<p>To follow the discussion on above topics and the further progress of the project one can check Gitter room <a href="https://gitter.im/sympy/GroupTheory">sympy/GroupTheory</a></p>https://shubhamkjha.github.io/2019/06/24/GSoC-2019-Week-4Shubham Kumar Jha (ShubhamKJha)Shubham Kumar Jha (ShubhamKJha): GSoC 2019: Week 4Mon, 24 Jun 2019 00:00:00 GMT
https://shubhamkjha.github.io/2019/06/24/GSoC-2019-Week-4.html
<p>With this the fourth week and the first phase of GSoC 2019 is over. Here I will give you a brief summary of my progress this week.</p>
<p>I started this week by setting up my workspace for profiling the code related to new assumptions. I am using <code class="highlighter-rouge">pyinstrument</code> for that. The results of profiler suggests that a significant amount of time is spent in the <code class="highlighter-rouge">to_cnf()</code> function which converts the logical expression into their CNF counterparts, to be used by the SAT solver. Also, since this system is built over the SymPy core, a large amount of this time is spent in the core itself (See the graph <a href="https://github.com/sympy/sympy/issues/17066#issuecomment-504774120">here</a>). A possible solution to this is to use constructs at a level lower than the SymPy objects, hence removing the overheads.</p>
<p>Also, as suggested in the last blog, there are various ideas proposed for improving the new assumptions mechanism. Some of them have been implemented to some extent in some PRs. Before proceeding for any new strategies, I need to look into these ideas first. I have started an <a href="https://github.com/sympy/sympy/issues/17066">issue-tree</a> to gather them.</p>
<p>Over the end of the week, I also pushed my work on <code class="highlighter-rouge">First Order Logic</code> module at <a href="https://github.com/sympy/sympy/pull/17069">#17069</a>. This work is based on <a href="https://github.com/sympy/sympy/pull/7608">#7608</a> and extends it by adding <code class="highlighter-rouge">Equality</code> to it. Currently, there are test failures and some points to decide. I will try to get it done within this week.</p>
<p>I spent most of this week exploring the profiling and benchmarking of code, and I learnt a lot during this. For the coming week, I will focus on speeding up the code in <code class="highlighter-rouge">to_cnf</code>. As suggested by Aaron, <a href="https://github.com/sympy/sympy/pull/11789">this</a> seems a good point to start with. Also, I will be working on the <code class="highlighter-rouge">FOL</code> module.</p>