FLINT uses it's own integer implementation in the form of

`fmpzxx`

. We would still stick with whatever `integer_class`

is chosen at compile time for SymEngine polynomials, right? What about methods like, `get_leading_coeff`

. If it is called on a `UnivariateIntFlint`

what type of int should be returned? And what should be returned on calling it on a `UnivariateIntSymEngine`

? And similarly, what happens for Piranha?
In Piranha, I think we have a choice, we can either pass in

`integer_class`

(either machine int or gmp int) or piranha ints, right @bluescarni ?
@Sumith1896 What would be the right way to go?

you can use arbitrary types as coefficients in piranha polynomials, if that is what you are asking

Yes. Also, does Piranha have it's own integer implementation?

yes, it's mostly a wrapper around GMP mpz_t with some extra stuff

Are there any speed differences using the various coefficients? GMP vs Piranha vs Machine?

What are the tradeoffs, basically

it will depend largely on the magnitude of the coefficients. If the coefficients are large enough, Piranha just uses the GMP routines. For small coefficients, Piranha's integer will be faster

http://bluescarni.github.io/memory-friendly-data-structures-in-piranha-13.html there's some numbers at the bottom of this

So, you'd suggest sticking with Piranha's integers, right?

FLINT ints will be the fastest if the value fits in a single word

A word?

2^64 / 2^32 depending on the arch

roughly speaking (might be a few bits less than that)

Oh, like the machine ints

yes

both flint and piranha adopt a small value otpimisation with respect to GMP

but piranha considers 2 words as a small value, flint considerd 1 word as a small value

So, if coefficients are (sure to be) small -> flint, otherwise pirahanha?

so for 1 word flint will be fastest, for 2 words piranha should be the fastest, greater than that everything will be roughly equal to GMP

Piranha uses GMP methods on large values, so offers about the same speed

Okay

@isuruf did some benchmarks at some point I believe

Thanks a lot @bluescarni !

np anytime

@srajangarg, also note that

`piranha::integer`

can be chosen as the `integer_class`

, but `fmpzxx`

cannot, because some arithmetic and logic operators are not implemented in `fmpzxx`

We have a

`fmpz_wrapper`

class which does have all the operators implemented which can be used as `integer_class`

How about having both

`symengine_integer_class`

as well as `piranha_integer_class`

?
Also, if

`fmpzxx`

doesn't have all operators implemented, how are we supposed to interface with the integer_class, when calling methods which deal with the polynomial coefficients?
^ Ignore above messages, did not read your statement fully.

I feel that we should now provide, both

`symengine_integer_class`

as well as `piranha_integer_class`

, to handle all possible cases. This maybe overkill, but I think there's no harm in allowing full customization.
@isuruf Another question I had is that, most of the methods (like

`from_dict`

) have `map_uint_mpz &&dict`

as an argument. What does the double `&`

signify?
Nvm, just read about it

Also, what does a polynomial with ""(empty)

`var`

signify?
A polynomial with just a constant term

Why does it have to be "" then? It can be any symbol, no?

Also, why do we need

`bool map_uint_mpz_eq()`

? Isn't `==`

operator defined for GMP?
Yes, but if you don't know beforehand what symbol to use then "" is used

This should be fixed though

There needs to be an elegant way to handle this

@isuruf Can you please look at srajangarg/symengine#3 It's a small change. (on my fork) Tests about to pass.

Looks Ok right?

Yes, if it works

Okay, I think there are more such redundancies in the code

I'll have a look and send in a PR tomorrow fixing such functions.

Thanks

@isuruf @srajangarg WRT to elegant handling of constant polynomials, in MultivariatePolynomial we keep out variables in an std::set which could be empty. When we manipulate constant polynomials we just end up iterating through objects of size zero. I'm not sure what the corresponding solution would be in the univariate case, though. Perhaps you could return whatever the coefficient type is when you get a constant polynomial, and overload all of the operations appropriately? Whatever decision you make, we might want to implement it in the multivariate case as well, for consistency if nothing else.