I missed canonicalization of the dictionary at the end. Need to fix that.

Yes, but there is a way to do so without the += and without creating a new object, which would greatly decrease the amount of time needed to calculate. You could just have the result go directly into

`dict_`

@srajangarg, it will be handled, but multiplying by a constant term should be handled specially for performance

@isuruf did you have a look at #959 ? Also, #951 is ready

btw, symengine openmp support is experimental and worsens benchmarks in most cases

@isuruf What kind of fast algorithm works well for sparse polynomial representation? I’ve been researching.

For multiplication.

@asmeurer, is there a way to specify the version number for a build dependency in a conda recipe? symengine.py is not building with Cython 0.24 and I want to use Cython 0.23

@chenchfort algorithmically the best you can do for multiplication is quadratic complexity, via hash tables

if you need the polys to be sorted (e.g., for GCD/division/Groebner basis etc.), complexity will be quadratic times log

I am not aware of any sub-quadratic algorithm for sparse poly multiplication

implementation details are going to matter a lot in practice, often even more than algorithmic complexity

I agree. For some benchmarks I've seen symengine is around 60X faster than sympy which means runtime is reduced from 15 mins to 15 seconds, but the speedup is constant. In this case algorithmic complexity is the same, but the implementation matters

@isuruf I was wondering if we can make the template of

Also, other functions like

`UPolyBase`

`template <typename Container, typename Poly, typename Coeff>`

? This will allow us to unify constructors https://github.com/symengine/symengine/blob/master/symengine/uint_base.h#L26Also, other functions like

`from_dict`

can also be moved to the base class. I think it can save a lot of common code.
@irislq Why is there a

`__str__()`

method for `UExprPoly`

? What's it's purpose?
Shouldn't we write the printing code for

`UnivariatePolynoimal`

in `printer.cpp`

, like it is for it's `Int`

counterpart?
Should I move it? It's basically not symmetric. Either both the dictionary wrappers should have the

`__str__()`

methods, and use it in `visit`

of the printer, or directly write it in that method.
I think we stick with the latter?

@srajangarg It was for printing for

`UnivariateSeries`

since that uses `UnivariateExprPolynomial`

@srajangarg @isuruf How soon can all the PRs dealing with the polynomial changes be merged? Charles (@chenchfort), Matthew (@myluszczak), James (@StoicBronco) and I are wrapping up our school year and we need to present what we've done in SymEngine to our professor in a "demo". So if there are any changes we'd like them to be done soon so we can prepare something to show

I think the delay right now is due to Appveyor CI

It's operating slower than usual