These are chat archives for symengine/symengine

9th
May 2016
Srajan Garg
@srajangarg
May 09 2016 14:39
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?
Francesco Biscani
@bluescarni
May 09 2016 14:42
you can use arbitrary types as coefficients in piranha polynomials, if that is what you are asking
Srajan Garg
@srajangarg
May 09 2016 14:43
Yes. Also, does Piranha have it's own integer implementation?
Francesco Biscani
@bluescarni
May 09 2016 14:44
yes, it's mostly a wrapper around GMP mpz_t with some extra stuff
Srajan Garg
@srajangarg
May 09 2016 14:45
Are there any speed differences using the various coefficients? GMP vs Piranha vs Machine?
What are the tradeoffs, basically
Francesco Biscani
@bluescarni
May 09 2016 14:46
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
Srajan Garg
@srajangarg
May 09 2016 14:47
So, you'd suggest sticking with Piranha's integers, right?
Francesco Biscani
@bluescarni
May 09 2016 14:47
FLINT ints will be the fastest if the value fits in a single word
Srajan Garg
@srajangarg
May 09 2016 14:47
A word?
Francesco Biscani
@bluescarni
May 09 2016 14:48
2^64 / 2^32 depending on the arch
roughly speaking (might be a few bits less than that)
Srajan Garg
@srajangarg
May 09 2016 14:48
Oh, like the machine ints
Francesco Biscani
@bluescarni
May 09 2016 14:48
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
Srajan Garg
@srajangarg
May 09 2016 14:49
So, if coefficients are (sure to be) small -> flint, otherwise pirahanha?
Francesco Biscani
@bluescarni
May 09 2016 14:49
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
Srajan Garg
@srajangarg
May 09 2016 14:49
Piranha uses GMP methods on large values, so offers about the same speed
Okay
Francesco Biscani
@bluescarni
May 09 2016 14:50
@isuruf did some benchmarks at some point I believe
Srajan Garg
@srajangarg
May 09 2016 14:51
Thanks a lot @bluescarni !
Francesco Biscani
@bluescarni
May 09 2016 14:51
np anytime
Isuru Fernando
@isuruf
May 09 2016 14:55
@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
Srajan Garg
@srajangarg
May 09 2016 15:26
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?
Srajan Garg
@srajangarg
May 09 2016 15:46
This message was deleted
^ 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.
Srajan Garg
@srajangarg
May 09 2016 16:16
@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
Srajan Garg
@srajangarg
May 09 2016 16:31
Also, what does a polynomial with ""(empty) var signify?
Isuru Fernando
@isuruf
May 09 2016 16:36
A polynomial with just a constant term
Srajan Garg
@srajangarg
May 09 2016 16:48
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?
Isuru Fernando
@isuruf
May 09 2016 16:52
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
Srajan Garg
@srajangarg
May 09 2016 17:22
@isuruf Can you please look at srajangarg/symengine#3 It's a small change. (on my fork) Tests about to pass.
Srajan Garg
@srajangarg
May 09 2016 17:27
Looks Ok right?
Isuru Fernando
@isuruf
May 09 2016 17:27
Yes, if it works
Srajan Garg
@srajangarg
May 09 2016 17:30
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.
Isuru Fernando
@isuruf
May 09 2016 17:31
Thanks
myluszczak
@myluszczak
May 09 2016 22:24
@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.