These are chat archives for symengine/symengine

5th
Jul 2016
Isuru Fernando
@isuruf
Jul 05 2016 03:23
Okay. how do you plan to implement the symengine version?
Srajan Garg
@srajangarg
Jul 05 2016 09:12
Just like the Int verison. I start with URatDict inheriting from ODictWrapper and start wrapping around that
It will use uint->rational_class
Isuru Fernando
@isuruf
Jul 05 2016 09:13
I'm not sure, that will be the best approach. Flint uses a fmpz_poly and a den
Srajan Garg
@srajangarg
Jul 05 2016 09:13
You mean internally?
Isuru Fernando
@isuruf
Jul 05 2016 09:13
yes
Srajan Garg
@srajangarg
Jul 05 2016 09:14
Hmm I see
What do you think can be done, introducing a denominator we might have to canonicalize after each operation
Isuru Fernando
@isuruf
Jul 05 2016 09:15
Yes, but the alternative is to canonicalize each coefficient
Srajan Garg
@srajangarg
Jul 05 2016 09:16
Plus will this rational polys be able to use the common templatized code if we use this approach?
Isuru Fernando
@isuruf
Jul 05 2016 09:17
I don't know
Srajan Garg
@srajangarg
Jul 05 2016 09:17
We'll have to write all the operators again, most probably
Isuru Fernando
@isuruf
Jul 05 2016 09:17
What do you mean?
Srajan Garg
@srajangarg
Jul 05 2016 09:18
So our URatDict is a UIntDict + a denominator term yes?
operator+ for URatDict = operator+ for UIntDict + custom canonicalization
NO, actually isn't that easy
we multiply the two UIntDicts with the others denominator, then add them, and new denominator is multiplication of both denominators, and then canonicalize
So we basically have to write a new operator+
So, should I go ahead with this?
We basically won't benefit from the already written ODictWrapper template
Isuru Fernando
@isuruf
Jul 05 2016 09:22
Yes, that's fine
Srajan Garg
@srajangarg
Jul 05 2016 09:24
Can you review symengine/symengine#1003, it is done from my end
Also for Piranha Polynomials, there are two ways. Either use polynomial<rational_class, monomial> or a polynomial<integer_class, monomial> + a denominatior
Isuru Fernando
@isuruf
Jul 05 2016 09:28
In #1003, shouldn't from_basic be declared in UIntPolyBase?
Srajan Garg
@srajangarg
Jul 05 2016 09:30
I haven't allowed construction of piranha and flint polys from basic
as it returns a UIntDict
I mean _b_to_poly
I can extract the map from it and then call a general from_dict method if you want
Isuru Fernando
@isuruf
Jul 05 2016 09:31
Isn't that the point of a common base?
Srajan Garg
@srajangarg
Jul 05 2016 09:35
I still don't understand how I'll go about it
Isuru Fernando
@isuruf
Jul 05 2016 09:36
In BasicToUPolyBase, template parameter D can be UIntDict, fmpz_poly_wrapper or piranha::polynomial right?
Srajan Garg
@srajangarg
Jul 05 2016 09:38
I don't think all of them can be constructed like this dict = D({{i, typename D::value_type(1)}});
all of them don't even have value_type defined
Isuru Fernando
@isuruf
Jul 05 2016 09:43
In UIntPolyFlint there is a static method from_dict that returns a UIntPolyFlint, right? How about having a another static method _from_dict which returns the internal storage class?
Srajan Garg
@srajangarg
Jul 05 2016 09:45
You mean the type?
Isuru Fernando
@isuruf
Jul 05 2016 09:46
An object of that type
Srajan Garg
@srajangarg
Jul 05 2016 09:47
So container_from_dict, I see
I'll try and make the changes
Isuru Fernando
@isuruf
Jul 05 2016 09:48
Series classes have a structure like this. Most methods are static functions and there is very little code duplication
Srajan Garg
@srajangarg
Jul 05 2016 09:49
Now the Poly type will also be a parameter? Poly::container_from_dict()
I mean, to use inside the the visitor
Isuru Fernando
@isuruf
Jul 05 2016 09:50
Yes, it can be the only type also, if you can access the container type from Poly::container_type
Srajan Garg
@srajangarg
Jul 05 2016 09:51
Makes sense, thanks
Srajan Garg
@srajangarg
Jul 05 2016 11:03
@isuruf is int still necessary for UExprPoly? All others have uint
Isuru Fernando
@isuruf
Jul 05 2016 11:03
Yes, it is needed for Series
Srajan Garg
@srajangarg
Jul 05 2016 12:42
@isuruf I need help, https://github.com/srajangarg/symengine/tree/b2poly, can you please suggest a solution. There are link errors. I know why the errors are happening, but cannot think of a solution. It's basically causing cyclic header includes. upolybase.h UPolyBase::from_basic -> _b_to_upoly -> BasicToPolyVisitors -> visitor.h -> all polys.h -> upolybase.h
Something must be forward declared, I don't know what should be the order
Srajan Garg
@srajangarg
Jul 05 2016 13:37
One solution I think is to forward declare all SymEngine classes
Isuru Fernando
@isuruf
Jul 05 2016 13:39
visitor.h is not included in upolybase.h right?
Srajan Garg
@srajangarg
Jul 05 2016 13:39
It should not be
It's not
Isuru Fernando
@isuruf
Jul 05 2016 13:39
Then, what is the cycle ?
Srajan Garg
@srajangarg
Jul 05 2016 13:40
As stated above
Isuru Fernando
@isuruf
Jul 05 2016 13:41
upolybase.h -> visitor.h -> upolybase.h ?
Srajan Garg
@srajangarg
Jul 05 2016 13:41
yes, indirectly upolybase.h -> basic_to_poly.h -> visitor.h -> upolybase.h
Isuru Fernando
@isuruf
Jul 05 2016 13:42
Where does upolybase.h include basic_to_poly.h?
Srajan Garg
@srajangarg
Jul 05 2016 13:43
updated branch, please look now
the prev version had link errors, I meant cycles would occur if I were to try and fix the link errors
Srajan Garg
@srajangarg
Jul 05 2016 13:44
that's what the prev version was
that had link errors
compiler hasn't generated code for the polynomials, as it has not even seen those classes
and we can't include basic_to_poly.h in the polys.hbecause again cycle
Isuru Fernando
@isuruf
Jul 05 2016 13:50
Keep a common function in basic_to_poly.h then without the from_basic methods
Srajan Garg
@srajangarg
Jul 05 2016 13:53
what will the API look like
Isuru Fernando
@isuruf
Jul 05 2016 13:54
Also use something like basic_conversions.h instead of basic_to_poly.h
Same as before,
template<typename Poly>
RCP<const Poly> from_basic(const RCP<const Basic> &basic,
                                          const RCP<const Basic> &gen,
                                          bool ex = false)
Srajan Garg
@srajangarg
Jul 05 2016 15:13
Why isn't operator* overloaded for fmpz_poly_wrapper
It needs to be right?
@rwst ping
Srajan Garg
@srajangarg
Jul 05 2016 15:19
can you tell me what I should add in, I need to get something working
Srajan Garg
@srajangarg
Jul 05 2016 15:27
Nvm, got it done for now
Others like + and - are missing too, can you add them in?
Srajan Garg
@srajangarg
Jul 05 2016 15:51
RCP<const UIntPolyFlint> V = UIntPolyFlint::from_vec(x, {{0_z, 0_z, 1_z, 1_z, 0_z, 0_z, 1_z}});
REQUIRE(V->__str__() == "x**6 + x**3 + x**2");
fails
It's printing x**6 + x**3 + x**2 + 7
:cry:
Srajan Garg
@srajangarg
Jul 05 2016 15:59
RCP<const UIntPolyFlint> V = UIntPolyFlint::from_dict(x, {{2, 1_z}, {3, 1_z}, {6, 1_z}});
REQUIRE(V->__str__() == "x**6 + x**3 + x**2");
passes
Srajan Garg
@srajangarg
Jul 05 2016 16:08
@isuruf please take a look at the PR now, pushed many changes