These are chat archives for symengine/symengine
UnivariatePolynomialis also a Basic type and
Expressioncan take it in
UnivariateExprPolynomialis not supposed to be used by the user
UnivariateSeriesare exposed to the user
Expressionclass can be used to wrap both and have operator overloads
UnivariatePolynomialbecause just overloading the dictionary (wrapper) is faster/lighter?
UnivariateExprPolynomialand not on
UnivariateExprPolynomialas it just contains only the dictionary
Integeris immutable and
mpz_classis mutable and is used in low level methods
Basictype and memory is managed by
RCP, therefore we are using non member functions like
UnivariateExprPolynomialbecause of reasons we talked about, like
UnivariateExprPolynomial, can the user still avoid using
UnivariateSeries's static methods are not used by the user. We are still trying to find how to use it in
UPolyBase will have several implementations. Each implementation has a different container. UnivariateExprPolynomial (this would keep just a map_int_Expr inside), piranha::polynomial, flint::fmpq_polyxx)
Here, you mean a new class which will store
map_unit_mpz, instead of
add(UPolyPiranha a, UPolyFlint b)exists
UnivariateSeries, but it'll be buggy. This will be added eventually
Expression(T &&o) : m_basic(std::forward<T>(o))will be used? How would we proceed to make it work?
I’m trying to do FFT with symbols. Currently the output is like this
"(0.0 + 2.46519032881566e-32*b - 2.46519032881566e-32*a*b)*x**5 + (0.0 + 1 .0*a**2 - 5.55111512312578e-17*b**2)*x**4 + (0.0 - 1.23259516440783e-32*b + 2 .0*a*b)*x**3 + (0.0 + 2.0*a - 1.14967358514655e-17*a*b + 1.0*b**2)*x**2 + (0 .0 + 2.0*b)*x + (1.0 - 1.14967358514655e-17*a*b + 5.55111512312578e-17*b**2)" == "a**2*x**4 + 2*a*b*x**3 + (2*a + b**2)*x**2 + 2*b*x + 1”
If coefficients are only integers and symbols we can go through these and round the dict_ part.
Or any idea?
x*(y+z) - x*y - x*z + w == w
Univariateclasses? Right now their names are very unintuitive
map_uint_mpz(to be implemented) ->
In : rs_series(sin(a+pi/8),a,4) Out: -1/6*(sqrt(sqrt(2)/4 + 1/2))*a**3 + (sqrt(sqrt(2)/4 + 1/2))*a - 1/2*a**2*(sqrt(-sqrt(2)/4 + 1/2)) + (sqrt(-sqrt(2)/4 + 1/2))
expandon every coefficient in order to simplify it. We do this to check if the coefficients are algebraically equal to zero, so that we can remove terms equal to zero. When working on multivariable series expansion, however, I have found that this imposes a very significant (100x slowdown, mostly in cases involving division) performance penalty. However, removing this simplification can lead to counter-intuitive results (like
(x**2 + (a+b)*x + 1) + (x**2 - (a+b) * x + 1) != 2*x**2 + 2*x). As I see it, we have three options: we can continue to expand the coefficients in
from_dict, eating the slowdown. Since the slowdown seems to be occurring primarily in cases involving division, there might be something we can do to optimize
expand. Secondly, we can stop expanding the coefficients and live with the counter-intuitive behavior. Thirdly, we can change the function
__eq__to ignore terms with zero coefficients --we'ed probably end up calling expand in
__eq__in that case.
UnivariateExprPolynomial, we can check the
Expressionterms if they would algebraically equate to 0 (i.e. for subtracting if the terms are equal to each other), and if they are we skip over them so they won't be added to the resulting polynomial