Srajan Garg2016-08-16T09:08:13+00:00http://srajangarg.github.io/Srajan Gargsrajan.garg@gmail.comContainers for Multivariate Polynomials2016-08-16T00:00:00+00:00http://srajangarg.github.io//2016/08/16/Containers-for-MPoly<h3 id="overview">Overview</h3>
<p>After the last blog post, I started working on the “fixing up the remainder of rational polynomials”. This also included adding support for basic to rational polynomial conversions. The current work is in <a href="https://github.com/symengine/symengine/pull/1055">#1055</a> which has not been merged in yet.</p>
<p>Another thing I started working on was conversions from SymEngine symbolics to multivariate polynomials. The way the current conversions work, led me to change the overall structure of multivariate polynomials.</p>
<h3 id="restructuring-multivariate-polynomials">Restructuring Multivariate Polynomials</h3>
<p>The current working of basic conversions is that it constructs the “internal container” of the polynomial as it parses the expression. These containers have operators overloaded and they can easily be manipulated by the functions. Handling multivariate polynomials using this approach would be impossible with the current structure of the code. There were no “containers” per se in the previous implementation.</p>
<p>I thought it would be better if we can implement a container based polynomial structure for multivariate polynomials too. Fortunately, the way the SymEngine polynomials work, an approach similar to the univariate case of containers worked. The container is a wrapper around a map from vector to a value (the coefficient)</p>
<div class="language-c++ highlighter-rouge"><pre class="highlight"><code><span class="k">template</span> <span class="o"><</span><span class="k">typename</span> <span class="n">Vec</span><span class="p">,</span> <span class="k">typename</span> <span class="n">Value</span><span class="p">,</span> <span class="k">typename</span> <span class="n">Wrapper</span><span class="o">></span>
<span class="k">class</span> <span class="nc">UDictWrapper</span>
<span class="p">{</span>
<span class="k">public</span><span class="o">:</span>
<span class="k">using</span> <span class="n">Dict</span> <span class="o">=</span> <span class="n">std</span><span class="o">::</span><span class="n">unordered_map</span><span class="o"><</span><span class="n">Vec</span><span class="p">,</span> <span class="n">Value</span><span class="p">,</span> <span class="n">vec_hash</span><span class="o"><</span><span class="n">Vec</span><span class="o">>></span><span class="p">;</span>
<span class="n">Dict</span> <span class="n">dict_</span><span class="p">;</span>
<span class="kt">unsigned</span> <span class="kt">int</span> <span class="n">vec_size</span><span class="p">;</span>
<span class="p">...</span>
</code></pre>
</div>
<p>The polynomial class uses this as a container, along with information about the generators and their ordering. Apart from holding the map, this class has various constructors, and all the operators overloaded for it. It also has helper functions, which help translate the current keys to another specific order/ arrangement. The container assumes that the all operations done to it are with other “adjusted” containers. Currently, the job of adjusting/aligning th container has been delegated to functions like <code class="highlighter-rouge">add_mpoly</code> etc.</p>
<div class="language-c++ highlighter-rouge"><pre class="highlight"><code><span class="k">template</span> <span class="o"><</span><span class="k">typename</span> <span class="n">Poly</span><span class="o">></span>
<span class="n">RCP</span><span class="o"><</span><span class="k">const</span> <span class="n">Poly</span><span class="o">></span> <span class="n">add_mpoly</span><span class="p">(</span><span class="k">const</span> <span class="n">Poly</span> <span class="o">&</span><span class="n">a</span><span class="p">,</span> <span class="k">const</span> <span class="n">Poly</span> <span class="o">&</span><span class="n">b</span><span class="p">)</span>
<span class="p">{</span>
<span class="k">typename</span> <span class="n">Poly</span><span class="o">::</span><span class="n">container_type</span> <span class="n">x</span><span class="p">,</span> <span class="n">y</span><span class="p">;</span>
<span class="n">set_basic</span> <span class="n">s</span> <span class="o">=</span> <span class="n">get_translated_container</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">a</span><span class="p">,</span> <span class="n">b</span><span class="p">);</span>
<span class="n">x</span> <span class="o">+=</span> <span class="n">y</span><span class="p">;</span>
<span class="k">return</span> <span class="n">Poly</span><span class="o">::</span><span class="n">from_container</span><span class="p">(</span><span class="n">s</span><span class="p">,</span> <span class="n">std</span><span class="o">::</span><span class="n">move</span><span class="p">(</span><span class="n">x</span><span class="p">));</span>
<span class="p">}</span>
</code></pre>
</div>
<p>and</p>
<div class="language-c++ highlighter-rouge"><pre class="highlight"><code><span class="k">template</span> <span class="o"><</span><span class="k">typename</span> <span class="n">Poly</span><span class="p">,</span> <span class="k">typename</span> <span class="n">Container</span><span class="o">></span>
<span class="n">set_basic</span> <span class="n">get_translated_container</span><span class="p">(</span><span class="n">Container</span> <span class="o">&</span><span class="n">x</span><span class="p">,</span> <span class="n">Container</span> <span class="o">&</span><span class="n">y</span><span class="p">,</span>
<span class="k">const</span> <span class="n">Poly</span> <span class="o">&</span><span class="n">a</span><span class="p">,</span> <span class="k">const</span> <span class="n">Poly</span> <span class="o">&</span><span class="n">b</span><span class="p">)</span>
<span class="p">{</span>
<span class="n">vec_uint</span> <span class="n">v1</span><span class="p">,</span> <span class="n">v2</span><span class="p">;</span>
<span class="n">set_basic</span> <span class="n">s</span><span class="p">;</span>
<span class="kt">unsigned</span> <span class="kt">int</span> <span class="n">sz</span> <span class="o">=</span> <span class="n">reconcile</span><span class="p">(</span><span class="n">v1</span><span class="p">,</span> <span class="n">v2</span><span class="p">,</span> <span class="n">s</span><span class="p">,</span> <span class="n">a</span><span class="p">.</span><span class="n">vars_</span><span class="p">,</span> <span class="n">b</span><span class="p">.</span><span class="n">vars_</span><span class="p">);</span>
<span class="n">x</span> <span class="o">=</span> <span class="n">a</span><span class="p">.</span><span class="n">poly_</span><span class="p">.</span><span class="n">translate</span><span class="p">(</span><span class="n">v1</span><span class="p">,</span> <span class="n">sz</span><span class="p">);</span>
<span class="n">y</span> <span class="o">=</span> <span class="n">b</span><span class="p">.</span><span class="n">poly_</span><span class="p">.</span><span class="n">translate</span><span class="p">(</span><span class="n">v2</span><span class="p">,</span> <span class="n">sz</span><span class="p">);</span>
<span class="k">return</span> <span class="n">s</span><span class="p">;</span>
<span class="p">}</span>
</code></pre>
</div>
<p>Basically, both the containers get the ordering of generators in the “new” polynomial which will soon be constructed, and adjust the ordering of the vectors inside their maps accordingly. Thus consistency is maintained. All the work done is in <a href="https://github.com/symengine/symengine/pull/1049">#1049</a> and this has been merged in.</p>
<h3 id="remaining-work">Remaining work</h3>
<ul>
<li>
<p>After getting this restructure done, I started work on the basic to multivariate conversions, though I have not been able to cover it completely. The idea for these conversions remains the same and should be easy to implement.</p>
</li>
<li>
<p>I also could not spend time to integrate wrappers to Piranha polynomials which can be used as multivariate polynomials within SymEngine</p>
</li>
</ul>
<h3 id="wrapping-up-gsoc">Wrapping up GSoC</h3>
<p>This is officially the last week of Google Summer of Code ‘16. Although GSoC is over, I plan to get the above mentioned work finished within August, before any other big undertaking. It has been a wonderful journey of insight and knowledge. Thanks a lot to my mentors Isuru, Ondrej and Sumith for helping me throughout the summers, and always being there for discussions and the silly issues I bombarded them with!</p>
<p>Bye!</p>
Multivariate Polynomials2016-08-01T00:00:00+00:00http://srajangarg.github.io//2016/08/01/Multivariate-Polynomails<h3 id="overview">Overview</h3>
<p>After college has started, work has been slower than usual. Last week I finally wound up Rational Polynomials in <a href="https://github.com/symengine/symengine/pull/1028">#1028</a>. Some minor changes still remain in some parts of the code. Most of the changes left are mainly related to code duplication, and will be fixed by writing their templated versions.</p>
<h3 id="multivariate-polynomials">Multivariate Polynomials</h3>
<p>I started off by reading and understanding how the multivariate class is implemented currently in SymEngine. It was developed by the UC Davis team as a part of their course project. The basic idea is pretty simple. It still is a sparse representation and maps from a vector (representing the powers of each generator in the monomial) to the non-zero coefficient multiplied to it. We use an unordered map instead of the ordered map used in the univariate counterpart. The choice does make some sense, as deciding order between two monomials is subjective and does not make sense (for eg. which is larger <code class="highlighter-rouge">x**2*y</code> or <code class="highlighter-rouge">x*y**2</code>) Even if we define a custom ordering, there are no real benefits I could think of that it would provide.</p>
<p>On a side note, it kind of makes me think why we have stuck to the ordered map implementation for our univariate polynomials. The places it offers benefits are <code class="highlighter-rouge">eval</code> and <code class="highlighter-rouge">mul</code> (in some ways) I worked with ordered maps, as that was the implementation the initial polynomial class was built on. I’m also wondering if it is healthy to use two different implementations for both the polynomial types, univariate and multivariate. This needs to be discussed.</p>
<p>Right now, I’m basically refactoring most of the code written in the multivariate class, so that it matches the API more or less from the univariate case. Some functions have been re-written and some unnecessary storage within the polynomials have been removed. Initially, I thought I will stick with the same container based approach I used in the univariate case. This proves to be non trivial for the multivariate case. So, after some discussion with Isuru, we decided to stick with different implementations for SymEngine polynomials and Piranha polynomials, as combining code was not easy. The current work is in <a href="https://github.com/symengine/symengine/pull/1049">#1049</a></p>
<h3 id="future-work">Future Work</h3>
<p>A lot is on my plate right now. Some of the work I plan to finish by the end of the next two weeks are</p>
<ul>
<li>
<p>Finish up the refactoring of multivariate polynomials, and make their interaction with univariate polynomials as seamless as possible</p>
</li>
<li>
<p>Introduce wrappers for piranha polynomials to be used as multivariate polynomials within SymEngine</p>
</li>
<li>
<p>Fix up the remainder of rational polynomials, and template code wherever possible to remove code duplicates</p>
</li>
<li>
<p>Write conversions from <code class="highlighter-rouge">Basic</code> to multivariate polynomials, which will finish up one part of the coercion framework as proposed by Isuru</p>
</li>
</ul>
<p>Off to work!</p>
Rational Polynomials ft. Bugs2016-07-23T00:00:00+00:00http://srajangarg.github.io//2016/07/23/Rational-Polynomials-ft-Bugs<h3 id="overview">Overview</h3>
<p>Sorry I haven’t been able to report my work for about two weeks now. Things have become slower mainly due to the fact that my university has resumed and along with it a heavily packed timetable and assignments in the first week don’t help. I also caught a bad fever the past week which really hindered my progress, but it’s dying down and I will resume my work with full vigor eventually.</p>
<p>The work I did do has been summarized below.</p>
<h3 id="bug-fixes">Bug Fixes</h3>
<p>While writing the code for the rational polynomials, as mentioned in the last blogpost, I encountered various bugs. Some of them caused other bugs to be exposed, which took a lot of time for me to debug.</p>
<ul>
<li>
<p><code class="highlighter-rouge">pow(Poly, uint)</code> was throwing a segmentation fault. After digging in and wasting more than four hours on unrelated checks I figured out that the <code class="highlighter-rouge">eq</code> inside the polynomial class was incorrect. Without checking whether the other parameter was a <code class="highlighter-rouge">Poly</code> or not, I was <code class="highlighter-rouge">static_cast</code>ing it which posed a problem.</p>
</li>
<li>
<p>The happiness was shortlived, as the bug persisted. On further inspection I found that the polynomial was being treated as a number! This was because <code class="highlighter-rouge">is_a_Number</code> relied on typecodes, and the polynomial types were defined before the <code class="highlighter-rouge">NUMBERWRAPPER</code> class, which deemed them numbers. The fix for this was simple, just move the polynomial type code definitions after the numbers.</p>
</li>
<li>
<p>The <code class="highlighter-rouge">pow</code> tests pass, but what’s this? All the <code class="highlighter-rouge">MSVC</code> builds on appveyor fail. They all fail a <code class="highlighter-rouge">coeff</code> test. Wow, I had not changed any code related to <code class="highlighter-rouge">coeff</code> at all, how does it affect that specific test and only on the <code class="highlighter-rouge">MSVC</code> compiler? This kept me wondering and looking at the source for a day. Finally, I had to login to the VM of appveyor running the tests. I was not familiar with windows development environment at all, which was the reason I failed a couple of times before I gave up debugging. The next morning I woke up determined to fix this Windows bug, I set the break points in Visual Studio and started the code execution. I found it! It was a bug in the <code class="highlighter-rouge">CoeffVisitor</code> itself. The code for the <code class="highlighter-rouge">coeff</code> function was incomplete. Why wasn’t this bug being captured before? Probably because the previous change (in the typecodes) caused a reordering in a map, which no other compiler was doing. Do read up <a href="https://github.com/symengine/symengine/pull/1033#issuecomment-232973025">here</a> for more details.</p>
</li>
<li>
<p>An appveyor build was failing for unknown reason, which had to be shifted to allowed failures</p>
</li>
</ul>
<p>This was basically the components of <a href="https://github.com/symengine/symengine/pull/1033">#1033</a>. Less quantity of changes, but really important none the less.</p>
<h3 id="rational-polynomials">Rational Polynomials</h3>
<p>The work with rational polynomials continues. I had underestimated the amount of work required, and I also feel that I should have broken down rational polynomials into three parts each, just like integer polynomials. Right now, the work continues in <a href="https://github.com/symengine/symengine/pull/1028">#1028</a>, but it’s soon going to become huge with all varieties of changes.</p>
<h3 id="miscellaneous">Miscellaneous</h3>
<p>I finally benchmarked <a href="https://github.com/sakra/cotire">cotire</a> to see how much speedup it was providing to SymEngine builds. <a href="https://github.com/symengine/symengine/issues/1023">Here</a> is the short summary of the speedups obtained, and the work to include it is in <a href="https://github.com/symengine/symengine/pull/1041">#1041</a>.</p>
<p>Also a small bug was present in our flint and gmp rational number wrappers. We were not canonicalizing on construction from two integers. It was fixed in <a href="https://github.com/symengine/symengine/pull/1031">#1031</a>.</p>
<p>Laters!</p>
Rational Polynomials2016-07-09T00:00:00+00:00http://srajangarg.github.io//2016/07/09/Rational-Polynomials<h3 id="overview">Overview</h3>
<p>This last week was divided into two parts. The first half was spent in fixing miscellaneous issue with the last PR, regarding the basic to polynomial converisons. The second half was spent in thinking of how SymEngine should store rational polynomials (polynomials with rational coefficients) and how infact should they be implemented.</p>
<h3 id="leftovers-from-basic-conversions">Leftovers from Basic Conversions</h3>
<p>As mentioned, the first half of my week was spent finalizing the basic to polynomial conversions PR.</p>
<ul>
<li>
<p>Using <code class="highlighter-rouge">divnum</code> and <code class="highlighter-rouge">mulnum</code> methods instead of using <code class="highlighter-rouge">rcp_cast<Number></code> on <code class="highlighter-rouge">mul</code> and <code class="highlighter-rouge">div</code> respectively. These made the code much more readable too.</p>
</li>
<li>
<p>Use <code class="highlighter-rouge">static_cast<const Rational &>(*rat_rcp).get_den()</code> instead of <code class="highlighter-rouge">rcp_static_cast<const Rational>(rat_rcp)->get_den()</code>. The logic behind this is, that in the second case, another <code class="highlighter-rouge">RCP</code> is being constructed, and the <code class="highlighter-rouge">get_den</code> function is called on this new RCP. This is unecessary and can be avoided using the former approach.</p>
</li>
<li>
<p>At many places within the visitor pattern, I was calling the external function <code class="highlighter-rouge">basic_to_poly</code>. This was not wrong, but caused necessary overhead and recursion, which is not usually desired. Isuru suggested that I can reuse the visitor and successfully avoid the recursion. Here’s an example</p>
</li>
</ul>
<div class="language-c++ highlighter-rouge"><pre class="highlight"><code><span class="n">dict_type</span> <span class="nf">_basic_to_poly</span><span class="p">(</span><span class="n">basic</span><span class="p">,</span> <span class="n">gen</span><span class="p">)</span>
<span class="p">{</span>
<span class="n">BasicToPolyV</span> <span class="n">v</span><span class="p">;</span>
<span class="n">v</span><span class="p">.</span><span class="n">apply</span><span class="p">(</span><span class="n">basic</span><span class="p">,</span> <span class="n">gen</span><span class="p">);</span>
<span class="p">}</span>
<span class="c1">// dict is the answer we will be returning
</span><span class="kt">void</span> <span class="n">BasicToPolyV</span><span class="o">::</span><span class="n">bvisit</span><span class="p">(</span><span class="k">const</span> <span class="n">Add</span> <span class="o">&</span><span class="n">x</span><span class="p">)</span>
<span class="p">{</span>
<span class="k">for</span> <span class="p">(</span><span class="k">auto</span> <span class="k">const</span> <span class="o">&</span><span class="n">it</span> <span class="o">:</span> <span class="n">x</span><span class="p">.</span><span class="n">dict_</span><span class="p">)</span>
<span class="c1">// unnecessary overhead
</span> <span class="n">dict</span> <span class="o">+=</span> <span class="n">_basic_to_upoly</span><span class="p">(</span><span class="n">it</span><span class="p">,</span> <span class="n">gen</span><span class="p">);</span>
<span class="p">}</span>
</code></pre>
</div>
<p>becomes this</p>
<div class="language-c++ highlighter-rouge"><pre class="highlight"><code><span class="c1">// dict is the answer we will be returning
</span><span class="kt">void</span> <span class="n">BasicToPolyV</span><span class="o">::</span><span class="n">bvisit</span><span class="p">(</span><span class="k">const</span> <span class="n">Add</span> <span class="o">&</span><span class="n">x</span><span class="p">)</span>
<span class="p">{</span>
<span class="n">dict_type</span> <span class="n">res</span><span class="p">;</span>
<span class="k">for</span> <span class="p">(</span><span class="k">auto</span> <span class="k">const</span> <span class="o">&</span><span class="n">it</span> <span class="o">:</span> <span class="n">x</span><span class="p">.</span><span class="n">dict_</span><span class="p">)</span>
<span class="c1">// no overhead
</span> <span class="n">res</span> <span class="o">+=</span> <span class="n">BasicToPolyV</span><span class="o">::</span><span class="n">apply</span><span class="p">(</span><span class="n">it</span><span class="p">,</span> <span class="n">gen</span><span class="p">);</span>
<span class="n">dict</span> <span class="o">=</span> <span class="n">std</span><span class="o">::</span><span class="n">move</span><span class="p">(</span><span class="n">res</span><span class="p">);</span>
<span class="p">}</span>
</code></pre>
</div>
<ul>
<li>There was also a <a href="https://github.com/symengine/symengine/pull/1003#discussion_r69408888">discussion</a> on how the visitor for <code class="highlighter-rouge">Pow</code> in <code class="highlighter-rouge">find_gen_pow</code> was implemented. Isuru pointed out, how it would give wrong answers in the cases he put forward. But I had thought of other cases (like <code class="highlighter-rouge">2**(2**(x+1))</code>) which would would then not work, if the code was changed. These were special type of cases where the expression could be ‘simplified’. There’s some discussion on the issue <a href="https://github.com/symengine/symengine/issues/1021">here</a>.</li>
</ul>
<h3 id="starting-rational-polynomials">Starting Rational Polynomials</h3>
<p>I began thinking of how the polynomials with rational coefficients class should be implemented. In Flint, the <code class="highlighter-rouge">fmpq_poly</code> class is implemented as a <code class="highlighter-rouge">fmpz_poly</code> class with another just another integer acting as the common denominatior. This kind of implementation saves up on a lot of time! (think of canonicalization of coefficients, after multiplication) But this kind of implementation would require a lot of extra code be written, and we could not reuse any of the code we have already written. So, after discussion with Isuru, he suggested that I can go ahead with the trivial implementation of using a map from <code class="highlighter-rouge">uint</code> to <code class="highlighter-rouge">rational_class</code>.</p>
<div class="language-c++ highlighter-rouge"><pre class="highlight"><code><span class="k">class</span> <span class="nc">URatDict</span> <span class="o">:</span> <span class="n">ODictWrapper</span><span class="o"><</span><span class="n">uint</span><span class="p">,</span> <span class="n">rational_class</span><span class="o">></span>
</code></pre>
</div>
<p>Add in some constructors and that’s it! The internal container for rational polynomials in SymEngine is ready, because of the way we had strcutured the earlier code.</p>
<p>Now the question was how the end classes should be implemented (i.e. <code class="highlighter-rouge">URatPoly</code>) If you think about it, the methods of both the rational and integer polynomials will look exactly the same. <code class="highlighter-rouge">from_vec</code>, <code class="highlighter-rouge">container_from_dict</code>, <code class="highlighter-rouge">eval</code>, <code class="highlighter-rouge">compare</code> will all look the same with minor differences. The minor differences are only what type of container is being used (<code class="highlighter-rouge">URatDict</code> or <code class="highlighter-rouge">UIntDict</code>?) and what coefficient class is being used (<code class="highlighter-rouge">integer_class</code> or <code class="highlighter-rouge">rational_class</code>?) Infact, I checked this for our other polynomial types Flint and Piranha and it holds true over there too!</p>
<p>So, what came to mind was that all the methods had to be reused! Thus I formed a <code class="highlighter-rouge">USymEnginePoly</code> class which acts as the ‘SymEngine’ implementation of polynomials. You can pass it a <code class="highlighter-rouge">BaseType</code> from which it will deduce what type of polynomial would be constructed. Ideally, all you need to do now for implenting end polynomial classes is choose a implementation type (SymEngine or Piranha or Flint?) and a polynomial type (Integer or Rational?)</p>
<p>Here’s some pseudo code for the class structure aimed at</p>
<div class="language-c++ highlighter-rouge"><pre class="highlight"><code><span class="c1">// the base
</span><span class="k">template</span> <span class="o"><</span><span class="k">typename</span> <span class="n">Container</span><span class="o">></span>
<span class="k">class</span> <span class="nc">UPolyBase</span> <span class="o">:</span> <span class="n">Basic</span>
<span class="c1">// super class for all non-expr polys, all methods which are
// common for all non-expr polys go here eg. degree, eval etc.
</span><span class="k">template</span> <span class="o"><</span><span class="k">typename</span> <span class="n">Cont</span><span class="p">,</span> <span class="k">typename</span> <span class="n">C</span><span class="o">></span>
<span class="k">class</span> <span class="nc">UNonExprPoly</span> <span class="o">:</span> <span class="n">UPolyBase</span><span class="o"><</span><span class="n">Cont</span><span class="o">></span>
<span class="c1">// the specialized non-expr classes
</span><span class="k">template</span> <span class="o"><</span><span class="k">typename</span> <span class="n">D</span><span class="o">></span>
<span class="k">class</span> <span class="nc">UIntPolyBase</span> <span class="o">:</span> <span class="n">UNonExprPoly</span><span class="o"><</span><span class="n">D</span><span class="p">,</span> <span class="n">integer_class</span><span class="o">></span>
<span class="c1">// and
</span><span class="k">template</span> <span class="o"><</span><span class="k">typename</span> <span class="n">D</span><span class="o">></span>
<span class="k">class</span> <span class="nc">URatPolyBase</span> <span class="o">:</span> <span class="n">UNonExprPoly</span><span class="o"><</span><span class="n">D</span><span class="p">,</span> <span class="n">rational_class</span><span class="o">></span>
<span class="c1">// a specific implementation
// similar classes like UPiranhaPoly/UFlintPoly
</span><span class="k">template</span> <span class="o"><</span><span class="k">template</span> <span class="o"><</span><span class="k">typename</span> <span class="n">X</span><span class="o">></span> <span class="k">class</span> <span class="nc">BaseType</span><span class="p">,</span> <span class="k">typename</span> <span class="n">D</span><span class="o">></span>
<span class="k">class</span> <span class="nc">USymEnginePoly</span> <span class="o">:</span> <span class="n">BaseType</span><span class="o"><</span><span class="n">D</span><span class="o">></span>
<span class="c1">// end classes (few examples)
</span><span class="k">class</span> <span class="nc">UIntPoly</span> <span class="o">:</span> <span class="n">USymEnginePoly</span><span class="o"><</span><span class="n">UIntDict</span><span class="p">,</span> <span class="n">UIntPolyBase</span><span class="o">></span>
<span class="k">class</span> <span class="nc">URatPoly</span> <span class="o">:</span> <span class="n">USymEnginePoly</span><span class="o"><</span><span class="n">URatDict</span><span class="p">,</span> <span class="n">URatPolyBase</span><span class="o">></span>
<span class="k">class</span> <span class="nc">UIntPolyPir</span> <span class="o">:</span> <span class="n">UPiranhaPoly</span><span class="o"><</span><span class="n">piranha</span><span class="o">::</span><span class="n">poly</span><span class="p">,</span> <span class="n">UIntPolyBase</span><span class="o">></span>
<span class="k">class</span> <span class="nc">URatPolyFlint</span> <span class="o">:</span> <span class="n">UFlintPoly</span><span class="o"><</span><span class="n">flint</span><span class="o">::</span><span class="n">poly</span><span class="p">,</span> <span class="n">URatPolyBase</span><span class="o">></span>
</code></pre>
</div>
<p>Here’s a bonus picture!</p>
<p><img src="http://srajangarg.github.io/assets/class.jpg" alt="" /></p>
<p>I hope to get all the rational polynomials ready and tested in the next two to three days. The existing work can be seen in <a href="https://github.com/symengine/symengine/pull/1028">#1028</a></p>
<p>Tata!</p>
Finding Generators & Polynomial Conversions2016-07-03T00:00:00+00:00http://srajangarg.github.io//2016/07/03/Generators-Poly-Conversions<h3 id="overview">Overview</h3>
<p>This week I continued my work from last week, but in a cleaner and structured fashion. The PR with last week’s work was closed in favour of a new PR, with better and scalable code. I’ll briefly explain how the functionality is implemented and the main ideas behind it. All the work is in <a href="https://github.com/symengine/symengine/pull/1003">#1003</a>.</p>
<h3 id="finding-generators">Finding Generators</h3>
<p>You can refer to last week’s post to know what a generator for a polynomial is at a preliminary level. An expression may have any number of generators, but our job is to get the least number of generators which will be able to construct the given expression. The only rule is that a generator cannot be a <code class="highlighter-rouge">Number</code> (ie <code class="highlighter-rouge">Rational</code> or <code class="highlighter-rouge">Integer</code>). So <code class="highlighter-rouge">sqrt(3)</code> and <code class="highlighter-rouge">pi</code> can be generators but <code class="highlighter-rouge">2</code> or <code class="highlighter-rouge">1/2</code> can’t.</p>
<p>Initially, the approach I was trying out was not general (as I catered to only the Univariate Int case), and expanding it to other polynomials would prove to be immensely difficult. Isuru suggested that the function should return all the possible generators. This will be the most general case for this function, and we can adapt to specific cases based on how many / which generators the function returns. I will try and summarize how the function works at a high level.</p>
<p>If the expression passed to <code class="highlighter-rouge">find_gen</code> is a</p>
<ul>
<li>
<p><code class="highlighter-rouge">Add</code> and <code class="highlighter-rouge">Mul</code> : We can just call <code class="highlighter-rouge">find_gen</code> recursively on each of the expressions being added/multiplied. <code class="highlighter-rouge">x + y</code> or <code class="highlighter-rouge">x*y</code> will return both <code class="highlighter-rouge">x</code> and <code class="highlighter-rouge">y</code> as the generators. This follows from the fact that polynomials can be multiplied or added up to give the resultant polynomial.</p>
</li>
<li>
<p><code class="highlighter-rouge">Number</code> : Do nothing, as numbers can never act as generators of polynomials.</p>
</li>
<li>
<p><code class="highlighter-rouge">Pow</code> : Few cases arise in if the expression is a <code class="highlighter-rouge">Pow</code>. If the exponent is a positive integer, it suffices to find the generators of only the base of the expression. If it is a negative integer, we update the current generator set with <code class="highlighter-rouge">base**(-1)</code>. For eg.</p>
</li>
</ul>
<div class="language-c++ highlighter-rouge"><pre class="highlight"><code><span class="n">find_gen</span><span class="p">((</span><span class="n">x</span> <span class="o">+</span> <span class="n">y</span><span class="p">)</span><span class="o">**</span><span class="mi">4</span><span class="p">)</span> <span class="o">=</span> <span class="n">find_gen</span><span class="p">(</span><span class="n">x</span> <span class="o">+</span> <span class="n">y</span><span class="p">)</span> <span class="o">=</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">find_gen</span><span class="p">((</span><span class="n">x</span><span class="o">**-</span><span class="mi">2</span><span class="p">))</span> <span class="o">=</span> <span class="p">(</span><span class="n">x</span><span class="o">**-</span><span class="mi">1</span><span class="p">)</span>
</code></pre>
</div>
<p>If the exponent is not an integer, the situation becomes a little complicated. It would seem intuitive that the generators in this case would be the base powered to the generators of the exponent. Like so,</p>
<div class="language-c++ highlighter-rouge"><pre class="highlight"><code><span class="n">find_gen</span><span class="p">(</span><span class="n">base</span><span class="o">**</span><span class="n">exp</span><span class="p">)</span> <span class="o">=</span> <span class="n">base</span><span class="o">**</span><span class="n">find_gen</span><span class="p">(</span><span class="n">exp</span><span class="p">)</span>
<span class="n">eg</span><span class="p">.</span>
<span class="n">find_gen</span><span class="p">(</span><span class="mi">2</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="p">))</span> <span class="o">=</span> <span class="mi">2</span><span class="o">**</span><span class="n">find_gen</span><span class="p">(</span><span class="n">x</span><span class="o">+</span><span class="n">y</span><span class="p">)</span> <span class="o">=</span> <span class="p">(</span><span class="mi">2</span><span class="o">**</span><span class="n">x</span><span class="p">,</span> <span class="mi">2</span><span class="o">**</span><span class="n">y</span><span class="p">)</span>
</code></pre>
</div>
<p>This would seem to be working, but actually the same <code class="highlighter-rouge">find_gen</code> function cannot be used to get the generators of the exponent expression. The <code class="highlighter-rouge">find_gen</code> works in a different way once we are “inside” an exponent. Take for example :</p>
<div class="language-c++ highlighter-rouge"><pre class="highlight"><code><span class="c1">// Incorrect
</span><span class="n">find_gen</span><span class="p">(</span><span class="mi">2</span><span class="o">**</span><span class="p">(</span><span class="n">x</span> <span class="o">+</span> <span class="p">(</span><span class="mi">1</span><span class="o">/</span><span class="mi">2</span><span class="p">)))</span>
<span class="o">=</span> <span class="mi">2</span><span class="o">**</span><span class="n">find_gen</span><span class="p">(</span><span class="n">x</span> <span class="o">+</span> <span class="p">(</span><span class="mi">1</span><span class="o">/</span><span class="mi">2</span><span class="p">))</span>
<span class="o">=</span> <span class="mi">2</span><span class="o">**</span><span class="n">x</span>
<span class="c1">// Correct
</span><span class="n">find_gen</span><span class="p">(</span><span class="mi">2</span><span class="o">**</span><span class="p">(</span><span class="n">x</span> <span class="o">+</span> <span class="p">(</span><span class="mi">1</span><span class="o">/</span><span class="mi">2</span><span class="p">)))</span>
<span class="o">=</span> <span class="mi">2</span><span class="o">**</span><span class="n">find_gen_pow</span><span class="p">(</span><span class="n">x</span> <span class="o">+</span> <span class="p">(</span><span class="mi">1</span><span class="o">/</span><span class="mi">2</span><span class="p">))</span>
<span class="o">=</span> <span class="p">(</span><span class="mi">2</span><span class="o">**</span><span class="n">x</span><span class="p">,</span> <span class="mi">2</span><span class="o">**</span><span class="p">(</span><span class="mi">1</span><span class="o">/</span><span class="mi">2</span><span class="p">))</span>
</code></pre>
</div>
<p><code class="highlighter-rouge">find_gen_pow</code> is another function which returns generators keeping in mind that the current expression it is dealing with is actually the exponent of another expression. So, it’s behaviour varies from the simple <code class="highlighter-rouge">find_gen</code>. Here is another example :</p>
<div class="language-c++ highlighter-rouge"><pre class="highlight"><code><span class="c1">// Incorrect
</span><span class="n">find_gen</span><span class="p">(</span><span class="mi">2</span><span class="o">**</span><span class="p">(</span><span class="n">x</span><span class="o">**</span><span class="mi">2</span> <span class="o">+</span> <span class="mi">3</span><span class="o">*</span><span class="n">x</span> <span class="o">+</span> <span class="p">(</span><span class="mi">1</span><span class="o">/</span><span class="mi">2</span><span class="p">))</span>
<span class="o">=</span> <span class="mi">2</span><span class="o">**</span><span class="n">find_gen</span><span class="p">(</span><span class="n">x</span><span class="o">**</span><span class="mi">2</span> <span class="o">+</span> <span class="mi">3</span><span class="o">*</span><span class="n">x</span> <span class="o">+</span> <span class="p">(</span><span class="mi">1</span><span class="o">/</span><span class="mi">2</span><span class="p">))</span>
<span class="o">=</span> <span class="mi">2</span><span class="o">**</span><span class="n">x</span>
<span class="c1">// Correct
</span><span class="n">find_gen</span><span class="p">(</span><span class="mi">2</span><span class="o">**</span><span class="p">(</span><span class="n">x</span><span class="o">**</span><span class="mi">2</span> <span class="o">+</span> <span class="mi">3</span><span class="o">*</span><span class="n">x</span> <span class="o">+</span> <span class="p">(</span><span class="mi">1</span><span class="o">/</span><span class="mi">2</span><span class="p">))</span>
<span class="o">=</span> <span class="mi">2</span><span class="o">**</span><span class="n">find_gen_pow</span><span class="p">((</span><span class="n">x</span><span class="o">**</span><span class="mi">2</span> <span class="o">+</span> <span class="mi">3</span><span class="o">*</span><span class="n">x</span> <span class="o">+</span> <span class="p">(</span><span class="mi">1</span><span class="o">/</span><span class="mi">2</span><span class="p">))</span>
<span class="o">=</span> <span class="p">(</span><span class="mi">2</span><span class="o">**</span><span class="n">x</span><span class="p">,</span> <span class="mi">2</span><span class="o">**</span><span class="p">(</span><span class="n">x</span><span class="o">**</span><span class="mi">2</span><span class="p">),</span> <span class="mi">2</span><span class="o">**</span><span class="p">(</span><span class="mi">1</span><span class="o">/</span><span class="mi">2</span><span class="p">))</span>
</code></pre>
</div>
<ul>
<li><code class="highlighter-rouge">Basic</code> : For all other structures like <code class="highlighter-rouge">Symbol</code> and <code class="highlighter-rouge">Function</code>, they themselves act as generators of the polynomial. We just need to update the generator set.</li>
</ul>
<p>It is to be kept in mind that whenever we obtain a new potential generator, we update the current generator set. This may lead to modification of an already existing generator or add in a new one. This method thus takes care of some cases, not done by SymPy. A similar updation rule is followed for <code class="highlighter-rouge">find_gen_pow</code> where this is done on the coefficients of each expression instead of their powers.</p>
<p><code class="highlighter-rouge">find_gen</code> :</p>
<div class="language-c++ highlighter-rouge"><pre class="highlight"><code><span class="n">gen_set</span> <span class="o">=</span> <span class="p">(</span><span class="n">x</span><span class="o">**</span><span class="p">(</span><span class="mi">1</span><span class="o">/</span><span class="mi">2</span><span class="p">))</span>
<span class="c1">// addition
</span><span class="n">update_gen_set</span><span class="p">(</span><span class="n">z</span><span class="p">)</span>
<span class="n">gen_set</span> <span class="o">=</span> <span class="p">(</span><span class="n">x</span><span class="o">**</span><span class="p">(</span><span class="mi">1</span><span class="o">/</span><span class="mi">2</span><span class="p">),</span> <span class="n">z</span><span class="p">)</span>
<span class="c1">// modification
</span><span class="n">update_gen_set</span><span class="p">(</span><span class="n">x</span><span class="o">**</span><span class="p">(</span><span class="mi">1</span><span class="o">/</span><span class="mi">3</span><span class="p">))</span>
<span class="n">gen_set</span> <span class="o">=</span> <span class="p">(</span><span class="n">x</span><span class="o">**</span><span class="p">(</span><span class="mi">1</span><span class="o">/</span><span class="mi">6</span><span class="p">))</span>
<span class="c1">// no change
</span><span class="n">update_gen_set</span><span class="p">(</span><span class="n">x</span><span class="p">)</span>
<span class="n">gen_set</span> <span class="o">=</span> <span class="p">(</span><span class="n">x</span><span class="o">**</span><span class="p">(</span><span class="mi">1</span><span class="o">/</span><span class="mi">2</span><span class="p">))</span>
</code></pre>
</div>
<p><code class="highlighter-rouge">find_gen_pow</code> :</p>
<div class="language-c++ highlighter-rouge"><pre class="highlight"><code><span class="c1">// "find_gen_pow"
</span><span class="n">gen_set</span> <span class="o">=</span> <span class="p">(</span><span class="n">x</span><span class="o">/</span><span class="mi">2</span><span class="p">)</span>
<span class="c1">// addition
</span><span class="n">update_gen_set</span><span class="p">(</span><span class="n">x</span><span class="o">**</span><span class="p">(</span><span class="mi">1</span><span class="o">/</span><span class="mi">2</span><span class="p">))</span>
<span class="n">gen_set</span> <span class="o">=</span> <span class="p">(</span><span class="n">x</span><span class="o">/</span><span class="mi">2</span><span class="p">,</span> <span class="n">x</span><span class="o">**</span><span class="p">(</span><span class="mi">1</span><span class="o">/</span><span class="mi">2</span><span class="p">))</span>
<span class="c1">// modification
</span><span class="n">update_gen_set</span><span class="p">(</span><span class="n">x</span><span class="o">/</span><span class="mi">3</span><span class="p">)</span>
<span class="n">gen_set</span> <span class="o">=</span> <span class="p">(</span><span class="n">x</span><span class="o">/</span><span class="mi">6</span><span class="p">)</span>
<span class="c1">// no change
</span><span class="n">update_gen_set</span><span class="p">(</span><span class="n">x</span><span class="p">)</span>
<span class="n">gen_set</span> <span class="o">=</span> <span class="p">(</span><span class="n">x</span><span class="o">/</span><span class="mi">2</span><span class="p">)</span>
</code></pre>
</div>
<p>I have a short description on the storage of these generators in the PR description and subsequent comments. Please do have a look!</p>
<h3 id="polynomial-conversions">Polynomial Conversions</h3>
<p>The next half of the week’s work involved actually converting a <code class="highlighter-rouge">Basic</code> into a polynomial. The API is too look as follows</p>
<div class="language-c++ highlighter-rouge"><pre class="highlight"><code><span class="n">RCP</span><span class="o"><</span><span class="n">Basic</span><span class="o">></span> <span class="n">UIntPoly</span><span class="o">::</span><span class="n">from_basic</span><span class="p">(</span><span class="n">Basic</span> <span class="n">x</span><span class="p">);</span>
<span class="n">RCP</span><span class="o"><</span><span class="n">Basic</span><span class="o">></span> <span class="n">UIntPoly</span><span class="o">::</span><span class="n">from_basic</span><span class="p">(</span><span class="n">Basic</span> <span class="n">x</span><span class="p">,</span> <span class="n">Basic</span> <span class="n">gen</span><span class="p">);</span>
</code></pre>
</div>
<p>The user can either supply a generator or one will automatically be deduced and used. The functions will throw of exactly one generator is not found, as we are dealing with univariate polynomials. Initially, I planned to write two different functions for <code class="highlighter-rouge">UIntPoly</code> and <code class="highlighter-rouge">UExprPoly</code> conversions, but soon I realized that most of the code was going to be identical. So, I formed a template function base with most of the common code, while the specific visitors inherit from this template base class with special methods.</p>
<p>The actual conversion was not too difficult, it just had to be broken down into cases like the <code class="highlighter-rouge">find_gen</code> problem. I leave it to the reader to try and theorize how this can be done. For eg. Imagine an <code class="highlighter-rouge">Add</code>, you can call <code class="highlighter-rouge">b2poly</code> on each expression added and add up the resulting polynomials. The code right now is scalable, and if we add in more polynomial classes like <code class="highlighter-rouge">URatPoly</code> there will be no issues in adding them in.</p>
<h3 id="miscellaneous-work">Miscellaneous Work</h3>
<ul>
<li>
<p>Templatized <code class="highlighter-rouge">pow_upoly</code> so that it can be used by any general polynomial class. Also removed some redundant code in the <code class="highlighter-rouge">ExpandVisitor</code> related to said function. Can be seen in <a href="https://github.com/symengine/symengine/pull/1010">#1010</a></p>
</li>
<li>
<p>I was just testing out how the parser is working out with the basic to polynomial conversions. It is working very seamlessly, constructing polynomials has never been easier! It’s as simple as</p>
</li>
</ul>
<div class="language-c++ highlighter-rouge"><pre class="highlight"><code><span class="n">s</span> <span class="o">=</span> <span class="s">"2*(x+1)**10 + 3*(x+2)**5"</span><span class="p">;</span>
<span class="n">poly</span> <span class="o">=</span> <span class="n">UIntPoly</span><span class="o">::</span><span class="n">from_basic</span><span class="p">(</span><span class="n">parse</span><span class="p">(</span><span class="n">s</span><span class="p">));</span>
<span class="n">s</span> <span class="o">=</span> <span class="s">"((x+1)**5)*(x+2)*(2*x + 1)**3"</span><span class="p">;</span>
<span class="n">poly</span> <span class="o">=</span> <span class="n">UIntPoly</span><span class="o">::</span><span class="n">from_basic</span><span class="p">(</span><span class="n">parse</span><span class="p">(</span><span class="n">s</span><span class="p">));</span>
</code></pre>
</div>
<p>Laters!</p>
Basic To Poly2016-06-26T00:00:00+00:00http://srajangarg.github.io//2016/06/26/Basic-Poly<h3 id="overview">Overview</h3>
<p>All of my week was mostly consumed by asking questions like “Should this throw?” and “What are it’s generators?”. My work for this week was to make a mechanism for converting arbitrary expression into polynomials. Turns out, it isn’t as trivial as it initially sounded. I will discuss my progress below. This week has been a lot more of logic involved, and thinking about how to go ahead instead of just development, so I do not have a lot to write about.</p>
<h3 id="the-idea">The Idea</h3>
<p>A multivariate polynomial is made of generators. A univariate polynomial is made of a single generator. Each term in a polynomial is a monomial which is multiplication of it’s generators to a non-negative power, which also has a non-zero coefficient multiplied to it. Here are some polynomials and their generators :</p>
<div class="highlighter-rouge"><pre class="highlight"><code>x**2 + x**5 -> x
sqrt(3) + sqrt(3)**3 -> sqrt(3)
(1/x**2) + (1/x**5) -> (1/x)
x**2 + y**2 + x -> x, y
2**x + 1 -> 2**x
</code></pre>
</div>
<p>I hope you get the idea. The main task is given a <code class="highlighter-rouge">Basic</code>, we need to construct a polynomial with appropriate generator. The task is broken down into two parts. First off, we try and extract a generator from the given expression. Secondly, use the found (or user given) generator to construct the polynomial.</p>
<p>Ideally the API should look as follows:</p>
<div class="highlighter-rouge"><pre class="highlight"><code>RCP<Basic> UIntPoly::from_basic(Basic x);
RCP<Basic> UIntPoly::from_basic(Basic x, Basic gen);
</code></pre>
</div>
<h3 id="my-progress">My Progress</h3>
<p>I have only worked on the univariate polynomial class as of now, and was to write the <code class="highlighter-rouge">from_basic</code> method just for the univariate classes for now. Although I just had to deal with the specific case of univariate integer polynomials, I haven’t successfully been able to get the job done just yet.</p>
<p>The work started with converting <code class="highlighter-rouge">Symbol var</code> to <code class="highlighter-rouge">Basic var</code>. Initially, the generators of the polynomial class could only be symbols, however this needed to be changed, as we’ve seen generators can be anything! This change did not take a lot of effort.</p>
<p>I started off with a <code class="highlighter-rouge">find_gen</code> function which given a <code class="highlighter-rouge">Basic</code> will try and find a unique generator for the polynomial to be constructed. Ideally, if no generator/ more than one generator is found it will throw a runtime error. I covered most of the cases but a few still remain.</p>
<p>Also, an initial implementation of the <code class="highlighter-rouge">to_poly</code> functionality has been done, complete with the required API. Some cases related to conversion still need to be handled. I do not want to go into the logic involved into each conversion as it is tedious and not very structured. All the work done till now can be seen in <a href="https://github.com/symengine/symengine/pull/998">#998</a>.</p>
<p>I hope with all the information I have gained over this week, I will wind up the <code class="highlighter-rouge">Basic</code> to <code class="highlighter-rouge">UPoly</code> conversions for both the integer coefficients as well as the general expression coefficients by the end of next week. I also intend to make the logic more concrete, so that the same API can be used in the multivariate case.</p>
<h3 id="miscellaneous-work">Miscellaneous Work</h3>
<ul>
<li>I made some changes in the <code class="highlighter-rouge">expand</code> function related to polynomials. They mostly have to deal with removal of code, which has already been implemented. It is also a partial fix for <a href="https://github.com/symengine/symengine/issues/886">#886</a>, work is in <a href="https://github.com/symengine/symengine/pull/999">#999</a>.</li>
</ul>
<p>Tata!</p>
Polynomial Functionalities2016-06-19T00:00:00+00:00http://srajangarg.github.io//2016/06/19/Polynomial-Functionality<h3 id="overview">Overview</h3>
<p>The last week was spent on adding more functionality to all the three types of Integer Polynomials in SymEngine. Which meant that I had to basically wrap methods already existing in Piranha and Flint, and write new methods for the SymEngine polynomials to provide the required functionality. Details about said functions and the problems faced while implementing them are described in the rest of the post.</p>
<p>Also this Saturday, some friends and I decided to visit the hill station of Lonavala for the day. It was a replenishing experience, and a break from the regular routine. Here’s us!</p>
<p><img src="http://srajangarg.github.io/assets/lonavala.jpg" alt="" /></p>
<h3 id="functions">Functions</h3>
<p>I wanted to start off by adding a <code class="highlighter-rouge">div_upoly</code> functions for dividing two univariate polynomials. It is obvious that division of two polynomials with integer coefficients may very well result in polynomials with rational coefficients. But a rational polynomial class does not exist. So what does it mean to divide two univariate polynomials and get a integer polynomial quotient and remainder? The domain <code class="highlighter-rouge">ZZ[x]</code> is not a <a href="https://en.wikipedia.org/wiki/Euclidean_domain">Euclidean Domain</a>. Here is what we mean by Euclidean division,</p>
<div class="highlighter-rouge"><pre class="highlight"><code>Two polynomials p, q can uniquely be written as
p = quo * q + rem
deg(rem) < deg(q) or rem = 0
</code></pre>
</div>
<p>Thus the euclidean division that we are so familiar with is not defined for this domain. So how do other libraries handle this division? I tried the division with Flint, Sage and SymPy.</p>
<div class="highlighter-rouge"><pre class="highlight"><code>In [14]: q = Poly(2*x)
In [15]: p = Poly(5*x**2)
In [16]: div(p, q, domain=ZZ)
</code></pre>
</div>
<p>Flint and Sage gave :</p>
<div class="highlighter-rouge"><pre class="highlight"><code>quo = Poly(2*x, x, domain='ZZ')
rem = Poly(x**2, x, domain='ZZ')
</code></pre>
</div>
<p>while SymPy gave :</p>
<div class="highlighter-rouge"><pre class="highlight"><code>quo = Poly(0, x, domain='ZZ')
rem = Poly(5*x**2, x, domain='ZZ')
</code></pre>
</div>
<p>This was interesting, as SymPy gave a different answer than the other two. I asked about this behaviour on gitter, and had a brief explanation given by <a href="https://github.com/jksuom">@jksuom</a>,</p>
<blockquote>
<p>The operation <code class="highlighter-rouge">quo_rem</code> is mathematically well defined only in so-called Euclidean domains. They are principal ideal domains (PIDs) equipped with a ‘Euclidean function. <code class="highlighter-rouge">ZZ[x]</code> is not a PID, so there is no universal agreement on how <code class="highlighter-rouge">quo_rem</code> should be defined. I think that there are some appealing features in the way it is defined in sage, but one cannot say that SymPy’s way would be wrong, either.</p>
</blockquote>
<blockquote>
<p>It seems that the main (only?) practical use of <code class="highlighter-rouge">quo_rem</code> in non-Euclidean domains is for testing if an element is divisible by another. That happens when the remainder vanishes. Both ways of defining <code class="highlighter-rouge">quo_rem</code> in <code class="highlighter-rouge">ZZ[x]</code> can be used to decide this.</p>
</blockquote>
<p>This explanation made a lot of sense, but I was anyways asked to open up <a href="https://github.com/sympy/sympy/issues/11240">#11240</a>, to know why SymPy handled division the way it did, and if it could be changed. Taking in all the inputs, I decided that I should not go ahead with a <code class="highlighter-rouge">div_upoly</code> function for now, instead I made a <code class="highlighter-rouge">divides_upoly</code> function which basically tells wether a polynomial divides the other or not. I had to implement the straight forward algorithm in SymEngine, while Flint already had a <code class="highlighter-rouge">divides</code> function and Piranha throws an exception on inexact division, which I used to port it for Piranha polynomials.</p>
<p>Other methods which were wrapped were <code class="highlighter-rouge">gcd</code> and <code class="highlighter-rouge">lcm</code> for both the Flint and the Piranha polynomials. I have not been able to write these functions for SymEngine polynomials yet. The most trivial algorithms for finding GCD of two univariate polynomials depends on euclidean division, and that does not exist in the integer ring polynomials. Some more information from <a href="https://github.com/jksuom">@jksuom</a>,</p>
<blockquote>
<p>The ring <code class="highlighter-rouge">ZZ[x]</code> is a unique factorization domain (UFD) even if it is not euclidean. It has <code class="highlighter-rouge">gcd</code> and <code class="highlighter-rouge">lcm</code>, but there is no euclidean algorithm for them.</p>
</blockquote>
<p>Isuru suggested a hint for a simple algorithm, but I have not been able to follow it up yet. I’ll catch up with it in the coming week. The next function I worked on was <code class="highlighter-rouge">pow</code>. Again this was already implemented in the two other libraries and I just had to wrap them. For SymEngine, I had to decide which algorithm to use, a naive repeated approach or the <a href="https://en.wikipedia.org/wiki/Exponentiation_by_squaring">exponention by squaring</a> algorithm. I also benchmarked the <code class="highlighter-rouge">pow</code> methods of Piranha too. All the work and the benchmarks are in <a href="https://github.com/symengine/symengine/pull/989">#989</a>.</p>
<h3 id="miscellaneous-work">Miscellaneous Work</h3>
<ul>
<li>
<p>Other functionalities like <code class="highlighter-rouge">multieval</code>, <code class="highlighter-rouge">derivative</code> and <code class="highlighter-rouge">get_lc</code> were also added for all the three intger polynomials.</p>
</li>
<li>
<p>There was an error in the Flint documentation, which was related with incorrect ordering of the arguments being passed to the <code class="highlighter-rouge">divides</code> function. It was reported in <a href="https://github.com/wbhart/flint2/issues/267">#267</a>.</p>
</li>
<li>
<p>Piranha required some implementations to be explicitly provided on the coefficient class, we are going to use. Thus, I had to overwrite some implementations like <code class="highlighter-rouge">gcd_impl</code>, <code class="highlighter-rouge">pow_impl</code> and <code class="highlighter-rouge">divexact_impl</code> for <code class="highlighter-rouge">SymEngine::intger_class</code> to work with <code class="highlighter-rouge">piranha::polynomial</code>.</p>
</li>
</ul>
<p>I will write <code class="highlighter-rouge">gcd</code> and <code class="highlighter-rouge">lcm</code> for SymEngine polynomials, and start on <code class="highlighter-rouge">Basic -> Poly</code> conversion to add to the coercion framework decided for SymEngine, soon.</p>
<p>See you!</p>
Piranha Polynomials & Iterators2016-06-12T00:00:00+00:00http://srajangarg.github.io//2016/06/12/Piranha-Polynomials<h3 id="overview">Overview</h3>
<p>I worked on wrapping Piranha polynomials within SymEngine this week. It felt much more interesting than wrapping Flint polynomials, mainly because I was reading the Piranha’s source and was in direct touch with the author of the library. Many thanks to <a href="https://github.com/bluescarni">@bluescarni</a> who helped me getting familiar with it. As before, I’ll briefly summarize the work I did this week along with my progress.</p>
<h3 id="piranha-polynomials">Piranha Polynomials</h3>
<p>Piranha’s polynomial class is the <code class="highlighter-rouge">piranha::polynomial</code> class. It’s templatized as follows:</p>
<div class="language-c++ highlighter-rouge"><pre class="highlight"><code><span class="k">template</span><span class="o"><</span><span class="k">typename</span> <span class="n">Cf</span><span class="p">,</span> <span class="k">typename</span> <span class="n">Key</span><span class="o">></span>
<span class="k">class</span> <span class="nc">polynomial</span> <span class="o">:</span> <span class="n">power_series</span><span class="o"><</span> <span class="p">...</span> <span class="o">></span>
</code></pre>
</div>
<p>There are two major differences about Piranha Polynomials and SymEngine polynomials. Firstly, it uses a custom unordered map implementation called <code class="highlighter-rouge">hash_set</code> for storing it’s degree-coefficient pairs. <code class="highlighter-rouge">hash_set</code> has been internally optimized for polynomial manipulations in general. On a side note, this makes SymEngine have all three types of polynomial representations too! Secondly, Piranha does not distinguish between univariate polynomials and multivariate polynomials. All polynomials are multivariate polynomials, univariate polynomials being a special case (with just one element in it’s <code class="highlighter-rouge">symbol_set</code>).</p>
<p>Here, <code class="highlighter-rouge">Cf</code> is the class for storing the coefficients, while <code class="highlighter-rouge">Key</code> are the monomials themselves. Unlike Flint, we can use any integer class as the coefficient class for the polynomials. So, the first question was wether to use <code class="highlighter-rouge">piranha::integer</code> (and use implicit conversions like I did in Flint polynomials) or <code class="highlighter-rouge">SymEngine::integer_class</code> as the integer class for Piranha polynomials. After a brief discussion with Isuru, we decided to go with SymEngine’s integers. The <code class="highlighter-rouge">Key</code> class used is <code class="highlighter-rouge">piranha::monomial<uint></code>, which means it will store one <code class="highlighter-rouge">unsigned int</code> per symbol (representing the degree, in each monomial).</p>
<h3 id="symengines-integers-in-piranhapolynomial">SymEngine’s integers in <code class="highlighter-rouge">piranha::polynomial</code></h3>
<p>For an integer class to be usable as the <code class="highlighter-rouge">Cf</code> it should have some basic properties like, default constructibility, copy constructibility, <code class="highlighter-rouge">nothrow</code> destructibility, <code class="highlighter-rouge">nothrow</code> move assignability and <code class="highlighter-rouge">nothrow</code> move constructibility. As of yet, <code class="highlighter-rouge">mpz_wrapper</code>, <code class="highlighter-rouge">fmpz_wrapper</code> and <code class="highlighter-rouge">mpz_class</code> did not pass the <code class="highlighter-rouge">nothrow</code> checks. All that had to bee done was that I had to add <code class="highlighter-rouge">noexcept</code> to the wrappers we had already written. This allowed <code class="highlighter-rouge">mpz_wrapper</code> and <code class="highlighter-rouge">fmpz_wrapper</code> to be used as coefficients in Piranha polynomials. Ofcourse, Piranha’s own integer class passes all these checks too.</p>
<p>Currently, there is no solution for having <code class="highlighter-rouge">mpz_class</code> as the coefficient class for polynomials. Firstly, these gmpxx integers methods have not been marked <code class="highlighter-rouge">nothrow</code> yet. There is a forum <a href="https://gmplib.org/list-archives/gmp-devel/2016-April/004271.html">post</a> on how it can be added, and actually has been added in the development version but hasn’t been released yet. Another reason is that <code class="highlighter-rouge">mpz_class</code> uses <a href="https://en.wikipedia.org/wiki/Expression_templates">expression templates</a> for improved performance. This means that unlike normal integers, any arithmetic operation does not necessarily return the same integer class.</p>
<div class="language-c++ highlighter-rouge"><pre class="highlight"><code><span class="kt">int</span> <span class="n">a</span><span class="p">,</span> <span class="n">b</span><span class="p">;</span>
<span class="n">is_a</span><span class="o"><</span><span class="kt">int</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="p">);</span> <span class="c1">// true
</span>
<span class="n">mpz_class</span> <span class="n">a</span><span class="p">,</span> <span class="n">b</span><span class="p">;</span>
<span class="n">is_a</span><span class="o"><</span><span class="n">mpz_class</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="p">);</span> <span class="c1">// false
</span></code></pre>
</div>
<p>The reason it cannot be used within Piranha is that Piranha checks the coefficient type after each operation so that it knows what <a href="https://en.wikipedia.org/wiki/Polynomial_ring">ring</a> the polynomial belongs to. Here, it will be unable to detect what the ring is, as the returned coefficient will be an expression template. Thus, it was decided that the integer class <code class="highlighter-rouge">mpz_class</code> can’t be used alongside Piranha with SymEngine. So, the following became invalid, on which a warning is thrown and the class is changed to <code class="highlighter-rouge">mpz_wrapper</code> :</p>
<div class="highlighter-rouge"><pre class="highlight"><code>cmake -DWITH_PIRANHA=yes -DINTEGER_CLASS=gmpxx
</code></pre>
</div>
<p>All the work on Piranha polynomials and the <code class="highlighter-rouge">cmake</code> changes can be found in <a href="https://github.com/symengine/symengine/pull/980">#980</a>.</p>
<h3 id="iterators">Iterators</h3>
<p>Currently this is what the <code class="highlighter-rouge">print</code> functions for our univariate integer polynomials looked like :</p>
<div class="language-c++ highlighter-rouge"><pre class="highlight"><code><span class="n">string</span> <span class="nf">print</span><span class="p">(</span><span class="k">const</span> <span class="n">UIntPoly</span><span class="o">&</span> <span class="n">p</span><span class="p">)</span>
<span class="p">{</span>
<span class="k">for</span><span class="p">(</span><span class="k">auto</span> <span class="n">it</span> <span class="o">=</span> <span class="n">p</span><span class="p">.</span><span class="n">dict_</span><span class="p">.</span><span class="n">begin</span><span class="p">();</span> <span class="n">it</span> <span class="o">!=</span> <span class="n">p</span><span class="p">.</span><span class="n">dict_</span><span class="p">.</span><span class="n">end</span><span class="p">();</span> <span class="o">++</span><span class="n">it</span><span class="p">)</span>
<span class="p">{</span>
<span class="c1">// use it->first and it->second
</span> <span class="p">}</span>
<span class="p">}</span>
<span class="n">string</span> <span class="nf">print</span><span class="p">(</span><span class="k">const</span> <span class="n">UIntPolyFlint</span><span class="o">&</span> <span class="n">p</span><span class="p">)</span>
<span class="p">{</span>
<span class="k">for</span><span class="p">(</span><span class="k">auto</span> <span class="n">it</span> <span class="o">=</span> <span class="n">p</span><span class="p">.</span><span class="n">degree</span><span class="p">();</span> <span class="n">it</span> <span class="o">>=</span> <span class="mi">0</span><span class="p">;</span> <span class="o">--</span><span class="n">it</span><span class="p">)</span>
<span class="p">{</span>
<span class="c1">// use it and p.get_coeff(it)
</span> <span class="p">}</span>
<span class="p">}</span>
</code></pre>
</div>
<p>These methods are very similar and do not deserve to be separate functions. All that was needed to unify these methods was to have iterators for each of the three classes, and then we can have use the same code for many functions like <code class="highlighter-rouge">print</code>, <code class="highlighter-rouge">as_symbolic</code> and <code class="highlighter-rouge">derivative</code>. This also called for a new base class to be made, <code class="highlighter-rouge">UIntPolyBase</code> from which these three integer polynomials inherit and it itself inherits from the original base class <code class="highlighter-rouge">UPolyBase</code>.</p>
<p>I stuck with the syntax of <code class="highlighter-rouge">it->first</code> and <code class="highlighter-rouge">it->second</code> for the unified iterators. Which means <code class="highlighter-rouge">operator*</code> needed to return a <code class="highlighter-rouge">std::pair<uint, integer_class></code>. So, for SymEngine polynomials all I needed to do was return iterators to the internal dictionary and that was it. Not going into too much technicality, for Flint and Piranha I used custom iterators which had <code class="highlighter-rouge">operator++</code> defined on them and returned a pair whenever <code class="highlighter-rouge">it-></code> or <code class="highlighter-rouge">*it</code> was called on them. They basically iterated over the degree and returned only for non-zero coefficients for both the libraries. The actual implementation of the iterator scheme can be seen in <a href="https://github.com/symengine/symengine/pull/985">#985</a>.</p>
<p>Initially I was happy with this approach and was able to write (unifying the three) :</p>
<div class="highlighter-rouge"><pre class="highlight"><code>string print(const UIntPolyBase& p)
{
for(auto it = p.dict_.begin(); it != p.dict_.end(); ++it)
{
// use it->first and it->second
}
}
</code></pre>
</div>
<p>Isuru pointed out that instead of returning the <code class="highlighter-rouge">integer_class</code> in the pair, we should return a reference to it. Now, this made sense but was a bit tricky to implement. Also the iterator could no longer return reference like <code class="highlighter-rouge">const integer_class&</code>, as Flint did not even store it’s coefficients as <code class="highlighter-rouge">integer_class</code>. To tackle this, another template parameter had to be added to the custom iterator class which determined the second term of the pair (which was supposed to be the reference to the coefficient in the internal storage of the polynomial). Also, I had to dig in to the Flint documentation and ask Piranha’s author, for knowing how I could get <code class="highlighter-rouge">const</code> references to the coefficients in internal storage. After this was finally implemented, there was a new <code class="highlighter-rouge">get_coeff_ref</code> method, which does not copy but returns a reference to the required coefficient. The only downside to all this was that instead of <code class="highlighter-rouge">it->second</code> I had to use <code class="highlighter-rouge">to_integer_class(it->second)</code> everywhere in the common functions.</p>
<h3 id="miscellaneous-work">Miscellaneous Work</h3>
<ul>
<li>I saw that in SymEngine, there were lots of redundant header file includes in many files. I wrote a short python script which makes a header dependency tree, and automatically removes header includes which are not needed. After some manual inspection of the changes I pushed in <a href="https://github.com/symengine/symengine/pull/981">#981</a>. It was really amazing to see the script flag more than 500 lines of redundant includes. The PR has not been merged yet, though.</li>
</ul>
<p>I will be working on higher level functionality like <code class="highlighter-rouge">gcd</code> in the coming week. Will keep you guys posted.</p>
<p>Laters!</p>
Flint Polynomials2016-06-06T00:00:00+00:00http://srajangarg.github.io//2016/06/06/Flint-Polynomials<h3 id="overview">Overview</h3>
<p>This week has not been as interesting as the last. Most of my work this week involved wrapping Flint Polynomials, for use in SymEngine. I will discuss their internal implementation and how they were integrated to the library.</p>
<h3 id="flint-polynomials">Flint Polynomials</h3>
<p>Flint’s integer polynomial class is the <code class="highlighter-rouge">fmpz_poly</code> class. Flint, being a C library also provides a C++ wrapper for most of it’s classes. In our case, it’s the <code class="highlighter-rouge">fmpz_polyxx</code> class. As discussed last week, the arithmetic operators for the class have already been overloaded and it can be seamlessly used with the base class which is already set up.</p>
<p>Internally, flint uses a dense representation of polynomials. What this means is that the coefficient for each degree in the polynomial are stored in a vector. This is in contrast to a sparse approach which deals stores only non-zero coefficients of a polynomial in a dictionary. Flint also uses it’s own integer class as the coefficient type. Flint’s integers are basically similar to GMP integers, and also follow the same naming conventions. (eg. <code class="highlighter-rouge">fmpz_t</code> is analogous to <code class="highlighter-rouge">mpz_t</code>) They have internal optimizations to make them faster for use within the flint library itself. Flint does not provide the option to use a custom integer class as the type of coefficients like Piranha does.</p>
<p>All the work related to flint polynomials can be seen in <a href="https://github.com/symengine/symengine/pull/971">#971</a>. The majority of the PR concerns introducing a new class <code class="highlighter-rouge">UIntPolyFlint</code> and all the necessary functionality like <code class="highlighter-rouge">__hash__</code>, <code class="highlighter-rouge">eval</code> and <code class="highlighter-rouge">compare</code>. Test cases have also been added, to see if the polynomial manipulation is working as intended. There is some additional minor work done here apart from this class introduction.</p>
<p>The polynomial base class now has three methods :</p>
<div class="language-c++ highlighter-rouge"><pre class="highlight"><code><span class="k">static</span> <span class="n">Poly</span> <span class="n">from_container</span><span class="p">()</span>
<span class="k">static</span> <span class="n">Poly</span> <span class="n">from_dict</span><span class="p">()</span>
<span class="k">static</span> <span class="n">Poly</span> <span class="n">from_vec</span><span class="p">()</span>
</code></pre>
</div>
<p>These methods are, as indicated from their names, used to construct the polynomial from any of the three sources. So, for example to construct a <code class="highlighter-rouge">UIntPolyFlint</code>, you can :</p>
<div class="language-c++ highlighter-rouge"><pre class="highlight"><code><span class="n">PolyFlint</span> <span class="n">a</span> <span class="o">=</span> <span class="n">PolyFlint</span><span class="o">::</span><span class="n">from_container</span><span class="p">(</span><span class="n">fmpz_polyxx</span> <span class="n">A</span><span class="p">);</span>
<span class="n">PolyFlint</span> <span class="n">b</span> <span class="o">=</span> <span class="n">PolyFlint</span><span class="o">::</span><span class="n">from_vec</span><span class="p">(</span><span class="n">vector</span><span class="o"><</span><span class="n">integer_class</span><span class="o">></span> <span class="n">B</span><span class="p">);</span>
<span class="n">PolyFlint</span> <span class="n">a</span> <span class="o">=</span> <span class="n">PolyFlint</span><span class="o">::</span><span class="n">from_dict</span><span class="p">(</span><span class="n">map</span><span class="o"><</span><span class="n">uint</span><span class="p">,</span> <span class="n">integer_class</span><span class="o">></span> <span class="n">C</span><span class="p">);</span>
</code></pre>
</div>
<h3 id="integerclass-conversions"><code class="highlighter-rouge">integer_class</code> Conversions</h3>
<p>Another issue was that methods like <code class="highlighter-rouge">eval</code> must return integers of <code class="highlighter-rouge">integer_class</code>. Thus, we needed functions to convert <code class="highlighter-rouge">fmpzxx</code> to any of the 4 possible integer classes used by SymEngine. The 4 integers used by SymEngine are :</p>
<div class="highlighter-rouge"><pre class="highlight"><code>1. mpz_class The default C++ class provided by GMP
2. mpz_wrapper SymEngine's wrapper around GMP's mpz_t
3. piranha::integer Piranha's integer class
3. fmpz_wrapper SymEngine's wrapper around Flint's fmpz_t
</code></pre>
</div>
<p>We, might even require such conversion for Piranha polynomials. So, I generalized this and made <code class="highlighter-rouge">to_integer_class()</code> which takes in either <code class="highlighter-rouge">flint::fmpzxx</code> or <code class="highlighter-rouge">piranha::integer</code> and returns an <code class="highlighter-rouge">integer_class</code>. There was a small discussion on where these functions should be placed, with Isuru which was insightful. Basically, what I was doing earlier caused a considerable <a href="https://github.com/symengine/symengine/pull/971#issuecomment-223743950">increase</a> in compilation time, which was later corrected. An example of one such function is :</p>
<div class="language-c++ highlighter-rouge"><pre class="highlight"><code><span class="cp">#if SYMENGINE_INTEGER_CLASS == GMP || GMPXX
#ifdef HAVE_SYMENGINE_FLINT
</span><span class="kr">inline</span> <span class="n">integer_class</span> <span class="nf">to_integer_class</span><span class="p">(</span><span class="k">const</span> <span class="n">flint</span><span class="o">::</span><span class="n">fmpzxx</span> <span class="o">&</span><span class="n">i</span><span class="p">)</span>
<span class="p">{</span>
<span class="n">integer_class</span> <span class="n">x</span><span class="p">;</span>
<span class="n">fmpz_get_mpz</span><span class="p">(</span><span class="n">x</span><span class="p">.</span><span class="n">get_mpz_t</span><span class="p">(),</span> <span class="n">i</span><span class="p">.</span><span class="n">_data</span><span class="p">().</span><span class="n">inner</span><span class="p">);</span>
<span class="k">return</span> <span class="n">x</span><span class="p">;</span>
<span class="p">}</span>
<span class="cp">#endif
#endif
</span></code></pre>
</div>
<p>A <code class="highlighter-rouge">get_coeff()</code> function was also added to the polynomial base is a much needed function for any polynomial manipulation.</p>
<h3 id="miscellaneous-work">Miscellaneous Work</h3>
<ul>
<li>
<p>There were some changes done to the polynomial structure before the flint polynomials were introduced. Constructor of the polynomials from vectors was removed, as it wasn’t required. And a <code class="highlighter-rouge">from_vec</code> was added for the SymEngine polynomial dictionaries <code class="highlighter-rouge">UIntDict</code> and <code class="highlighter-rouge">UExprDict</code>. The changes can be seen here <a href="https://github.com/symengine/symengine/pull/965/">#965</a>.</p>
</li>
<li>
<p>In Travis CI builds, SymEngine was using flint-2.4.4 from a static location. There’s a <a href="https://github.com/wbhart/flint2/issues/217">bug</a> that I encountered using this version, which dealt with incorrect header declaration in one of the flint files. Now, we clone the flint repository from <a href="https://github.com/wbhart/flint2/">wbhart/flint2</a> to use in the CI builds. The change is in <a href="https://github.com/symengine/symengine/pull/973">#973</a>.</p>
</li>
</ul>
<p>I’m working on wrapping Piranha polynomials next week. After that is done, I plan to start getting higher level functionality like <code class="highlighter-rouge">gcd</code> and <code class="highlighter-rouge">factorize</code> ready.</p>
<p>Ciao!</p>
Wrap a lot2016-05-29T00:00:00+00:00http://srajangarg.github.io//2016/05/29/Wrap-a-Lot<h3 id="overview">Overview</h3>
<p>As I pointed out in last week’s post, I have begun my work on the wrapping aspects of my project. The final aim of wrapping the polynomial class is to provide users with the option of using specialized polynomial libraries like Flint and Piranha.</p>
<p>Right at the beginning of the project, I was lacking the basic idea of how the wrapping will work. Mostly I was confused by the fact that we have to right common code for all the libraries (SymEngine, Flint & Piranha) with the problem being, each of the these libraries have different internal representation and methods. By the end of the week, thanks to Isuru, I have much more understanding of the desired structure of the code. Here’s a short summary on how it will work.</p>
<h3 id="polynomial-base">Polynomial Base</h3>
<p>There will be four end (derived) classes. <code class="highlighter-rouge">UIntPoly</code> & <code class="highlighter-rouge">UExprPoly</code> (the SymEngine) polynomials, <code class="highlighter-rouge">UIntPolyFlint</code> and also <code class="highlighter-rouge">UIntPolyPiranha</code>. Each of these classes derive from the base class called <code class="highlighter-rouge">UPolyBase</code>. Now the base class must have methods and members which can be used commonly by each of the derived classes. Thus, the base class should have two members, the <code class="highlighter-rouge">var</code> which depicts the variable of the polynomial and a <code class="highlighter-rouge">container</code> which contains the data about the polynomial (basically the coefficients corresponding to each degree).</p>
<p>This is skeleton of how the classes should look like :</p>
<div class="language-c++ highlighter-rouge"><pre class="highlight"><code><span class="k">template</span> <span class="o"><</span><span class="k">typename</span> <span class="n">Container</span><span class="o">></span>
<span class="k">class</span> <span class="nc">UPolyBase</span>
<span class="p">{</span>
<span class="n">Symbol</span> <span class="n">var</span><span class="p">;</span>
<span class="n">Container</span> <span class="n">container</span><span class="p">;</span>
<span class="p">}</span>
<span class="c1">// the derived polynomials
</span><span class="k">class</span> <span class="nc">UIntPolyPiranha</span> <span class="o">:</span> <span class="n">UPolyBase</span><span class="o"><</span><span class="n">piranha</span><span class="o">::</span><span class="n">polynomail</span><span class="o">></span>
<span class="k">class</span> <span class="nc">UIntPolyFlint</span> <span class="o">:</span> <span class="n">UPolyBase</span><span class="o"><</span><span class="n">flint</span><span class="o">::</span><span class="n">fmpz_polyxx</span><span class="o">></span>
</code></pre>
</div>
<h3 id="symengines-container">SymEngine’s Container</h3>
<p>The containers of the Flint and Piranha will be discussed in detail in the upcoming weeks. We now had to think about what the container must be for SymEngine. Also we have to merge as much functionality as possible. I saw that both the external libraries had operators overloaded for addition, subtraction, multiplication and division. So, methods like <code class="highlighter-rouge">add_poly</code> and <code class="highlighter-rouge">sub_poly</code> etc. could be made common in the base class itself if I implemented a container for holding SymEngine polynomials which also has it’s operators overloaded.</p>
<p>I was not familiar with the symbolic side of the polynomials, and found out that a container had already been made for <code class="highlighter-rouge">UExprPoly</code> called <code class="highlighter-rouge">UExprDict</code>. The class was nothing but a wrapper around <code class="highlighter-rouge">map<int, Expression></code>. It had overloaded methods for addition, subtraction etc. So, technically this dictionary was storing all the information about the polynomials. I just had to create another similar wrapper for <code class="highlighter-rouge">map<uint, integer_class></code> for the integer counterpart of the polynomial class. This resulted in <a href="https://github.com/symengine/symengine/pull/946">#946</a> and Isuru mentioned that most of the code for both these dictionary wrappers is about the same! So, I decided to make a base class for polynomial dictionary wrappers and both of these can inherit from that. Any different implementations (like <code class="highlighter-rouge">*=</code>) can be overridden in the derived class if needed.</p>
<p>The ordered map base looks like :</p>
<div class="language-c++ highlighter-rouge"><pre class="highlight"><code><span class="k">template</span> <span class="o"><</span><span class="k">typename</span> <span class="n">Key</span><span class="p">,</span> <span class="k">typename</span> <span class="n">Value</span><span class="p">,</span> <span class="k">typename</span> <span class="n">Wrapper</span><span class="o">></span>
<span class="k">class</span> <span class="nc">ODictWrapper</span>
<span class="p">{</span>
<span class="n">std</span><span class="o">::</span><span class="n">map</span><span class="o"><</span><span class="n">Key</span><span class="p">,</span> <span class="n">Value</span><span class="o">></span> <span class="n">dict_</span><span class="p">;</span>
<span class="k">friend</span> <span class="n">Wrapper</span> <span class="k">operator</span><span class="o">-</span><span class="p">(</span><span class="k">const</span> <span class="n">Wrapper</span> <span class="o">&</span><span class="n">a</span><span class="p">,</span> <span class="k">const</span> <span class="n">Wrapper</span> <span class="o">&</span><span class="n">b</span><span class="p">)</span>
<span class="p">{</span>
<span class="n">Wrapper</span> <span class="n">c</span> <span class="o">=</span> <span class="n">a</span><span class="p">;</span>
<span class="n">c</span> <span class="o">-=</span> <span class="n">b</span><span class="p">;</span>
<span class="k">return</span> <span class="n">c</span><span class="p">;</span>
<span class="p">}</span>
<span class="n">Wrapper</span> <span class="k">operator</span><span class="o">-</span><span class="p">()</span> <span class="k">const</span>
<span class="p">{</span>
<span class="n">ODictWrapper</span> <span class="n">c</span> <span class="o">=</span> <span class="o">*</span><span class="k">this</span><span class="p">;</span>
<span class="k">for</span> <span class="p">(</span><span class="k">auto</span> <span class="o">&</span><span class="n">iter</span> <span class="o">:</span> <span class="n">c</span><span class="p">.</span><span class="n">dict_</span><span class="p">)</span>
<span class="n">iter</span><span class="p">.</span><span class="n">second</span> <span class="o">*=</span> <span class="o">-</span><span class="mi">1</span><span class="p">;</span>
<span class="k">return</span> <span class="k">static_cast</span><span class="o"><</span><span class="n">Wrapper</span> <span class="o">&></span><span class="p">(</span><span class="n">c</span><span class="p">);</span>
<span class="p">}</span>
<span class="p">....</span>
<span class="p">}</span>
<span class="c1">// the derived wrappers
</span><span class="k">class</span> <span class="nc">UIntDict</span> <span class="o">:</span> <span class="n">ODictWrapper</span><span class="o"><</span><span class="n">uint</span><span class="p">,</span> <span class="n">integer_class</span><span class="p">,</span> <span class="n">UIntDict</span><span class="o">></span>
<span class="k">class</span> <span class="nc">UExprDict</span> <span class="o">:</span> <span class="n">ODictWrapper</span><span class="o"><</span><span class="kt">int</span><span class="p">,</span> <span class="n">Expression</span><span class="p">,</span> <span class="n">UExprDict</span><span class="o">></span>
</code></pre>
</div>
<h3 id="finishing-the-class">Finishing the class</h3>
<p>After the containers for SymEngine were complete, I started implementing the polynomial base class, from which the two current polynomial classes will inherit. The class turned out to be very similar to the prototype described above. Accessor methods were added and basic polynomial functions were added <a href="https://github.com/symengine/symengine/pull/951">#951</a>.</p>
<p>All we have to do now for functions like <code class="highlighter-rouge">add_poly</code> is use the overloaded operators on the containers. Also, template argument deduction will automatically allow us to call the functions directly on two same polynomial types.</p>
<p>An example of a common template function for addition :</p>
<div class="language-c++ highlighter-rouge"><pre class="highlight"><code><span class="k">template</span> <span class="o"><</span><span class="k">typename</span> <span class="n">Poly</span><span class="o">></span>
<span class="n">RCP</span><span class="o"><</span><span class="k">const</span> <span class="n">Poly</span><span class="o">></span> <span class="n">add_upoly</span><span class="p">(</span><span class="k">const</span> <span class="n">Poly</span> <span class="o">&</span><span class="n">a</span><span class="p">,</span> <span class="k">const</span> <span class="n">Poly</span> <span class="o">&</span><span class="n">b</span><span class="p">)</span>
<span class="p">{</span>
<span class="k">auto</span> <span class="n">dict</span> <span class="o">=</span> <span class="n">a</span><span class="p">.</span><span class="n">get_poly</span><span class="p">();</span>
<span class="n">dict</span> <span class="o">+=</span> <span class="n">b</span><span class="p">.</span><span class="n">get_poly</span><span class="p">();</span>
<span class="k">return</span> <span class="n">Poly</span><span class="o">::</span><span class="n">from_dict</span><span class="p">(</span><span class="n">a</span><span class="p">.</span><span class="n">get_var</span><span class="p">(),</span> <span class="n">std</span><span class="o">::</span><span class="n">move</span><span class="p">(</span><span class="n">dict</span><span class="p">));</span>
<span class="p">}</span>
</code></pre>
</div>
<p>and how easily it can be used :</p>
<div class="language-c++ highlighter-rouge"><pre class="highlight"><code><span class="n">A</span> <span class="o">=</span> <span class="n">uint_poly</span><span class="p">(</span><span class="s">"x"</span><span class="p">,</span> <span class="p">{(</span><span class="mi">0</span> <span class="o">:</span> <span class="mi">1</span><span class="p">),</span> <span class="p">(</span><span class="mi">1</span> <span class="o">:</span> <span class="mi">2</span><span class="p">)});</span> <span class="c1">// 2*x + 1
</span><span class="n">B</span> <span class="o">=</span> <span class="n">uint_poly</span><span class="p">(</span><span class="s">"x"</span><span class="p">,</span> <span class="p">{(</span><span class="mi">2</span> <span class="o">:</span> <span class="mi">2</span><span class="p">)});</span> <span class="c1">// 2*x**2
</span>
<span class="n">C</span> <span class="o">=</span> <span class="n">add_upoly</span><span class="p">(</span><span class="o">*</span><span class="n">A</span><span class="p">,</span> <span class="o">*</span><span class="n">B</span><span class="p">);</span>
</code></pre>
</div>
<h3 id="miscellaneous-work">Miscellaneous Work</h3>
<ul>
<li>
<p>The names of the classes I refer to here are the new names. The old names were a little unintuitive, so decided to change them, along with introducing a new subfolder in the repository to hold all code related to polynomials (and their tests). Some code was also shifted to places more apt, all changes can be seen here <a href="https://github.com/symengine/symengine/pull/960">#960</a>.</p>
</li>
<li>
<p>There are a small number of miscellaneous changes that need to be worked out in the overall structure, here they are <a href="https://github.com/symengine/symengine/pull/962">#962</a>.</p>
</li>
</ul>
<p>More on this and Flint next week! Goodbye!</p>
Pre GSoC and Community Bonding2016-05-21T00:00:00+00:00http://srajangarg.github.io//2016/05/21/Pre-GSoC<h3 id="the-kronecker-substitution">The Kronecker Substitution</h3>
<p>I started off my work by reading through the existing <code class="highlighter-rouge">mul_poly</code> function. It uses the Kronecker Substitution technique to multiply two polynomials. An insight can be gained by looking at the slides <a href="http://web.maths.unsw.edu.au/~davidharvey/talks/kronecker-talk.pdf">here</a>. Think of it this way,</p>
<blockquote>
<p>“If you evaluate a polynomial at a large enough power of 10, I bet you can tell all it’s coefficients just by looking at the result!”</p>
</blockquote>
<p>The mentioned slides call this the KS1 algorithm. Another algorithm it proposes is the KS2 algorithm, which evaluates the polynomial at two points (in contrast to just one) to interpolate the polynomial. A more mathematical explanation on the two techniques can be found <a href="http://arxiv.org/pdf/0712.4046v1.pdf">here</a>. I implemented the algorithm, and it wasn’t too difficult, as it was a a slight modification to the already existing multiplication technique. Later, I added a benchmark test for comparing the two techniques, KS1 & KS2. The benchmark (roughly) calculates the ratio of the time required for multiplying two polynomials using the two algorithms. Both the polynomial length (from 1 to 10,000) and the bit length of the coefficients (5, 10, 15, 20 bits) were varied. The graphs of the benchmarking are as follows.</p>
<p>Linear & Log scale :
<img src="/assets/ll.png" alt="" />
During this time, I was asked by Isuru to switch work towards the polynomial interface with FLINT & Piranha (and shift the polynomial manipulations to the end of summer). So, the PR hasn’t been merged in yet, and no conclusions and observations have been made between the two algorithms as of yet. Will be done later during the summer. Here’s the PR <a href="https://github.com/symengine/symengine/pull/930">#930</a></p>
<h3 id="dictionary-wrappers">Dictionary wrappers</h3>
<p>I also started work on Dictionary wrappers for SymEngine. One was already made, for the <code class="highlighter-rouge">UnivariatePolynomial</code> class aka the class for univariate polynomials with symbolic coefficients. It is a map from <code class="highlighter-rouge">int -> Expression</code>. We needed another wrapper for the <code class="highlighter-rouge">uint -> integer_class</code> map, so that the <code class="highlighter-rouge">UnivariateIntPolynomial</code> class can be structured the same way as the former. Now that we need almost the same functionality, why not temlatize the wrapper? (suggested by Isuru) That’s what I did, and the PR <a href="https://github.com/symengine/symengine/pull/946">#946</a> is almost merged in. More on wrappers next time!</p>
<h3 id="miscellaneous-issues">Miscellaneous issues</h3>
<p>Most of my work during this period revolved around reading the existing polynomial class, and refactor it and removed any redundancies. Some of the miscellaneous work that was done :</p>
<ul>
<li>
<p>Some refactoring was done in the <code class="highlighter-rouge">dict.cpp</code> file. There were some redundancy in the functions which was removed. Templatized methods for checking equality and comparing vectors (and sets) were made. Other specific <code class="highlighter-rouge">eq</code> & <code class="highlighter-rouge">compare</code> methods became derived methods of these base classes. <a href="https://github.com/symengine/symengine/pull/933">#933</a></p>
</li>
<li>
<p>Initially, the <code class="highlighter-rouge">mul_poly</code> method was constructing a vector of coefficients for the resulting multiplied polynomial (thus, implicitly storing it in a dense representation for a while). However, it was returned as a sparse represented polynomial, using a dictionary. This was changed, so that the dictionary is directly created, and the intermediate vector isn’t requireds. Also, some changes in variable names for clarity, as well as removing the redundant function <code class="highlighter-rouge">dict_add_term</code>. <a href="https://github.com/symengine/symengine/pull/928">#928</a></p>
</li>
<li>
<p>A redundant function <code class="highlighter-rouge">create</code> was removed. All it was doing was calling <code class="highlighter-rouge">from_vec</code> within the same class. <a href="https://github.com/symengine/symengine/pull/941">#941</a></p>
</li>
</ul>
<p>See you next week, Goodbye!</p>
Selected2016-04-29T00:00:00+00:00http://srajangarg.github.io//2016/04/29/Selected<p>I have been selected for GSoC’16! The results came out on Apr 23, and I have never been happier! I got around to writing this blog post only now, because of my end semester examinations which ended yesterday. I have been alotted <a href="https://github.com/isuruf">Isuru</a> and <a href="https://github.com/sumith1896">Sumith</a> as my official mentors. I’m very excited to start working on the project, alongside them.</p>
<p>Right now, I’ll start my discussions on the implementation details, and overall structure of the code. Also I will begin work on the Fast Fourier algorithm for univariate polynomial multiplication.</p>
<p>Looking forward to a busy summer!</p>
Initial Commit2016-03-07T00:00:00+00:00http://srajangarg.github.io//2016/03/07/Initial-Commit<p>This is my first blog post. The blog was made to track progress of my GSoC project and get feedback from my mentors, if my proposal gets selected. I’m proposing to implement the Multivariate and Univariate polynomial class in SymEngine.</p>
<p>Wish me luck!</p>